Why Batch Belongs to the Scheduler, Not Computed

Recap Building on the previous articles— signal , effect , and computed —we have already made the timing of side-effect execution much more controllable: Multiple set() calls are merged → an effect reruns only once per flush cycle Updating multiple signals in one block → avoids intermediate “flickering” states Reading inside a block always returns the latest value (because set() writes synchronously, and computed recomputes lazily on get() ) Why Do We Need batch ? A key design principle here is: computed stays lazy. batch / transaction only adjust effect scheduling (push merging). They never force eager recomputation. In other words: computed decides when to compute batch decides when side effects run Design Approach We modularize scheduling logic into a dedicated scheduler module to handle: Deduplication Microtask merging Batching flushSync support Components scheduler.ts : A minimal scheduler (dedupe, microtask merging, batch / flushSync support) batch(fn) : Wraps a sequence of updat