d-for inside d-if renders empty when data storage loads before the condition becomes true

[silvath]

Problem

When a \d-for\ loop is inside a \d-if\ section and the bound data storage loads before the \d-if\ condition becomes \ rue\ (e.g., waiting for an auth check), the list renders empty — even though the data is already available in storage.

Why it happens

Drapo initializes all \d-dataKey\ storages at page startup, including those inside \d-if\ sections that are currently hidden (condition is \alse). The storages fetch their data via \d-dataUrlGet, receive responses, and are populated.

Later, when the \d-if\ condition becomes \ rue\ and Drapo inserts the section's DOM elements, the \d-for\ renders an empty initial snapshot — it does not read the already-populated storage value. Subsequent explicit \ReloadData()\ calls work correctly, but the initial render on first view is blank.

Common scenario

Authentication-gated dashboards:

\\html

...

\\\

Result: the table is empty on first load. Clicking away and back (triggering \ReloadData) makes data appear — confirming the data is there but the initial \d-for\ render missed it.

Fix

Move the data storage definitions inside the \d-if\ section. Drapo will then initialize them only when the section becomes visible, ensuring \d-for\ renders with fresh data:

\\html

<!-- d-for now renders correctly on first view -->
<tr d-for='item in items'>...</tr>

\\\

Suggested doc addition

A note in the \d-for\ or \d-if\ docs:

Data loading and d-if: All \d-dataKey\ storages initialize at page startup, even if they are inside a hidden \d-if\ section. If a \d-for\ inside a \d-if\ section needs to render data that depends on the \d-if\ condition being true (e.g., after authentication), place the storage definition inside the \d-if\ section. This ensures the storage loads after the section becomes visible, so \d-for\ receives the data on initial render.