Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Evaluate an option to fetch limited or all event fields for range requests

Ouverte
  • Quelque chose ne va pas ?
#736 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 7 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
javascript, php
Domaine
api, backend, performance

Piste de recherche

Commencez par examiner l’endpoint events.php et par comparer les champs utilisés par les vues de liste et de détail. Examinez l’issue #576 et déterminez quels champs principaux l’application Bike Fun utilise pour les vues de liste et de carte, y compris les demandes de suivi éventuelles. La tâche est considérée comme terminée lorsque la stratégie de réponse, les paramètres de la requête, le plan de compatibilité et le comportement pour les enregistrements complets sont documentés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

API backend enhancement frontend question

Currently, whether you fetch a single event or a range of events from the events endpoint, we send back an events array which contains 1 event object for every matching event. Each event object always includes all of the (public) fields for an event.

For single events, this is obviously desired. For range requests, the client may not need the full object for every single event. For example, the grid view only uses a few properties: id, title, date, time, cancelled, featured, and maybe a few others. We request all of the data for every event that it displays, but to actually see it you have to navigate to an individual ride page (at which point we make a second request and re-fetch the full record anyway).

I did some brief experimenting with past ride data. comparing the current results vs. omitting a handful of fields that aren't likely needed until someone wants to read an individual ride listing:

  • description
  • contact fields: email, phone, contact
  • all of the "print" and "hide" fields (which should be deprecated anyway in this endpoint; see #576)

In my test, this reduced the (uncompressed, but minified) JSON by about 50%, from 512 KB down to 205 KB.

If we want to pursue this further, some considerations:

  • The description and print description fields alone may be responsible for a lot of the weight difference
  • We'll gain some improvements just by deprecating the "print" and "hide" fields for all requests to the events endpoint
  • How would these requests by made — optional URL param? e.g. events.php?startdate=2024-04-04&enddate=2024-04-04&fields=all
  • A sensible default might be to serve the limited response for range requests, unless the client explicitly requests the full records. This wouldn't be backwards-compatible, however. As a transition, we could make it opt-in for now (fields=limited?), but flip the default behavior in the next major API version.
  • Should consider including an additional field in the truncated response, with a URL for the full record
    (e.g. "full_record":"https://localhost:4443/api/events.php?id=12345"; this is different from the shareable URL, which is a link to the web page rather than the API request)
  • Fetching a single event could always return all fields, ignoring the param.
  • Our list view currently makes use of the fact that it has the full event record for every fetched event. If you expand a ride listing in-place, it does so without needing to load a new page or make another request. We should determine which is speedier overall — requesting all event data up front and expanding in-place, or making a just-in-time request to fetch details if/when needed. (This might be different for busy times of year vs less busy ones, e.g. Pedalpalooza vs January.)
  • Find out which core fields Bike Fun app is using for its list and map views and which are needed only for detail views, and if/how they are making follow-up requests.
Langage dominant
JavaScript
Étoiles
30
Forks
26
Merge moyen
5 j 3 h
PR mergées (30 j)
7

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de shift-org/shift-docs

Toutes les issues de shift-org/shift-docs

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.