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.
26 lines
1.6 KiB
TypeScript
26 lines
1.6 KiB
TypeScript
/**
|
||
* 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);
|