Reactive Graph vs UI Tree

Ansiq intentionally keeps two different graphs:

the reactive dependency graph
the UI tree

This is one of the most important separations in the design.

The previous page already explained the reactive graph itself:

signal
computed
effect
how dirty scopes are produced

So this page does not repeat that material. Its real question is:

once the runtime knows what became dirty, why does it still need a separate UI tree?

What the UI tree is for

The UI tree answers:

which nodes currently exist
where they are laid out
which subtree should be replaced
which regions should be redrawn

In other words, it answers:

How should the terminal be updated?

So the split is:

the reactive graph answers “what became dirty?”
the UI tree answers “how should the screen change?”

Why Ansiq keeps this as a two-stage model

At the smallest useful level, Ansiq’s update story is:

Stage 1: reactive propagation

Answer:

which signal changed
which scopes became dirty

Stage 2: runtime update

Answer:

which subtree rerenders
which ancestors relayout
which regions redraw
which terminal patches are emitted

Without that boundary, systems quickly drift into confusion:

the dependency layer starts making layout decisions
widgets start making patch decisions
the runtime stops being the single coordinator

Why not merge them

If you merge these responsibilities too deeply:

debugging gets harder
runtime logic and component logic contaminate each other
local update optimization becomes harder to reason about

Ansiq’s runtime maturity depends on keeping this separation stable.

A simple mental model

You can compress the whole story into one chain:


signal/computed change
-> dependency graph marks scopes dirty
-> runtime collects dirty scopes
-> subtree rerender
-> partial relayout
-> terminal patch

The dependency graph should not start behaving like a renderer, and the renderer should not start behaving like a dependency graph.

Why this split also helps debugging

This boundary is not only architectural hygiene. It directly affects debugging quality.

When something goes wrong, you can ask:

is dependency propagation wrong?
is dirty scope collection wrong?
is subtree replacement / relayout / redraw wrong?

If the reactive graph and UI tree were deeply merged, those questions would collapse into one opaque failure mode.

That is why Ansiq keeps repeating the same rule:

reactive graph is one layer
UI tree is another
the runtime loop coordinates between them

Where to go next

Continue with: