|
|
@@ -4039,6 +4039,40 @@ null`**; staat die er niet, dan heb je de verkeerde route genomen. En let op: de
|
|
|
lukt dat na een paar pogingen niet, dan is dit een taak voor Bob's eigen browser
|
|
|
in plaats van een reden om de bovenstaande snelle route te nemen.
|
|
|
|
|
|
+**Een blok tonen/verbergen op "heeft de gebruiker items X?" waarvan de data in
|
|
|
+een SIBLING-FutureBuilder zit: page state van het type JSON + Is List, en dan
|
|
|
+"Is Set and Not Empty" als conditie.** Volledig gelukt 2026-09-20 op `mijnProfiel`
|
|
|
+(het evenementenblok alleen tonen aan wie een horecagelegenheid heeft). Het
|
|
|
+probleem: de lijst met zaken hangt aan een Backend Query op een ListView, en die
|
|
|
+respons is buiten die eigen subtree niet leesbaar — een blok erboven kan er dus
|
|
|
+niet op conditioneren. Werkende keten, geen custom function en geen Single
|
|
|
+Condition nodig:
|
|
|
+1. pagina-root → State Management → **+ Add Field**, Type **JSON** met **Is List**
|
|
|
+ aan (een List-typed page state krijgt in de Set-from-Variable-dialoog de
|
|
|
+ lijst-transforms, net als een App State-lijst);
|
|
|
+2. **On Page Load** → *Backend Call* naar hetzelfde endpoint → *Update Page State*
|
|
|
+ met **Action Outputs → JSON Body → No Further Changes**. Doe die tweede actie in
|
|
|
+ de **Action Flow Editor** (knop *Edit*, dan het `|<` om de trigger-kolom in te
|
|
|
+ klappen) — in het compacte Actions-paneel reageert het Value-veld niet;
|
|
|
+3. per te verbergen widget: Visibility → Conditional → bron = die page state →
|
|
|
+ Available Options → **Is Set and Not Empty**. Levert
|
|
|
+ `if (_model.veld.isNotEmpty)`.
|
|
|
+Kost één extra GET, maar je verdient 'm terug: een verborgen `FutureBuilder`
|
|
|
+wordt niet gebouwd, dus de call van het verborgen blok vertrekt ook niet meer.
|
|
|
+On Page Load draait ná de eerste build, dus het blok begint verborgen en
|
|
|
+verschijnt — dat is de goede richting voor dit soort guards.
|
|
|
+
|
|
|
+**Controleer een vertaalronde met een DIFF tussen twee exports, niet met een grep
|
|
|
+op de nieuwe waarde.** Bevestigd 2026-09-20: een `Bekijk alles`-knop moest van
|
|
|
+`+ Add` naar `See all`, en de wijziging landde op de knop van de *andere* tab —
|
|
|
+beide sleutels hadden dezelfde Nederlandse tekst en dezelfde foute Engelse. Een
|
|
|
+grep op "staat `See all` er?" had dat "ja" genoemd. Bewaar dus de exportmap van
|
|
|
+vóór de ronde en draai
|
|
|
+`diff <oud>/lib/flutter_flow/internationalization.dart <nieuw>/...` — dat toont in
|
|
|
+één keer wélke sleutels echt veranderd zijn, inclusief de wijzigingen die je niet
|
|
|
+gevraagd had. Zelfde diff verraadt ook nieuwe dode kopieën: een gedupliceerde
|
|
|
+pagina/component duikt op als een compleet nieuw blok met `// <naam>Copy<N>`.
|
|
|
+
|
|
|
**Een widget kan zijn EIGEN Backend-Query-response niet gebruiken in
|
|
|
zijn eigen Visibility-conditie — wel in zijn Options.** De
|
|
|
Set-from-Variable-dialoog toont die response daar simpelweg niet als
|
