Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Favorites page fetches every favorite because getDaily's guard is inverted

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#1,087 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

@gangster đang làm issue này rồi.

Từ ngày 5/8/2026.

  • #1088 của @gangster — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
javascript
Lĩnh vực
frontend, performance

Hướng nghiên cứu

Bắt đầu trong cal/src/support/favorites.js và cal/src/support/dataPool.js, sau đó tái hiện bằng npm run dev với một lần tải trang mới và tab Favorites. Xác minh rằng việc tải mục yêu thích chỉ từ cache không tạo bất kỳ yêu cầu nào đến events.php và rằng các tiêu đề, ngày tháng và thời gian đã lưu vẫn được hiển thị chính xác; kiểm tra docs/CalVue.md để biết hành vi làm mới dự kiến.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Opening the Favorites tab issues one events.php request per stored favorite, one after another, even though the calling code explicitly asks for cache-only data by passing {fetch: false}. The guard it passes that flag to is inverted, so it gets the opposite of what it asks for.

Reproducing

  1. npm run dev, then open http://localhost:3080/events/
  2. Open a few rides and favorite each one (the star button on the event details page)
  3. Reload the page — this matters, see the note below
  4. Open DevTools → Network and filter for events.php
  5. Click through to the Favorites tab

Expected: no requests. The favorites list renders from local storage.

Actual: one events.php?id=N request per favorite, each starting only after the previous one finishes.

With 4 favorites stored I measured 4 requests taking 11 ms, 2.1 ms, 1.9 ms and 1.9 ms, starting at +0, +11.3, +13.5 and +15.5 ms — 17.3 ms of wall time on localhost. The start offsets line up with the preceding request's completion, which confirms they are serialised rather than merely issued in quick succession.

The reload in step 3 matters because dataPool keeps an in-memory caldaily_map. If you favorited the rides in the same page session they are already cached, the early-return hides the bug and you see nothing. A fresh load is the normal case anyway — someone opening the app and tapping Favorites.

Cause

cal/src/support/favorites.js asks for cache-only data:

// if we have retrieved this event recently; update it.
// future: background request to update all ( or a page of ) favorite data.
const [ series_id, single_id ] = key.split('-');
const evt = await dataPool.getDaily(single_id, {fetch: false});

But the guard in cal/src/support/dataPool.js is inverted:

async getDaily(caldaily_id, options = null) {
  const cached = caldaily_map.get(caldaily_id);
  if (cached) {
    return cached;
  } else if (!options || options.fetch === false) {
    // ...performs the network fetch

The branch runs the fetch when fetch is false. Because that await sits inside a for loop over every stored key, the requests are also serialised.

A second consequence: getDaily(id, {fetch: true}) matches neither branch and returns undefined. Nothing calls it that way today, so it is latent rather than broken.

Suggested fix, and the one thing it changes

-    } else if (!options || options.fetch === false) {
+    } else if (!options || options.fetch !== false) {

I tried this locally: the Favorites tab makes 0 requests and all four favorites still render correctly, with the right titles, dates and times, straight from local storage.

To be upfront about the trade-off — these requests are not doing nothing. updateStorage runs the response back through pick(), the same subset filter used when the favorite was created, so the fetch cannot add any field the stored copy lacks. What it can do is refresh values: a ride cancelled or retimed after you favorited it currently gets picked up here. After this change, a favorite would show what it showed when you saved it until you open it.

That looks like the intended design rather than a regression:

  • pick()'s own comment says "doesn't store newsflash: there's no fast refresh; it might be stale."
  • The comment at the call site describes a background refresh as future work.
  • docs/CalVue.md lists both "a disclaimer about opening each favorite to see the latest information" and "future: server helper to quick update favorite status" as open items.

So the accidental refresh is doing a job nobody has designed yet, in the least efficient shape available — serially, on the critical path, on every visit. If you would rather keep refreshing, the fix is still correct and the refresh wants to become deliberate: batched or parallel rather than one awaited request per favorite.

Impact

Negligible on localhost, but it is a serial chain in front of the render. On a mobile connection at 100–300 ms per round trip, twenty favorites would be several seconds before the view settles. It is also avoidable load on the API box for data the client already has.

Possibly related to the "favorites need pagination" item in docs/CalVue.md — some of what makes that page feel slow may be this rather than the rendering.

Ngôn ngữ chính
JavaScript
Star
30
Fork
25
Merge trung bình
9 phút
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của shift-org/shift-docs

Tất cả issue của shift-org/shift-docs

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.