useReducer Patterns and Action Design

## What "pure" means here A pure reducer satisfies two properties. It is **deterministic**: the same `(state, action)` pair always yields the same result. And it has **no observable side effects**: calling it changes nothing outside itself — no network requests, no `localStorage` writes, no DOM touching, no mutation of the objects it was handed. ```js // pure function reducer(state, action) { switch (action.type) { case 'added': return { ...state, items: [...state.items, action.item] }; default: return state; } } ``` ## Why React requires it **Reducers run during the render phase.** When you call `dispatch`, React does not immediately compute the new state; it queues the action and runs your reducer while rendering the component. The render phase is the phase React reserves the right to run repeatedly, discard, or (with concurrent rendering) interrupt and restart. Anything you do in there may therefore happen more than once, or happen for a render whose output is thrown away. **React actively double-invokes reducers in development.** In Strict Mode, React calls reducers and initializer functions twice during development renders precisely so impurity shows up as a visible bug on your machine rather than a rare one in production. A reducer that pushes an analytics event will fire it twice; a reducer that increments a module-level counter will jump by two. **Mutation defeats the bail-out check.** React compares the value the reducer returned with the previous state using `Object.is`. If you mutate the existing object and return it, the comparison says "same value" and React can skip re-rendering that component. The state "changed" but nothing on screen moved — one of the most confusing bugs in React, and it is caused purely by mutating: ```js // broken: same reference back case 'added': state.items.push(action.item); return state; // Object.is(prev, next) === true -> possible bail-out ``` **Determinism is what makes reducers testable and replayable.** The whole benefit of extracting transitions into a reducer is that you can assert `reducer(before, action) === after` with no rendering. A reducer that reads `Date.now()`, `Math.random()`, or a module-level variable cannot be asserted on and cannot be replayed from a log of actions. ## Where the effects go instead The rule of thumb: the reducer decides *what the state becomes*; something else decides *what happens in the world*. - **Caused by a user interaction → the event handler.** Fire-and-forget work triggered by a click belongs next to the dispatch, not inside the reducer: ```js function onSubmit() { analytics.track('submitted'); // effect, in the handler dispatch({ type: 'submitted' }); // pure state transition } ``` - **Needs to stay in sync with the resulting state → an effect.** If the requirement is "whenever status becomes `loading`, start the request", that is a synchronization concern and belongs in `useEffect` keyed on `state.status`, with the appropriate cleanup. - **Non-deterministic values → compute them outside and put them in the action payload.** This is the standard workaround for IDs and timestamps: the reducer stays pure and the impurity is captured once, in the handler. ```js dispatch({ type: 'added', id: crypto.randomUUID(), at: Date.now() }); ``` Now the reducer just reads `action.id` and `action.at`, and a test can supply fixed values. ## Common impurities to name in an interview - `fetch` / any network call - `localStorage`, `sessionStorage`, cookie writes - `console.log` used as production logging, analytics events - `Date.now()`, `new Date()`, `Math.random()`, `crypto.randomUUID()` - reading or writing a variable declared outside the reducer - mutating `state`, `action`, or any nested object reachable from them - dispatching another action from inside the reducer ## A note on "but it works" Impure reducers frequently appear to work, because in a simple app the reducer happens to run exactly once per dispatch. That is not a guarantee React makes. The double-invocation in development is the cheap warning; concurrent rendering behaviour is the expensive one. Treat "it worked in my test" as luck, not as evidence.