React useReducer Explained With Examples

1What Is useReducer?

useReducer is a React hook for managing state that is more complex than a single value. Instead of calling a setter directly, you dispatch action objects to a reducer — a pure function that takes the current state and an action and returns the next state. This centralizes all your update logic in one predictable place.

It is the same mental model popularized by Redux, built into React. When several pieces of state change together, or the next value depends on the current one through branching logic, useReducer keeps that logic organized instead of scattering setState calls across event handlers.

2The Anatomy of useReducer

useReducer returns the current state and a dispatch function, and it takes a reducer and an initial state. The three moving parts are easy to name.

• const [state, dispatch] = useReducer(reducer, initialState) # the hook call
• reducer(state, action) # pure function returning the next state
• dispatch({ type: 'increment' }) # send an action to trigger an update
• action objects usually have a type and an optional payload.

3A Counter Example

The simplest useReducer example is a counter, which shows the full loop from action to new state. Even here the logic lives in one reducer rather than in the button handlers.

function reducer(state, action) {
  switch (action.type) {
    case 'increment': return { count: state.count + 1 };
    case 'decrement': return { count: state.count - 1 };
    case 'reset': return { count: 0 };
    default: throw new Error('Unknown action: ' + action.type);
  }
}

const [state, dispatch] = useReducer(reducer, { count: 0 });
<button onClick={() => dispatch({ type: 'increment' })}>+</button>
<span>{state.count}</span>
<button onClick={() => dispatch({ type: 'reset' })}>Reset</button>

4useReducer vs useState

Both hooks manage state, so the choice comes down to complexity. Neither is universally better; they suit different shapes of state.

• Use useState for a single independent value: a toggle, an input string, a boolean flag.
• Use useReducer when multiple values change together or transitions have branching rules.
• useReducer makes updates testable — the reducer is a plain function you can test without React.
• useReducer keeps event handlers thin because they only dispatch intent, not implementation.
• You can migrate from useState to useReducer as a component's logic grows without changing the UI.

5A Realistic Form Example

Forms are where useReducer earns its place, because many fields, validation errors, and a submitting flag all change together. A single reducer coordinates them coherently.

Instead of five separate useState calls fighting each other, one action like { type: 'field_changed', field: 'email', value } updates the right slice, and a 'submit' action can flip loading and clear errors at once. The state stays consistent because every path goes through one function.

• state = { values: {}, errors: {}, submitting: false }
• case 'field_changed': return { ...state, values: { ...state.values, [action.field]: action.value } }
• case 'submit': return { ...state, submitting: true, errors: {} }
• case 'error': return { ...state, submitting: false, errors: action.errors }

6Best Practices

A few conventions keep reducers clean and prevent the subtle bugs that come from accidental mutation.

• Always return a new object; never mutate state directly with something like state.count++.
• Keep reducers pure — move API calls and side effects into event handlers or effects, not the reducer.
• Use a discriminated action type so a switch statement stays exhaustive and typo-proof.
• Combine useReducer with Context to share complex state across a subtree cleanly.
• Extract the reducer to its own module so you can unit-test it in isolation.

7Sharing Reducer State With Context

useReducer manages state locally, but complex state often needs to reach many components. Placing the state and dispatch into a Context Provider turns a local reducer into an app-wide store without any external library.

Components deep in the tree read the state to render and call dispatch to trigger actions, and every update still flows through the single reducer. This keeps behavior predictable while removing prop drilling, which is why the reducer-plus-context pattern is a popular Redux alternative for medium-sized apps.

• Create a context and provide { state, dispatch } from a Provider that calls useReducer.
• Read them anywhere below with useContext.
• Memoize the value so consumers do not re-render needlessly.
• Consider separate contexts for state and dispatch to contain re-renders.

8Key Takeaways

useReducer brings structure to complex state. These points summarize when and how to use it.

• useReducer manages state via a pure reducer and dispatched action objects.
• Reach for it when state is complex, interdependent, or has branching transitions.
• The reducer centralizes update logic and is easy to test outside React.
• Dispatch actions that describe intent; keep event handlers thin.
• Pair it with Context to distribute complex state, and always return new state objects.

9Frequently Asked Questions

Q: When should I use useReducer instead of useState? A: Choose useReducer when state has multiple related fields that change together, when the next state depends on the previous one, or when transitions involve branching logic. For a single independent value, useState is simpler and clearer.

Q: Is useReducer the same as Redux? A: They share the reducer pattern, but useReducer is a local React hook with no store, middleware, or devtools out of the box. Redux is a separate library for global state with more machinery. You can approximate Redux by combining useReducer with Context.

Q: Can a reducer make API calls? A: No. Reducers must be pure functions with no side effects. Perform API calls in event handlers or effects, then dispatch an action with the result so the reducer updates state from that data.

Q: How do I share useReducer state across components? A: Put the state and dispatch into a Context Provider at a common ancestor, then read them with useContext in descendants. This gives you a lightweight, predictable global-ish store without an external library.