Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#736 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
javascript, php
領域
api, backend, performance

調査の方向性

まず events.php エンドポイントを調査し、一覧ビューと詳細ビューで使用されているフィールドを比較します。Issue #576 を確認し、Bike Fun アプリが一覧ビューとマップビューで使用するコアフィールドを、追加のフォローアップ要求も含めて特定します。レスポンス戦略、リクエストパラメータ、互換性計画、および完全なレコードの動作が文書化されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
JavaScript
スター
30
フォーク
26
平均マージ
6日 23時間
マージ済み PR（30日）
3

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

shift-org/shift-docs のほかの issue

shift-org/shift-docs の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。