|
|
@@ -1981,20 +1981,42 @@ call, bevestigd via verse export. Punt 2 hieronder blijft open als
|
|
|
losse taak.)*
|
|
|
|
|
|
**P1-10 · Eigenaar: Onbepaald.** Performance — resterend werk (audit
|
|
|
-afgerond 2026-08-05, Claude, code-niveau):
|
|
|
-1. **Groter/structureel, nog te beoordelen:** 4 pagina's (`Home`,
|
|
|
- `horecagelegenheden_overzicht(_sort_page/_page_data_type)_widget.dart`)
|
|
|
- hebben een `TabBarView` met 6-7 tabs die **allemaal gelijktijdig**
|
|
|
- hun eigen API-call vuren bij page-load (Flutter bouwt alle tabs
|
|
|
- eager, geen lazy-tabs) — ook de tabs die de gebruiker nog niet ziet.
|
|
|
- De inmiddels aangezette `cache: true` (zie archiveringsnotitie
|
|
|
- hierboven) verhelpt dit niet — dat voorkomt alleen herhaling bij een
|
|
|
- latere rebuild, niet de eerste gelijktijdige burst. Echte fix vraagt
|
|
|
- een structurele herbouw (bv. `IndexedStack`
|
|
|
- met on-demand `FutureBuilder` per tab-activatie i.p.v.
|
|
|
- `TabBarView`) — vermoedelijk custom code. Geen bekend
|
|
|
- rate-limit-probleem op de Drupal-API, dus mogelijk lage prioriteit
|
|
|
- ondanks de N×-overhead.
|
|
|
+afgerond 2026-08-05, Claude, code-niveau; **puntje 1 verder uitgewerkt
|
|
|
+2026-08-23, Claude, code-only — geen builder aangeraakt, Home/
|
|
|
+horeca-overzicht staan momenteel toch al in een andere sessie's
|
|
|
+actieve WIP-diff**):
|
|
|
+1. **Groter/structureel, nog te beoordelen — nu met concrete cijfers +
|
|
|
+ een builder-native aanpak (géén custom code nodig, i.t.t. de
|
|
|
+ eerdere inschatting):**
|
|
|
+ - **`home_widget.dart`**: 5 tabs (Uitgaan/Activiteiten/Cultuur/
|
|
|
+ Films/Jeugd), elk een eigen instantie van
|
|
|
+ `HomeUitgaantabelKaartComponentWidget(displayid: 'services_N')`
|
|
|
+ — dat component vuurt zijn eigen `HomeTabelCall`/paginated
|
|
|
+ Backend Query al in `initState`/`didChangeDependencies`, dus
|
|
|
+ **alle 5 direct bij page-load**, ook de 4 tabs die de gebruiker
|
|
|
+ nog niet ziet.
|
|
|
+ - **`horecagelegenheden_overzicht(_sort_page/_page_data_type)_widget.dart`**
|
|
|
+ (3 bijna-identieke pagina-varianten, elk 6 tabs): zelfde patroon,
|
|
|
+ **6× eager** per variant.
|
|
|
+ - `cache: true` lost dit niet op (voorkomt alleen herhaling bij een
|
|
|
+ latere rebuild, niet de eerste burst) en geen bekend
|
|
|
+ rate-limit-probleem op de Drupal-API — blijft dus mogelijk
|
|
|
+ bewust lage prioriteit, maar **wél goedkoper te fixen dan eerder
|
|
|
+ gedacht.**
|
|
|
+ - **Geen `IndexedStack`/custom code nodig** — dit project heeft al
|
|
|
+ een bewezen, puur builder-native patroon voor "fetch alleen bij
|
|
|
+ tab-activatie": de **per-tab "On Tap"-actie op de `Tab`-node**
|
|
|
+ (zie `CLAUDE.md`, al gebruikt op Favorieten Tab 1). Recept om
|
|
|
+ hetzelfde hier toe te passen: (1) een Page/Component State-flag
|
|
|
+ per tab (bv. `tabNGeladen`, default `false`, tab 0 default
|
|
|
+ `true` want die is al zichtbaar bij page-load); (2) elke
|
|
|
+ tab-content wrappen in een `ConditionalBuilder` op die flag
|
|
|
+ (Else-tak: lege/loading-placeholder); (3) op elke `Tab`-node
|
|
|
+ (niet de `TabBar` zelf) een On Tap-actie die de eigen flag op
|
|
|
+ `true` zet. Mechanisch herhaalbaar over de 5+6+6+6 = 23
|
|
|
+ tab-content-plekken, geen structurele widget-tree-herbouw. Nog
|
|
|
+ niet uitgevoerd/besproken met Bob — dit is puur de
|
|
|
+ bouwrichting, geen aangenomen taak.
|
|
|
- Bijvangst tijdens de audit: dode `EstablishmentsNewCall` verplaatst
|
|
|
naar de P2-7-opschoonlijst.
|
|
|
|
