In React, what signals tell you a component should move from several useState calls to a single useReducer, and what do you actually gain by doing it?

## The real difference: where update logic lives Both `useState` and `useReducer` store state in the same place — React's hook list for that component instance. The difference is architectural, not mechanical. With `useState`, the logic that computes the next state is scattered across the event handlers that call the setters. With `useReducer`, the handlers describe *what happened* and a single function decides what the state becomes: ```js const [state, dispatch] = useReducer(reducer, { status: 'idle', data: null, error: null }); // handler onClick={() => dispatch({ type: 'submitted' })} ``` The component gets smaller and more declarative; the state logic gets concentrated and testable. ## The signals that justify the move **1. Fields that change together.** This is the strongest signal. Three `useState` calls for `status`, `data` and `error` mean every handler must remember to update all three in the right combination. Miss one and you render a combination that should not exist — an error message next to a spinner, or stale data under a fresh error. A reducer writes the whole next state in one place, so each transition is exhaustive by construction: ```js function reducer(state, action) { switch (action.type) { case 'submitted': return { status: 'loading', data: null, error: null }; case 'succeeded': return { status: 'success', data: action.payload, error: null }; case 'failed': return { status: 'error', data: null, error: action.error }; default: return state; } } ``` **2. The next state depends on the previous one in a non-trivial way.** A counter is fine with `setCount(c => c + 1)`. But "add this item unless it is already in the cart, in which case bump its quantity and recompute the total" is a transition, and transitions read better as a named action than as three chained updater callbacks. **3. The same update appears in several handlers.** If `handleCancel`, `handleEscape` and `handleBackdropClick` all run the same four setter calls, that repetition is a reducer case waiting to be named `'dismissed'`. **4. You want to test the logic without rendering.** A reducer is an ordinary function of `(state, action) -> state`. You can assert on it directly, with no component, no DOM, and no act-like ceremony: ```js expect(reducer({ status: 'idle' }, { type: 'submitted' }).status).toBe('loading'); ``` **5. You are passing a fistful of callbacks down the tree.** Handing children a single `dispatch` is usually cleaner than five `useCallback`-wrapped setters, and `dispatch` is stable so it never invalidates a memoized child. ## What you gain - **One pure transition function.** All the rules live in one switch, reviewable in one screen. - **Named events instead of anonymous writes.** `{ type: 'retried' }` says more in a stack trace, a log, or a React DevTools inspection than `setStatus('loading')`. - **A stable `dispatch`.** React guarantees the dispatch function's identity does not change across re-renders of that component, so it is safe to pass down and safe to omit from dependency arrays. - **Testability.** Plain-function tests cover the state rules; component tests then only need to cover wiring. ## What you do NOT gain (the common wrong answers) - **Not fewer re-renders.** One `dispatch` produces one update, but React already batches multiple state updates that happen in the same event, so three setters in one handler were already one render. Switching for performance reasons is a misdiagnosis. - **Not global state.** The state still lives in the component that called `useReducer`. Sharing it across the tree still requires putting it in context or an external store — the reducer alone changes nothing about scope. - **Not an escape from immutability.** The reducer must return a new object rather than mutating, exactly as a `useState` updater must. ## When `useState` is still the right answer Independent, small, unrelated values — an input's text, a disclosure's open flag, a hovered index. Wrapping two booleans that never interact in a reducer adds indirection (an action type, a switch case, a file) and buys nothing. The honest heuristic: start with `useState`, and move to `useReducer` the moment a handler starts coordinating several pieces of state at once.