A React submit flow uses a reducer whose switch is on action.type alone. A user double-clicks Submit, so a second SUBMIT arrives while the request is already in flight. How do you structure the reducer so only transitions that are legal from the current state are applied?

## Action-first reducers have no notion of legality The reflex shape for a reducer is a `switch (action.type)`. It reads well and it is fine while the flow is linear, but it encodes exactly one rule: *this action always does this*. Nothing in it says a SUBMIT is only meaningful from `idle`, or that a RESOLVE arriving in `idle` is a mistake. Every action is accepted from every state. That is what makes the double-click bug possible. The button dispatches SUBMIT twice before the first render that would disable it commits; the reducer happily produces `submitting` twice; whatever the component does in response to entering `submitting` runs twice. ## State-first: make the transition a function of both A state machine's transition function takes the current state *and* the event. Mirror that in the reducer by making the state the outer switch: ```typescript function reducer(state: State, action: Action): State { switch (state.status) { case 'idle': return action.type === 'SUBMIT' ? { status: 'submitting' } : state; case 'submitting': if (action.type === 'RESOLVE') return { status: 'succeeded', id: action.id }; if (action.type === 'REJECT') return { status: 'failed', error: action.error }; return state; case 'succeeded': return action.type === 'RESET' ? { status: 'idle' } : state; case 'failed': if (action.type === 'SUBMIT') return { status: 'submitting' }; if (action.type === 'RESET') return { status: 'idle' }; return state; } } ``` The second SUBMIT lands in the `submitting` case, matches nothing, and returns the identical state object. Returning the *same reference* matters: React bails out of re-rendering when a `useReducer` state is unchanged by `Object.is`, so ignoring an illegal action costs nothing. Read the code above as a specification and you can see the legal graph without running it. That is the real deliverable — the reducer now documents which sequences are possible. ## The transition table Once there are more than four or five states, the nested conditionals get noisy and the graph stops being visible. Lift it into data: ```typescript const transitions = { idle: { SUBMIT: 'submitting' }, submitting: { RESOLVE: 'succeeded', REJECT: 'failed' }, succeeded: { RESET: 'idle' }, failed: { SUBMIT: 'submitting', RESET: 'idle' }, } as const; ``` The reducer becomes a lookup: find the next status for this state and action, and if there is none, stay put. A table has properties nested `if`s do not. It is enumerable, so you can assert in a test that no state can reach `succeeded` except from `submitting`. It is reviewable, because adding a transition is a one-line diff in a place reviewers can see whole. And it separates *whether* a transition is legal from *what data* the new state carries, which is usually a small per-transition function applied after the lookup. ## Guards Some transitions are legal only under a condition — a WIZARD_NEXT from `step2` only when the form is valid. That is a guard: a predicate evaluated during the transition. In a hand-written reducer it is an `if` inside the matching case; in a table it is a small function stored beside the target state. What it must not become is a check at the call site, because then the rule lives wherever somebody happened to dispatch from, and the next call site will forget it. ## Where this leaves the UI Disabling the Submit button while `status === 'submitting'` is still correct and still worth doing — it tells the user what is happening. But treat it as presentation. The button is one of several dispatchers (an Enter keypress, a retry link, a parent effect), and a machine that only holds because one particular control was greyed out is not guarded at all. Push the rule down into the transition function and every dispatcher inherits it. One dev-only refinement: rather than silently returning `state`, log the rejected pair in development. A quiet ignore is right in production, but during development "REJECT arrived while idle" is a genuine signal that some caller is out of step with the flow, and you want to see it rather than have it swallowed. ## What it does not fix Guarding transitions constrains what the *state* can do; it does not by itself stop work that was already started from finishing. The machine can ignore a late RESOLVE, which is usually the outcome you want, but the ignored action is a hint that the flow needs a cancellation story too. Keep the two concerns separate: legality of transitions in the reducer, lifecycle of the in-flight work where that work is started.