In React, why is the dispatch function returned by useReducer safe to leave out of a useEffect dependency array, and what does that stability let you avoid elsewhere?

## The guarantee `const [state, dispatch] = useReducer(reducer, initialState)` returns a `dispatch` whose identity React keeps constant across every render of that component instance. It is created once, when the hook is first mounted, and returned unchanged forever after. The state setter from `useState` carries the same guarantee. That single fact explains everything else here. ## Why the dependency array does not care A dependency array is a change detector: React compares each entry with its value from the previous render and re-runs the effect if any differ. A value that is identical on every render can never trigger that comparison to fail. So: ```js useEffect(() => { const id = setInterval(() => dispatch({ type: 'ticked' }), 1000); return () => clearInterval(id); }, []); // safe: dispatch cannot change // [dispatch] // equally correct, and equally never re-runs ``` Both forms behave identically. The `react-hooks/exhaustive-deps` lint rule has this knowledge built in: it will not complain about an omitted `dispatch`, and many codebases still list it for explicitness. Neither choice is a bug. Compare that with a handler you define in the component body, which is a *new* function object every render — omitting that from the array creates a stale closure, and including it re-runs the effect on every render unless you wrap it. ## What the stability actually buys you **No `useCallback` when passing it down.** An inline `onChange={() => setX(1)}` is a fresh function each render, so a `React.memo`-wrapped child re-renders every time unless the parent wraps the handler in `useCallback`. `dispatch` needs none of that: ```js <ExpensiveList dispatch={dispatch} /> // memo holds; no useCallback needed ``` This is one of the genuine architectural arguments for a reducer: instead of threading five memoized callbacks through the tree, you thread one stable `dispatch`, and children describe what happened. **A stable value to put in context.** Because it never changes, `dispatch` can be placed in a context that is separate from the state context, and consumers that only dispatch will not re-render when the state changes. **Interval and subscription callbacks stay simple.** Long-lived callbacks — an interval, a socket handler, an event listener registered once — can call `dispatch` without the effect needing to be torn down and re-created to keep the reference current. ## The trap: stable is not fresh Stability applies to the function, not to anything around it. Two things people wrongly infer: 1. **"Since dispatch is stable, my effect can use an empty dependency array."** No. Any *other* value the effect reads — props, state, a derived object — still needs to be in the array or accounted for, or the effect closes over a stale render's values. `dispatch` being exempt exempts only itself. 2. **"Since dispatch is stable, the action I build inside the callback sees current state."** No. If you compute the payload from `state` captured in a long-lived callback, you capture the value from the render in which the callback was created. The correct answer is to let the *reducer* read the latest state — dispatch an action describing the event and compute from `state` inside the reducer, which always receives the current state: ```js // stale: count is from the render that created the interval setInterval(() => dispatch({ type: 'set', value: count + 1 }), 1000); // correct: the reducer reads current state setInterval(() => dispatch({ type: 'ticked' }), 1000); ``` That second form is a big practical reason reducers pair well with timers and subscriptions. ## Summary `dispatch` is one of the few React values you can treat as a constant. Use that: pass it down freely, put it in context, close over it in long-lived callbacks. Just do not let its stability convince you that the *state* around it is fresh too.