Why can an assertion made immediately after a state write in a component test still read the previous rendered output?

## A write is a request, not a render Every mainstream component framework separates *deciding that output is stale* from *producing new output*. A state write marks the owning scope dirty and hands work to a scheduler; the scheduler applies a batch at a point of its own choosing. Nothing about the host changes at the moment of the write. That is invisible in an application, because the user only ever sees the committed result. In a test it is the single most common source of confusion, because the test reads the host on the very next line — inside the same task, before the scheduler has run anything. ``` state count = 0 // test: write count = 1 // queues work; host untouched assert text == '1' // still reads '0' settle() // scheduler applies the batch assert text == '1' // now true ``` ## Why frameworks batch at all Batching is not a test artefact; it is what makes normal interaction cheap. - A single handler often writes several pieces of state. Rendering after each one would produce intermediate output nobody should ever see. - Coalescing lets the framework render each affected component **once** per batch instead of once per write. - Deferring the commit lets the framework order work — higher-priority updates first, lower-priority ones later — which only has meaning if the commit is not immediate. So a test that wants the post-write output has to cooperate with the scheduler rather than assume it away. ## The settle step, and the shapes it takes **Settling** means: run the framework's queued work to completion so the host reflects the current state. Frameworks expose that in different shapes, and this is where the contrast between reactivity models shows. | Shape | What the test does | Why it works | | --- | --- | --- | | Await a tick | yield once so pending microtasks drain | the framework's queue is itself scheduled as a microtask, so yielding lets it run | | Explicit flush | call the framework's flush entry point | the queue is drained synchronously, so the next line sees committed output | | Harness wrapper | write or interact through a helper | the helper flushes around the call, so tests never settle by hand | Frameworks genuinely differ here: a runtime that re-runs the whole component function usually batches into a microtask and warns when a write happens outside its wrapper; a runtime with fine-grained dependency tracking may apply the write to its graph immediately and only defer the host commit; a compile-time runtime schedules the commit itself and gives tests a promise to await. The mechanism is the same — queue, then apply — while the primitive that drains the queue is not. ## Why a fixed wait is the wrong tool Waiting a chosen number of milliseconds looks like it works and is a trap: 1. It encodes a guess about how long the queue takes on this machine today. 2. It passes locally and fails on a loaded shared runner, which is the classic intermittent failure. 3. It slows every run, including the overwhelming majority where the queue drained instantly. 4. When it fails, the message says only that the element was absent — it points nowhere near the scheduler. The settle primitive returns when the queue is actually empty. It is both faster and deterministic. ## Why a ported test breaks here first Because the write-then-assert line is the one place a test depends on the runtime's scheduling contract rather than on its own logic. Move the same body to another framework and the flush disappears or changes form: the awaited tick that used to be enough no longer drains an explicitly-flushed queue, or the harness that used to wrap writes is not there. The test looks framework-agnostic and is not. ## What settling does not do - It does not dispatch events for you — driving an interaction is a separate step, and settling only applies what that step queued. - It does not make a host measure anything; a host with no layout engine still answers geometry queries with stubs. - It does not conjure output that was never queued. If the queue was empty, the write never happened, or it happened on a different state holder than the one the tree reads. The practical rule is short: **after anything that can change state, settle before you assert** — and when a test is intermittently green, check the settle step before you blame the runner.