kyuno/watchparty
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

Correct docs/comments left stale by the Limit removal
Some checks failed
Publier l'image Docker / test (pull_request) Failing after 4s
Details
Publier l'image Docker / publish (pull_request) Has been skipped
Details

Browse source
This commit is contained in:
Nicolas 2026-09-15 22:51:36 +02:00
parent 05c4611403
commit 40e019cd81
2 changed files with 30 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
client/src/tiles.ts
View file

@ -140,11 +140,14 @@ export function renderTilesInChunks(container: HTMLElement, items: ItemDto[], ch
* Wires a search <input> to show/hide `itemSelector` elements by name,
* live as you type - client-side only, filtering whatever's already
* rendered rather than a server round trip per keystroke. Deliberately
* simple for that reason: a library page tops out at a few hundred items
* (see getLibraryItems's own Limit), well within "just filter the DOM"
* territory - shared by views/library, views/artist, views/album so the
* three catalog pages that asked for this all behave identically instead
* of drifting into three slightly different implementations.
* simple for that reason: even a library with well over a thousand items
* (see getLibraryItems/getArtists - no Limit any more, see their own
* comments) is still just a plain, already-in-the-DOM list of elements
* to a querySelectorAll/textContent check - "just filter the DOM" scales
* fine here regardless of count. Shared by views/library, views/artist,
* views/album so the three catalog pages that asked for this all behave
* identically instead of drifting into three slightly different
* implementations.
*
* `scope` should be wide enough to contain both the items themselves AND
* a `.searchEmpty` notice element - typically the view's own `root`, not

22
docs/architecture.md
View file

@ -2631,6 +2631,28 @@ mode a naive per-button-at-call-time wiring would have hit). **Not
verified**: no Emby login reachable from this sandbox to measure the
actual before/after latency against a real, large library.
**Correction, reported immediately after this shipped**: "the catalogs
are broken, not all the data is there". The `Limit: 300` both queries
above carried (`getArtists` gained one here; `getLibraryItems` already
had one, predating this section) turned out not to be the safe,
theoretical headroom it was assumed to be - confirmed directly against
the real server that this app's own "Musique" library has **1229**
distinct artists and "Films" has **421** movies, so both were silently
serving an incomplete grid, no error, no visible sign anything was
missing. Both `Limit`s removed outright, not raised to some other
guessed number - confirmed empirically that Emby returns everything
when `Limit` is omitted at all (`TotalRecordCount` matched
`Items.length` exactly for both the 421- and 1229-item cases), and the
render-side concern that motivated capping in the first place is
already `renderTilesInChunks`'s job regardless of how large the list
gets. That fix's own scheduling primitive needed a second look too:
`requestAnimationFrame` is deliberately paused by the browser for a
backgrounded/hidden tab - an ordinary thing to do while a now-possibly-
1000+-item list is still loading, and would have stalled the render
indefinitely, looking exactly like the same "data missing" symptom for
an unrelated reason. Switched to `setTimeout(fn, 0)`, which keeps
running (throttled, never paused) regardless of tab visibility.
## Fixing the listen-party queue's layout and its missing album art
Reported directly: the music bar's "File d'attente" popup looked broken,