Module: lib/core/renderer/program/TemplateInstance

One mounted copy of a render program, and the effects that keep it in step with state.

What replaces the update cycle

The string renderer had a single reactive unit per component. Any dependency of any binding woke it, and waking it meant re-rendering, re-parsing and re-diffing the whole template. Change one cell in a table and the framework did work proportional to the table.

Here each op is its own reactive unit. A binding's effect reads exactly the state its expression names, so a write wakes only the bindings that read it and each of those writes to exactly one node. Changing one cell costs one expression evaluation and one DOM write, whatever else the template contains.

Why the effects are lazy with a queueing callback

The obvious construction -- a plain effect that re-applies on every write -- would update the DOM synchronously inside the assignment. That is faster to write and changes observable behaviour: $nextTick would resolve after the DOM had already been touched, and an action making three writes to one value would produce three DOM writes.

So each binding uses the same shape the component's render watcher used: a lazy watcher whose callback queues a job. Writes still coalesce into one microtask flush, $nextTick still means "after the DOM has settled", and the only thing that changed is how much work the flush does.

Errors and suspension

A binding that throws does not take its siblings with it -- the rest of the template still updates, and the failure is reported once with the expression that caused it. A binding that throws a Promise is a resource read under Suspense, which is not an error: it is handed to the owner so the component can suspend as it did before.