In a store with unidirectional flow, what does routing a change through an action and an applier buy over direct assignment?

## The shape of the flow Unidirectional flow describes a loop with one direction of travel. Something in the tree — an event handler, an effect, another store — **dispatches an action**: a value that names the change and carries the data it needs. The store applies that action in exactly one place, producing the next state. Only then does it notify subscribers. Each subscriber re-reads, and the components whose slice moved update. Nothing writes state on the way down; nothing observes half-applied state on the way back. The contrast is a store that simply exposes its fields for assignment. That also works, and for one value with one writer it is the better choice. The argument for the extra machinery is about what happens when there are twenty values and forty call sites. ## Why the change gets a name An action is a *description* of a change, separate from the code that performs it. That separation is what the other benefits hang from: - **Traceability.** Every mutation arrives through one funnel with a name and a payload, so "why is this field wrong" becomes a readable ordered list rather than a hunt for assignments. - **One place for invariants.** Rules that span fields — a selection must be cleared when the list it points into is replaced — live in the applier instead of at whichever call sites remembered them. - **A testable write path.** The applier is a function from a state and an action to a state, so the whole behaviour can be exercised with plain values and no component tree. - **A stable vocabulary.** Call sites express intent rather than mechanics, so changing the state's representation does not touch them. | | Direct assignment | One action, one applier | |---|---|---| | Where a change is expressed | at each call site | as a named value | | Where invariants live | wherever the author remembered | in the applier | | A change touching several fields | several writes, several notifications | one apply, one notification | | Testing the write path | needs the caller | plain input, plain output | | Cost | none | ceremony per change | ## Two ways to apply an action Stores diverge on the applier. Some use a **pure function** of the previous state and the action that returns the next state without touching the old one. Others let the action mutate a tracked draft and derive the next state from the recorded writes. The mechanics differ; the discipline is identical — one entry point, one place to look, and a step that completes before anyone is told. Where the pure form differs in practice is **replay**: a deterministic applier can be re-run over a recorded list of actions and must produce the same states, which is what makes an action log useful while debugging. The purity that matters is narrow: the applier must not perform effects. A network call, a timer or a freshly read clock inside it makes the same action produce different states, and it drops work into a function the store calls while deciding what to notify. Asynchronous work stays outside: dispatch one action when it starts and another when it settles, and let the store hold status and result. ## Notification comes after, and once The most practical property of the flow is the ordering: the apply step finishes before the first listener runs. So a change touching several fields is never observed half-done, and a subscriber reading two related fields cannot render a pair that never legitimately existed. Two separate setters give that up — each notifies, and between them the state is briefly incoherent — unless the store batches, which is the same guarantee reached the long way round. One direction also disciplines **reentrancy**. If a listener dispatches during notification, the store has a defined answer — queue it, or apply it after the current pass completes — because there is a single place where application happens. With scattered assignment there is nothing to queue. ## What it does not buy - It does not make anything faster: there is an allocation and a dispatch per change. - It does not decide which subscribers wake; that is the reading side's comparison against its previous selected value. - It does not make asynchronous flow simple by itself; that still needs a start/settle pair and a status field. - It does not prevent a badly shaped state; an applier can enforce invariants only over fields it owns. ## When to skip the ceremony Skip it when the store holds one value with one writer, when the write surface is a single setter that cannot break an invariant, or when the store is created with a screen and thrown away with it. Adopt it when several unrelated call sites write the same state, when invariants span fields, or when you need to answer "what changed this, and in what order" after the fact. The decision is about the number of writers and the reach of the invariants, not about the size of the state.