|
Gesprekken: eerst wie, dan pas wat
shaer-frontend-yso, stap 1 van 3: de serverkant NAAST het bestaande pad, want
de apps in het veld lezen de oude inbox-lezing nog.
De oude lezing geeft de nieuwste 60 berichten over ALLE gesprekken samen. Bij
DM's is dat veel erger dan bij posts -- meer en kortere berichten, dus een druk
gesprek eet de 60 in zijn eentje op en duwt de rest eruit. Viel het laatste
bericht van iemand erbuiten, dan verdween die persoon HELEMAAL uit Messages:
de avatarhemel plaatst mensen op de leeftijd van hun laatste bericht, dus geen
bericht is geen gezicht. test/conversations.test.js legt die bug eerst vast.
Nu twee lezingen:
GET /ap/users/:slug/conversations een rij per tegenpartij, compleet van
vorm -- het aantal rijen is het aantal
mensen, niet het aantal berichten
GET /ap/users/:slug/messages?with= het gesprek zelf, beide kanten onder EEN
limiet, met next zolang er meer is
Beide kanten onder een limiet, want in de oude lezing werden jouw kant
(getSentNotes) en hun kant apart afgekapt en kon een gesprek eenzijdig lijken.
DE CURSOR IS SAMENGESTELD (stempel|ref) en niet alleen de stempel. Twee
berichten in dezelfde seconde is bij DM's een gesprek en geen randgeval; met
'stamp < before' viel alles wat die grensseconde deelde stil weg. De testen
vonden dat, en tellen nu dat de drie paginas samen precies 80 berichten zijn.
De paginagrootte reist mee in next, anders wordt pagina twee stilletjes de
standaard.
Om te voorkomen dat de kaartvorm twee keer beschreven staat: de poorten
(leesPoorten) en de vorm (berichtItem/verzondenItem) zijn uit de inbox-lezing
gehesen en worden nu door allebei gebruikt. Zelfde gedrag, 843/843 groen.
Co-Authored-By: Claude Opus 5 <noreply@…>
|