useReducer in React: When It Beats useState

Every React codebase eventually grows a component like this: six calls to useState at the top, and a handful of event handlers that each have to update three of them in the right order. It works until someone adds a seventh, forgets to reset the second, and the UI ends up in a state that should not be possible.

useReducer is the built-in fix. It is not a smaller Redux and it is not for "complex state" in the vague sense people usually mean. It is for state where the transitions matter as much as the values.

What is a reducer?

A reducer is a plain function that takes the current state and an action, and returns the next state. No React in it, no hooks, nothing async.

That definition is worth taking literally, because everything else follows from it. The useReducer referencedocuments the hook, but the property that matters is inherited from the plain function underneath: the same state and the same action produce the same result every time, with no way for the outside world to interfere.

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'increment':
      return { ...state, count: state.count + 1 };
    case 'reset':
      return { ...state, count: 0 };
    default:
      return state;
  }
}

useReducer takes that function and an initial state, and hands back the current state plus a dispatch function for sending actions to it.

const [state, dispatch] = useReducer(reducer, { count: 0 });

<button onClick={() => dispatch({ type: 'increment' })}>+1</button>

The component no longer describes how state changes. It describes what happened, and the reducer decides what that means. That indirection is the entire trade: you give up locality to gain a single place where every transition is written down.

useReducer vs useState

Both are the same feature underneath. useState is implemented in terms of useReducer inside React. So the question is never capability, it is which one makes the code easier to get right.

The row I care most about is the last one, and it deserves its own example.

Making impossible states impossible

Here is the pattern that made me change how I write async UI. The obvious version, with a state per concern:

const [loading, setLoading] = useState(false);
const [error, setError] = useState<string | null>(null);
const [data, setData] = useState<User | null>(null);

Three booleans-worth of state means eight combinations, and only three of them are meaningful. Nothing stops loading being true while error is set and data is stale, and every handler has to remember to clear the other two. The bug is always the same: an error stays on screen after a successful retry, because the success path set data and forgot setError(null).

A reducer over a union type lets you write down only the states that exist:

type State =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; user: User }
  | { status: 'error'; message: string };

type Action =
  | { type: 'fetch' }
  | { type: 'resolved'; user: User }
  | { type: 'rejected'; message: string };

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'fetch':
      return { status: 'loading' };
    case 'resolved':
      return { status: 'success', user: action.user };
    case 'rejected':
      return { status: 'error', message: action.message };
  }
}

Each case returns a complete new state rather than patching the old one, so there is no stale field to forget. And because the union is discriminated on status, TypeScript narrows it in the JSX:

function Profile() {
  const [state, dispatch] = useReducer(reducer, { status: 'idle' });

  if (state.status === 'loading') return <Spinner />;
  if (state.status === 'error') return <Error message={state.message} />;
  if (state.status === 'success') return <Card user={state.user} />;
  return <button onClick={() => dispatch({ type: 'fetch' })}>Load</button>;
}

Reading state.user in the error branch is now a compile error rather than a runtime one. The union types doing that work are the same feature I covered in React and TypeScript, and this is the highest-value place to use them.

Reducers have to be pure

A reducer takes state and an action and returns new state. That is the whole contract. No fetch calls, no localStorage writes, no Math.random(), no mutation of the state you were given.

// Broken: mutates the existing state object.
case 'add':
  state.items.push(action.item);   // React may not see a change at all
  return state;

// Correct: returns a new object.
case 'add':
  return { ...state, items: [...state.items, action.item] };

The mutating version fails in a specific and confusing way. React compares the returned state to the previous one, sees the same reference, and skips the re-render. The data changed and the screen did not. Because Strict Mode calls your reducer twice in development, a mutating reducer also produces doubled results, so you might see an item added twice locally and once in production. If either symptom shows up, look for a mutation before you look anywhere else.

The third argument nobody uses

useReducer takes an optional lazy initialiser. It matters when building the initial state is expensive, because the second argument is evaluated on every render even though only the first result is used.

// Runs JSON.parse on every render and throws the result away.
useReducer(reducer, JSON.parse(localStorage.getItem('draft') ?? '{}'));

// Runs once, on mount.
function init(key: string): State {
  return JSON.parse(localStorage.getItem(key) ?? '{}');
}
useReducer(reducer, 'draft', init);

It is also the clean way to implement a reset: keep the same init function and call it from a 'reset' action, so the initial state is defined in exactly one place.

Name actions after events, not setters

The single biggest difference between a reducer that helps and one that is just a switch statement is how the actions are named. Most first attempts look like this:

dispatch({ type: 'setLoading', value: true });
dispatch({ type: 'setError', value: null });
dispatch({ type: 'setUser', value: user });

That is three setters with extra steps. The caller still knows the shape of the state, still has to remember the order, and still has to remember to clear the error. Every problem useReducer was supposed to solve is intact.

Name the action after the thing that happened in the UI instead:

dispatch({ type: 'submitted' });
dispatch({ type: 'serverRejected', message: 'Email already in use' });
dispatch({ type: 'retryClicked' });

Now the reducer owns the consequences. "Submitted" means clear the error, set status to loading and disable the button, and it means that in one place rather than at every call site. When a designer asks for the form to also scroll to the top on submit, there is one obvious function to change.

A useful test: if you renamed the state fields, how many action types would you have to rename? With event-shaped actions the answer is zero. With setter-shaped actions it is all of them, which tells you the abstraction was not doing anything.

Reducers and Context

The combination people reach for next is a reducer at the top of a subtree with the state and dispatch handed down through Context. It is a reasonable pattern and it has one property worth knowing about: dispatch is referentially stable for the life of the component, so consumers that only dispatch never need to re-render when the state changes.

// Two contexts, so components that only dispatch do not re-render
// every time the state changes.
const StateContext = createContext<State | undefined>(undefined);
const DispatchContext = createContext<Dispatch<Action> | undefined>(undefined);

export function CartProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <StateContext.Provider value={state}>
      <DispatchContext.Provider value={dispatch}>
        {children}
      </DispatchContext.Provider>
    </StateContext.Provider>
  );
}

Splitting the two is the point. Put state and dispatch in one object and every consumer re-renders on every change, including the buttons that only ever send actions. This is the re-render trap I described in the React Context API guide, and a reducer makes it unusually easy to avoid because dispatch is already stable.

Where does this stop being enough?

Reducer plus Context is not a state management library, and pretending otherwise leads somewhere unpleasant. What it does not give you: selective subscriptions, so any consumer of the state context re-renders on any change; devtools with a readable action log; middleware; or anything for server state, caching and revalidation.

My rough boundary is the subtree. A reducer owning one feature's state, a checkout flow, a multi-step form, a canvas editor's undo stack, is a good fit and I would not add a dependency for it. State that the whole application reads and writes wants a real store. Zustand takes about the same amount of code and gives you selectors, which is the thing Context cannot do. I compared the options in React state management.

Server data is a separate question again, and neither a reducer nor a store is the right shape for it. If your reducer's action types are mostly fetch, resolved and rejected, you are hand-rolling a cache, and a data fetching library does that better.

What I actually reach for

I start with useState, always. Most components never need anything else, and a reducer for a single boolean is ceremony.

I switch to useReducer at the point where one event handler is calling three setters, or where I notice I am writing a comment explaining which combinations of state are valid. Both are signals that the transitions have become the interesting part, and that is precisely what a reducer is for. The rewrite is usually twenty minutes and it almost always turns up a bug that was already there.