What does the third argument in React's useReducer(reducer, initialArg, init) do, and when is passing it worth it?

## The mechanic ```js const [state, dispatch] = useReducer(reducer, initialArg, init); ``` With two arguments, the initial state **is** `initialArg`. With three, the initial state is `init(initialArg)` — React calls your initializer with the second argument and stores the result. Either way, the initialization happens exactly once, on mount, and is ignored on every later render. ```js function createInitialState(userId) { return { userId, items: [], selected: new Set(), status: 'idle' }; } const [state, dispatch] = useReducer(reducer, userId, createInitialState); ``` ## Why the plain form can be wasteful The distinction people miss is that the second argument is an ordinary JavaScript expression evaluated on every render, because the whole component body re-runs. React discards the value after the first render, but it does not stop you from computing it: ```js // createInitialState(userId) runs on EVERY render; only the first result is used const [state, dispatch] = useReducer(reducer, createInitialState(userId)); ``` If the function parses a payload, hydrates from `localStorage`, builds a `Map`, or walks a large array, you are paying that on every keystroke. Passing the function itself instead of its result moves the cost to mount only. Note the shape difference precisely: the third argument is the function **uncalled**. `useReducer(reducer, userId, createInitialState())` is a bug — it invokes immediately and hands React whatever came back, usually not a function at all. Be honest about the size of the win, though. For a small object literal like `{ count: 0 }` there is nothing to save, and adding an initializer is pure ceremony. This is an optimisation for genuinely expensive initialization, and interviewers do listen for whether you know that. ## The reuse win The more durable reason to use `init` has nothing to do with speed. Once initial state is produced by a named function, that function becomes the single definition of "a valid starting state", and the reducer can reuse it: ```js function reducer(state, action) { if (action.type === 'reset') return createInitialState(action.userId); // ... } ``` Without it, mount-time state and reset-time state are two separate literals that quietly diverge the first time someone adds a field to one of them. It also gives you something you can unit-test on its own: assert that `createInitialState(id)` produces the invariants your reducer relies on. ## What init does not do - **It does not re-run when `initialArg` changes.** If `userId` becomes a different value on a later render, React does nothing — state is already initialized. Re-initializing on a prop change is a separate problem, and the idiomatic React answer is to give the component a `key` so it remounts, not to watch the prop in an effect. - **It does not run on every render.** That is the entire point. - **It is not required to be pure in the reducer sense**, but it should be: React may call it during a render that is later discarded, and reading or writing anything outside its arguments makes that visible. - **It receives exactly one argument** — whatever you passed as `initialArg`. If the initializer needs several inputs, pass an object. ## Relationship to the useState initializer `useState` has the same idea in a different shape: `useState(() => expensiveThing())` passes a zero-argument function that React calls once. `useReducer` splits it into a value plus a function that transforms it, which is what makes the function reusable for a reset — the `useState` form closes over its inputs instead of receiving them. ## Interview framing The strongest answer covers three beats: what it computes (`init(initialArg)`), when it runs (mount only, so it avoids per-render work that the two-argument form would repeat), and why you would still reach for it when nothing is expensive (one named source of truth for a valid starting state, reusable by a reset action and testable on its own).