Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#736 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 7 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 小时
30 天内合并 PR
3

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

shift-org/shift-docs 的其他 Issue

查看 shift-org/shift-docs 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。