A React component calls const [state, dispatch] = useReducer(reducer, buildInitialState(items)), where buildInitialState is expensive. What happens on every re-render, and how do you fix it?

## What actually happens `useReducer(reducer, buildInitialState(items))` contains a plain function call. JavaScript evaluates arguments before the call, so `buildInitialState(items)` executes on *every* render of the component — first render, and every re-render after it. React only looks at the initial-state argument during the initial render; on subsequent renders it returns the state it already has and discards the value you just spent time computing. So the cost is pure waste. If `buildInitialState` parses a large payload, builds an index from a list, or reads and deserializes from `localStorage`, you pay that cost on every keystroke that re-renders the component. ```js // runs on EVERY render, used only on the first const [state, dispatch] = useReducer(reducer, buildInitialState(items)); ``` ## The fix: the third argument `useReducer` accepts an optional third argument, an initializer function. When you pass it, React treats the second argument as raw input and calls `init(initialArg)` itself — only during the initial render: ```js // buildInitialState is CALLED BY REACT, once, on mount const [state, dispatch] = useReducer(reducer, items, buildInitialState); ``` Note the shape of the change: you removed the parentheses. You are handing React the function rather than the result. On re-renders React never invokes it, so the expensive work disappears from the render path entirely. The initializer receives whatever you passed as the second argument, which is how you keep it parameterized: ```js function buildInitialState(items) { return { byId: Object.fromEntries(items.map(i => [i.id, i])), selectedId: null }; } ``` ## The initializer must be pure Exactly like the reducer, the initializer runs during rendering, and React calls initializers twice in development under Strict Mode to surface impurity. So no network calls, no writes, no `Math.random()` sprinkled inside it. Reading synchronously from `localStorage` is a grey area many codebases accept — it is idempotent — but anything that *writes* or *sends* belongs elsewhere. ## The reset pattern this unlocks Once the initializer is a named, exported function, resetting to initial state stops being a second definition of the same shape. The reducer just calls it: ```js function reducer(state, action) { switch (action.type) { case 'reset': return buildInitialState(action.items); // ... } } // somewhere in the component dispatch({ type: 'reset', items }); ``` This matters in practice: without it, the initial-state literal appears twice — once at the `useReducer` call and once in the reset case — and they drift apart the first time someone adds a field. ## What lazy init does NOT do - **It is not a dependency mechanism.** If `items` changes later, React does not re-run the initializer; initial state means initial. If the component genuinely must rebuild its state when a prop changes, that is a different design question, and dispatching an explicit reset action is the honest answer. - **It is not memoization.** There is no cache and no comparison. React simply calls the function once, on mount, and stores the result as the first state. - **It is not required for cheap values.** `useReducer(reducer, { count: 0 })` allocates a small object per render; that is not worth a third argument. Reach for lazy init when the computation is genuinely expensive or touches something like storage. ## The parallel worth knowing `useState` has the same design: `useState(expensive())` calls `expensive` every render, while `useState(expensive)` — passing the function itself — makes React call it only on mount. Interviewers often ask the `useState` version first and then the `useReducer` version to see whether you understood the principle or memorised one API.