Changeset bac4bf3 in Klonkt for src/services/ap-core.js

Timestamp:

08/13/2026 11:55:04 AM (4 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

783b9ff

Parents:

7e9d0ea

git-author:

Robin <roboburr@…> (08/13/2026 11:54:36 AM)

git-committer:

Robin <roboburr@…> (08/13/2026 11:55:04 AM)

Message:

Paginering die echt pagineert (shaer-sk4)

Robin zag dat elke ?page= dezelfde inhoud gaf. Dat klopte, en het was geen halve
implementatie maar een omhulsel: pagedCollection veranderde alleen de VORM en
sneed nooit. first en last wezen allebei naar ?page=1, en de routes lazen
!!req.query.page -- of de parameter er STAAT, niet welke. Live gaf ?page=2 en
?page=99 dezelfde acht items, en noemden zichzelf pagina 1.

Nu: echt snijden, met next en prev, en een pagina die zijn eigen nummer
draagt. Een pagina voorbij het einde is LEEG en zegt dat ook -- hem naar de
laatste terugbuigen zou opnieuw een antwoord zijn dat over zichzelf liegt.

DE WORTEL HOUDT ZIJN ITEMS INLINE, en dat is geen slordigheid maar de reden dat
dit veilig is. Shaer leest een document en volgt next niet (KlonktClient.swift
orderedItems). Werd de wortel nu leeg, dan kreeg elke draaiende app nul items en
geen foutmelding -- dezelfde stille val waar ik op 10 augustus bij Funkwhale zelf
in trapte. Eerst de clients leren pagineren, dan pas de wortel afslanken.

WAT WEL EN NIET GEPAGINEERD IS. Volgers en following pagineren nu volledig: die
lijsten zitten al in het geheugen, dus dat kost niets extra. De outbox krijgt de
juiste VORM maar niet meer diepte: de route kapt al op twintig rijen in SQL.
Echt doorbladeren vraagt daar een LIMIT/OFFSET, en dat is lastiger dan bij
volgers omdat posts en tracks op datum door elkaar gevlochten worden en uit twee
tabellen komen -- een UNION met een offset erover, geen tweede slice. Dat staat
als naad in de code en op de bead, niet weggemoffeld.

Zeven tests, waaronder de klacht zelf: pagina 2 geeft ANDERE items dan pagina 1.

Co-Authored-By: Claude Opus 5 <noreply@…>

File:

• src/services/ap-core.js (modified) (2 diffs)

src/services/ap-core.js

@@ -212 +212 @@
  *   extra       velden die op de wortel horen (attributedTo, shaer:*)
  */
-export function pagedCollection(id, items, { totalItems, page = false, extra = {} } = {}) {
+/** Hoeveel items op een pagina. Gelijk aan wat de outbox vroeger als KAP had. */
+export const PAGINA_GROOTTE = 20;
+
+/**
+ * Een collectie, met ECHTE paginering (shaer-sk4).
+ *
+ * Wat hier stond was een omhulsel: `page` veranderde alleen de VORM en er werd
+ * nooit gesneden. `first` en `last` wezen allebei naar ?page=1, elke ?page=N gaf
+ * dezelfde items, en pagina 99 noemde zichzelf pagina 1. Robin zag dat de
+ * pagina's identiek bleven; dit is waarom.
+ *
+ * DE WORTEL BLIJFT ZIJN ITEMS INLINE DRAGEN, en dat is geen slordigheid maar de
+ * hele reden dat dit veilig is. Shaer leest één document en volgt `next` niet;
+ * zou de wortel nu leeg worden, dan kreeg elke draaiende app nul items en geen
+ * foutmelding. Eerst de clients leren pagineren, dan pas de wortel afslanken.
+ *
+ * Een pagina VOORBIJ het einde is leeg en zegt dat ook -- met zijn eigen nummer
+ * en zonder `next`. Hem naar de laatste pagina terugbuigen zou opnieuw een
+ * antwoord zijn dat over zichzelf liegt.
+ */
+export function pagedCollection(id, items, { totalItems, page = false, perPage = PAGINA_GROOTTE, extra = {} } = {}) {
   const lijst = items || [];
   const telling = totalItems === undefined ? lijst.length : totalItems;
-  const eerste = `${id}?page=1`;
+  const grootte = Math.max(1, Number(perPage) || PAGINA_GROOTTE);
+  const paginas = Math.max(1, Math.ceil(lijst.length / grootte));
+  const url = (n) => `${id}?page=${n}`;
+
   if (page) {
+    const n = Math.max(1, Math.floor(Number(page)) || 1);
+    const deel = lijst.slice((n - 1) * grootte, n * grootte);
     return {
       '@context': AP_CONTEXT,
-      id: eerste,
+      id: url(n),
       type: 'OrderedCollectionPage',
       partOf: id,
       totalItems: telling,
-      orderedItems: lijst,
+      ...(n > 1 ? { prev: url(n - 1) } : {}),
+      ...(n < paginas ? { next: url(n + 1) } : {}),
+      orderedItems: deel,
     };
   }
@@ -232 +259 @@
     ...extra,
     totalItems: telling,
-    first: eerste,
-    last: eerste,
+    first: url(1),
+    last: url(paginas),
     orderedItems: lijst,
   };