Files
siftlode/frontend/src/lib/nextPage.ts
T
peter 4aaaaa7860 chore(comments): drop epic, sprint and review-round ids from the code
The code cited its plan instead of saying why: `E28 review J4`, `(R6 S3b)`, `S1 justified…`,
`deep-review round 5`. That plan lives in the private ops repo, so for every reader of this one the
citation was noise, and a sentence whose subject was the plan step ("round 2 showed…") hid its
lesson behind an id. Each one is gone and the "why" kept: a bare citation is deleted, a sentence
carrying a lesson is reworded around it ("a later attempt showed…").

Measured (`scripts/audit_metrics.py`, product code): 652 lines in 270 files carried an epic code by
the definition the next commit holds (507 / 241 by the old, two-digit-only one) -> 0. Across all
code, tests, scripts and configs: ~1100 epic-code lines plus ~320 sprint/round ids.

Behaviour unchanged, checked mechanically: every changed .py file has the same AST once docstrings
are blanked; css/sh/toml/yml/json files are identical once comments are stripped; the only
non-comment changes in TS/JS are test titles, one description string in a contract table, and five
ESLint messages, whose text is all the gates snapshot diff holds. Not touched: Markdown (docs and
the changelog keep their history), Alembic migrations, TV episode notation (`S2 · E5`), DESIGN.md
ids (`C1`, `B4`, `S3h`), tracker ids (`SEC-16`, `DX-17`).

One stale claim fixed on the way: test_hls_reaper's docstring said the player checkpoints "every
10 s whether or not it is playing", which plex/stream.py calls wrong; it now says what the code does.
2026-10-05 00:19:39 +02:00

26 lines
1.6 KiB
TypeScript
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
/**
* What every `fetchNextPage` call passes (lint-enforced). By default react-query CANCELS a next-page
* fetch that is still in flight and sends it again with the same cursor. Our requests do not take the
* abort signal, so the first one is not stopped: the server ran both. The feed's read-ahead effect
* re-runs on every scroll frame, and a frame that lands before `isFetchingNextPage` turns true calls
* again. On prod every feed page went out 2–3 times; on a 0.8 s title sort the copies
* queued to 2.3 s. With this a second call joins the fetch already running.
*
* The join takes ANY fetch in flight, not only a next page: a call during a background refetch (an
* invalidation, a poll) joins THAT, which reloads the pages already there and appends none.
* So a read-ahead also waits while the list is fetching at all (`mayReadAhead`) and runs again when
* the fetch settles; a click uses `nextPageOnClick`.
*/
export const NEXT_PAGE = { cancelRefetch: false } as const;
/** Whether an infinite list's read-ahead may ask for the next page now. Not while ANY fetch of the
* list is in flight: that call would join it (see NEXT_PAGE). The caller re-runs on `isFetching`. */
export const mayReadAhead = (hasNextPage: boolean, isFetching: boolean) =>
hasNextPage && !isFetching;
/** The options for a next page a person asked for (a "Load older" button): join the page already
* loading, else cancel a background refetch and load the page — a click must not be swallowed by a
* poll that happened to be running. */
export const nextPageOnClick = (isFetchingNextPage: boolean) =>
isFetchingNextPage ? NEXT_PAGE : ({ cancelRefetch: true } as const);