In a React app where one context provides both the state and the function that updates it, why do teams split it into two separate contexts — one for the state and one for the updater — and what does that buy?

## The problem it solves The usual shape of a context-based store is one object carrying both halves: ```jsx const value = useMemo(() => ({ todos, dispatch }), [todos]); return <TodoContext value={value}>{children}</TodoContext>; ``` This is correctly memoized — the value only changes when `todos` changes. But now consider two kinds of consumer: - `<TodoList>` reads `todos` and renders them. It *must* re-render when `todos` changes. - `<AddTodoButton>` reads only `dispatch`. It renders a button. It never displays state. Both read the same context, so both are notified on every state change. The button re-renders on every keystroke that touches the store, for a value that did not change from its point of view. Multiply that across a toolbar, a row of per-item action buttons, or a form of thirty inputs each holding a `dispatch`-bound handler, and the waste is real. Context gives you no way to express "notify me only about the parts I read", so you express it structurally instead: **make the parts you read into separate contexts.** ## The shape of the fix ```jsx const TodoStateContext = createContext(null); const TodoDispatchContext = createContext(null); function TodoProvider({ children }) { const [todos, dispatch] = useReducer(todoReducer, []); return ( <TodoStateContext value={todos}> <TodoDispatchContext value={dispatch}>{children}</TodoDispatchContext> </TodoStateContext> ); } ``` Notice what disappeared: there is no `useMemo` anywhere. `todos` is the reducer's state object, already stable between updates, and `dispatch` is stable by construction — React guarantees the same `dispatch` identity for the life of the component. Two single-value contexts sidestep the whole memoization problem, which is a real secondary benefit: there is no dependency array to get wrong. The write-only consumer now reads `TodoDispatchContext`, whose value is `Object.is`-equal on every render forever, so React never schedules it for a context update. It re-renders only if its own props or state change. ## Doing the same without a reducer With `useState` the updater is `setTodos`, which React also guarantees to be stable, so the same split works directly. What is *not* stable is a hand-written wrapper: ```jsx // unstable — new function every render, so the dispatch context changes every render const api = { add: (t) => setTodos((prev) => [...prev, t]) }; ``` If your write context exposes several named actions rather than a raw setter, memoize the whole action object and stabilise each function: ```jsx const add = useCallback((t) => setTodos((prev) => [...prev, t]), []); const clear = useCallback(() => setTodos([]), []); const actions = useMemo(() => ({ add, clear }), [add, clear]); ``` Because each updater uses the functional form of the setter, none of them needs the current state as a dependency, so all of them can have empty dependency arrays and the action object is stable for the lifetime of the provider. That functional-update discipline is what makes the split possible at all — an action written as `() => setTodos([...todos, t])` would depend on `todos` and re-create the whole action object on every state change, collapsing the benefit. ## Ergonomics Expose a hook per half so consumers state their intent, and so you can add the throw-if-missing check in one place: ```jsx export const useTodos = () => useContext(TodoStateContext); export const useTodoDispatch = () => useContext(TodoDispatchContext); ``` A component that calls `useTodoDispatch()` alone is now visibly write-only, and reviewers can see at a glance that adding a `useTodos()` call to it changes its render profile. ## When it is not worth it This is a targeted fix, not a default architecture. Two contexts mean two providers, two hooks, and two things to import; a small app with a handful of consumers and infrequent updates gains nothing measurable and loses some clarity. Reach for it when you can point at the cost: state that updates on every keystroke or every animation frame, or a wide set of consumers that only dispatch. And measure with the Profiler afterwards — the split removes context-driven renders, but if the write-only components were re-rendering because their parent re-rendered, this changes nothing at all.