Techniques
Data refresh — swapping records without breaking the view
A chart whose data block is swapped wholesale — new records, same keys, same bindings — plus the dependency graph reading of the same model.
chart.basic@1New DDN source
Why use it?
Refreshes are the normal case, not the exception: a view that breaks on new data was wired to the data, not the contract.
When it helps
Operational dashboards, periodic re-publication, any view fed by a changing extract.
How to read it
- The chart re-renders from the swapped records; bindings follow keys, not positions.
- The variant shows the model behind the refresh — the dependency graph does not change when only values do.
What you need
- The data block with stable keys
- The projection bindings
- The refresh payload
Things to check
- Do not change the key space in a refresh without migrating the bindings.
- A refresh that changes shape (fields, not values) is a schema change — version it.
Scope of this diagram
Record-swap refresh through the declared block; streaming or incremental updates are a host concern.
Work with the converted example
- Open the viewer and select
latency_chart. Inspect the rendered view and its source. - Open the designer. Keep the selected profile and inspect its legal palette and property controls.
- Change one displayed title or an appropriate data value. Apply the edit and check the resulting diagram.
- Run the verifier and review its diagnostics before moving complete content into review.
- Download your edited DDN source to retain the change.
The example uses the indentation-based ddn-next-1 dialect. The language guide explains reusable definitions, dotted data rows and explicit property blocks.