Quellcode durchsuchen

Zoekfilter reist niet meer mee bij menu-navigatie (14 drawer-knoppen)

Bob heeft op alle drawer-knoppen naar een filterpagina een Update App State
gezet (Clear Value op zoekterm + zoekOpen) VOOR de Navigate To. Geverifieerd
op een verse export: 14 resets, alle 14 voor de navigatie en alle 14 met
beide velden. Naast de 11 doelrijen ook Horeca (2x) en Thuis bezorgen -
onschadelijk, die pagina's lezen de App State zoekterm/zoekOpen niet.

CLAUDE.md: twee onderzoeksresultaten vastgelegd die hier onder lagen.
- Navigatie stapelt (18x pushNamed, 0x goNamed), de oude pagina blijft leven
  met zijn controllers en zijn lijst, en didPopNext bevat alleen debug-code -
  dus er is geen "bij terugkeer"-trigger. Daarom hoort zo'n reset in de
  drawer en niet in On Page Load (die draait na de eerste build: flikkering
  plus een dubbele API-call).
- Een meegereisde zoekterm kost een factor 8 aan laadtijd. Niet door meer
  queries, maar omdat alleen de lege "zoek=" altijd warm in de Cloudflare-
  cache staat: 1,4-1,7 s koud tegen 0,17-0,21 s warm.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bob vor 1 Tag
Ursprung
Commit
b00b0ebd40
2 geänderte Dateien mit 32 neuen und 1 gelöschten Zeilen
  1. 31 0
      CLAUDE.md
  2. 1 1
      TASKS.md

+ 31 - 0
CLAUDE.md

@@ -1449,6 +1449,37 @@ het argument op type JSON en het return-type op **Boolean met Nullable uit** —
 dan is er ook geen "Default Variable Value" nodig. Voorbeeld in dit project:
 `isOngepubliceerd(dynamic item)` in `custom_functions.dart`.
 
+**Navigatie in dit project STAPELT: alle 18 drawer-knoppen gebruiken
+`context.pushNamed`, geen enkele `goNamed` — en er is geen trigger die bij
+TERUGKEER draait.** Gemeten 2026-09-24. Drie gevolgen die je bij elk
+"reset bij paginawissel"-ontwerp moet kennen:
+- De oude pagina wordt nooit weggegooid. Hij houdt zijn eigen
+  `TextEditingController`s, zijn eigen page state én zijn al opgehaalde lijst.
+  Op het toestel bewezen: Home kwam na een back-navigatie terug met `jazz` in
+  het zoekveld én zijn oude jazz-lijst eronder, terwijl de App State intussen
+  leeg was. Intern consistent, dus de gebruiker merkt niets — tot iets een
+  herlaad triggert (een chip aantikken) en veld en lijst uiteenlopen.
+- **`didPopNext()` bevat in álle componenten uitsluitend debug-code**
+  (`isRouteVisible`, voor FlutterFlow's eigen inspectiepaneel), nooit
+  gebruikersacties. FlutterFlow biedt dus geen "On Page Return"; er is niets om
+  een reset aan te hangen bij een pop.
+- **On Page Load is geen alternatief voor "schoon beginnen"**: die draait in een
+  `addPostFrameCallback`, dus ná de eerste build. De lijst doet dan eerst een
+  gefilterde fetch en daarna nog een ongefilterde — zichtbare flikkering plus
+  een dubbele API-call. Reset daarom **in de drawer, vóór de `Navigate To`**;
+  dan is de App State al leeg wanneer de nieuwe pagina zijn `initState` draait.
+  Sinds 2026-09-24 staat dat op 14 drawer-knoppen (`Update App State` met
+  **Clear Value** op `zoekterm` + `zoekOpen`).
+
+**Een zoek-/filterparameter mee laten reizen kost een factor 8 aan laadtijd —
+niet door méér queries, maar door een koude Cloudflare-cache.** Gemeten
+2026-09-24 op `flutterflowmobiel1` services_3: elke unieke URL wordt gecachet
+(ook `zoek=jazz`), maar `zoek=` (leeg) is de enige variant die iedereen
+opvraagt en dus altijd warm staat. Koud 1,4-1,7 s (MISS, met een `LIKE` op
+`node.title` op de origin) tegenover 0,17-0,21 s warm. `ApiManager.asQueryParams`
+filtert lege params **niet** weg, dus de lege variant is één vaste, gedeelde URL.
+Vuistregel: laat een nieuw scherm zijn eerste fetch op de kale URL doen.
+
 **Een `Navigate To`-actie naar een ANDERE pagina laten wijzen wist stil alle
 parameter-bindingen — zet ze altijd opnieuw.** Bevestigd 2026-09-11 (taak 18,
 twee plekken): na "Select Page" om te zetten van de ene naar de andere pagina

+ 1 - 1
TASKS.md

@@ -613,7 +613,7 @@ eerste tab naar die knop (of toon `LegeLijstComponent` met die tekst).
 
 ### 132-I · Kleine punten
 
-- **Drie dode restanten rond de filterbalk** (gevonden 2026-09-22 bij het zoeklek —
+- **Drie dode restanten rond de filterbalk** (gevonden 2026-09-22 bij het zoeklek, nog steeds open —
   alleen opruimen, geen gedragswijziging; **Claude raakt dit niet aan**):
   App State **`zoekActief`** wordt nergens gelezen of gezet; de
   component-parameter **`parameter1`** van `FilterBalkComponent` wordt nergens