Under the Hood.nl

🌐 English · Deutsch · Español · Français · 简体中文

Onder de motorkap

Implementatienotities die niet in het verhaal van Architectuur passen — details die het weten waard zijn als u iets aan het debuggen bent, wilt nagaan wat de app waar opslaat, of zich afvraagt waarom hij zich op een bepaalde manier gedraagt.

Browseropslag: sessionStorage vs localStorage

Beide zijn afgebakend tot het browserprofiel + de origin, niet tot degene die is ingelogd. Als gebruiker A uitlogt en gebruiker B inlogt in dezelfde browser (dezelfde computer, hetzelfde browserprofiel), begint het tabblad van gebruiker B met wat de opslag van die origin al bevatte — tenzij de app die expliciet wist of van een naamruimte voorziet. Gramps Connect verdeelt zijn opslag aan de clientzijde precies langs die lijn over de twee API's:

sessionStorage (app/src/auth/auth.ts) bevat het toegangstoken, het refresh-token en de gebruikersnaam. logout() wist alle drie expliciet, en sessionStorage zelf overleeft een gesloten tabblad niet — dus een nieuwe login begint altijd schoon, en hier lekt niets tussen gebruikers.

localStorage bevat UI-voorkeuren, en — anders dan de authenticatietokens — wordt niets daarvan gewist bij uitloggen:

Sleutel	Bereik	Bestand
gramps-connect_home_person	per stamboom (met getTreeId() als sleutel)	app/src/store/homePersonPreference.ts
gramps-connect_column_widths	globaal	app/src/store/columnWidths.ts
gramps-connect_tree_manual_expand	globaal	app/src/store/treeExpandPreference.ts
gramps-connect_aside_widths	globaal	app/src/App.tsx
gramps-connect:map-viewport	globaal	app/src/components/visuals/MapCanvas.tsx
gramps-connect_browser_notifications_enabled	globaal	app/src/store/browserNotifications.ts

Geen van deze heeft een naamruimte per gebruiker, en alleen home_person heeft er een per stamboom. Praktisch gevolg: op een gedeelde computer erft de volgende persoon die inlogt (zelfs in een andere stamboom, voor de globale sleutels) de kolombreedtes, paneelgroottes, het kaartbeeld en de meldingsschakelaar van de vorige gebruiker — en, als het dezelfde stamboom is, ook diens keuze van de startpersoon. Er wordt niets gevoeligs blootgegeven (hier staan geen stamboomgegevens of inloggegevens, alleen weergavevoorkeuren), maar het is echt gedrag dat een gebruiker kan opmerken en waarover hij vragen kan stellen.

Als isolatie per gebruiker ooit gewenst is, is de oplossing hetzelfde patroon dat homePersonPreference.ts al gebruikt voor afbakening per stamboom — het opgeslagen object een sleutel geven op gebruikers-id (of gebruikersnaam) in plaats van, of naast, het stamboom-id.

Gerelateerd-/detailpaneel: direct opnieuw tekenen bij terugkeer

Het ophalen per record van het paneel rechtsboven (en het paneel "Referentiedetail" onderaan) (fetchObjectExtended, app/src/store/objectDetail.ts) wordt ondersteund door een kleine stale-while-revalidate-cache in het geheugen, met weergave + handle als sleutel en een maximum van 50 items (LRU-verwijdering). Van een record weg navigeren en ernaar terugkeren tekent direct het laatst bekende detail in plaats van een laadindicator te tonen — de onderliggende lijstweergaven (DataTable) deden dit al via hun blijvende ViewStore/SQLite-cache (zie Architectuur); dit dicht hetzelfde gat voor het detailpaneel, dat voorheen bij elke mount helemaal opnieuw ophaalde.

Het is geen echte cache in de zin van "de fetch overslaan": elke mount roept fetchObjectExtended nog steeds precies zoals voorheen aan en overschrijft het cache-item met het verse resultaat. Net als de localStorage-sleutels hierboven is het een cache op moduleniveau — die niet wordt gewist bij uitloggen of wisselen van stamboom.

Het paneel haalt ook opnieuw op telkens wanneer live synchronisatie enige wijziging in de stamboom meldt, niet alleen een wijziging aan zijn eigen (weergave, handle). Het normale pad van live synchronisatie verhoogt alleen de revisie van een ViewStore bij een wijziging die overeenkomt met de eigen tabel/handle van die store, wat precies is voor lijstweergaven maar hier niet genoeg: een bewerking van een ander record dat in de opgeloste referenties van dit record is ingebed (de tekst van een Notitie, de datum van een Gebeurtenis die via extend=all/backlinks wordt binnengehaald) zou anders geen nieuwe fetch veroorzaken, en dus verouderd blijven tot het paneel opnieuw werd gemount. Opnieuw ophalen bij elke wijziging in de stamboom ruilt wat extra pollingverkeer in voor correctheid, in plaats van opnieuw af te leiden welke handles zijn ingebed — die vorm verschilt per objecttype (zie Datamodel en bewerken).