Widget State

This page explains which interaction states runtime continuity preserves and why that matters.

If you have not read the internals pages yet, start with:

What continuity preserves today

Runtime continuity currently preserves these RuntimeWidgetState variants:

This is what keeps subtree replacement and full rerendering from resetting interaction state back to defaults.

Input continuity preserves the cursor position, not the input string itself.


RuntimeWidgetState::InputCursor(cursor)

The string is still your app state or local signal. Continuity exists so the cursor does not jump back to the beginning after rerender.

List preserves the selected item:


ListState::default().with_selected(Some(2))

When the user moves selection and a rerender happens, runtime reconnects that interaction state.

Table has a richer shape than List:

That is why continuity matters more here: a table can lose both selection and viewport position if the state shape is not preserved.

Tabs preserves the runtime-managed selected tab.

If you pass selected(...), that is controlled state. If you do not, runtime keeps the user’s current tab stable across rerenders.

Scrolling widgets preserve position:

That is what lets shared scroll state, redraw, and continuity work together.

When you design a new interactive widget, ask:

If the answer is yes, it probably belongs in the continuity contract instead of living only in transient node state.

These usually should not become RuntimeWidgetState:

Put differently: