Render ownership and subscriptions
Use one writer for each kind of state:
application data ──> framework ──> which item children exist
mounted elements ──> core ──────> sizes, offsets, transforms, scrollbarThe framework owns item content and keyed reconciliation. Core owns virtual geometry after layout elements attach. This prevents a delayed framework commit from replacing newer geometry calculated during scrolling or measurement.
What causes a framework update
| Change | Framework work | Core work |
|---|---|---|
from or to changed | Reconcile item children | Publish RANGE |
| An attached item changed size | None if the range is unchanged | Update cached sizes and positions |
| Total item extent changed | None | Resize the native size element |
| Rendered block moved | None | Update its transform |
The normal list APIs already apply this boundary. Do not subscribe the complete
page merely to render model.from through model.to.
Subscribe at the smallest consumer
Use the adapter’s snapshot primitive only in the component or computation that
reads the selected state. Select VirtualScrollerEvent.RANGE for item children;
select size events only for a consumer that displays or exports those values.
The examples show independent range and scroll-size consumers in framework-native syntax. Their source is the canonical subscription recipe.
Prefer imperative consumers for imperative output
A canvas, CSS variable, external widget, or manually managed spacer does not need a framework render merely to receive a number. Subscribe through
model.subscribe()
or the adapter’s effect primitive, update that owner directly, and clean up at the same lifecycle boundary.
Keep presentation separate from geometry
Applications still own dimensions, borders, colors, typography, and other presentation. Do not reapply core-owned height, width, position, or transform properties from reactive templates. The ownership of each element is shown in how virtual layout works.