fw-04 step 03 — Tearing, batching, and whether it was worth it

Goal

Meet the bug the reference implementation of this spec actually had, then decide honestly when time-slicing helps.

Tasks

  1. Batching. Multiple setState in one tick must coalesce into one render (stage 8).
  2. Tearing. Get stage 11 green. Expect to fail it first: if a same-priority update arriving mid-render lets in-flight work continue, your commit mixes components that saw old state with ones that saw new. Restart on any new update — and note that this is only legal because render is pure.
  3. Read external mutable state at two points in one interruptible render, mutating between. Reproduce the inconsistency, then evaluate the useSyncExternalStore shape of fix.
  4. Starvation. Continuously schedule high-priority updates; watch low-priority work never complete. Design the escalation rule; compare with Chromium's anti-starvation (bi-11).
  5. The honest measurement. Measure p75 input delay under load, recursive vs interruptible. Then measure total wall-clock. State the conditions under which time-slicing helps, and the conditions under which reducing work would have been the better fix.

Done when

  • 6/6 passing, tearing included
  • Starvation reproduced and bounded
  • Input-delay and wall-clock numbers for both renderers
  • Notebook entry: Fiber — the flagship entry