A React provider is written as `<AuthContext value={{ user, login, logout }}>{children}</AuthContext>` inside a component that re-renders often. Why does every consumer re-render even when user has not changed, and how do you fix it?

## What React actually compares A context provider does not diff the contents of its value. It performs one comparison — `Object.is(previousValue, nextValue)` — and if that is false, it schedules an update on every component reading that context below it. `Object.is` is essentially reference equality for objects (it differs from `===` only for `NaN` and `-0`). Two objects with identical fields are still two objects. That single comparison is the whole story, and it is why this pitfall is so common: a context almost always carries several things at once — some state plus the functions to change it — and the natural way to bundle them is an object literal in JSX. An object literal is an allocation expression. It runs on every render. ```jsx function AuthProvider({ children }) { const [user, setUser] = useState(null); // new object identity on every render of AuthProvider return ( <AuthContext value={{ user, login: () => setUser(fetchMe()), logout: () => setUser(null) }}> {children} </AuthContext> ); } ``` If `AuthProvider` re-renders for any reason at all — an unrelated piece of its own state, a parent re-render — every consumer in the app is notified, even though `user` is the same object it was before. ## The fix, in two halves **Half one: memoize the container object.** ```jsx const value = useMemo(() => ({ user, login, logout }), [user, login, logout]); return <AuthContext value={value}>{children}</AuthContext>; ``` `useMemo` returns the same object across renders as long as every dependency is `Object.is`-equal to last time. Now the context value only changes when something inside it genuinely changed. **Half two: make the functions stable, or half one is theatre.** If `login` and `logout` are arrow functions defined in the component body, they are new function objects every render, so the dependency array changes every render, so `useMemo` recomputes every render, so the value identity changes every render. You have added a hook and fixed nothing. Wrap them: ```jsx const login = useCallback((creds) => setUser(authenticate(creds)), []); const logout = useCallback(() => setUser(null), []); ``` Or sidestep it: if the provider's state lives in `useReducer`, the `dispatch` function React hands you is stable across renders, so it needs no wrapping at all. The same trap applies to nested objects and to arrays: `useMemo(() => ({ config: { retries: 3 } }), [])` is fine because the whole thing is memoized, but `useMemo(() => ({ items: items.filter(Boolean) }), [items])` re-allocates whenever `items` changes identity — which may be every render if `items` itself is computed inline upstream. Stability is only as good as the least stable dependency. ## When you do not need any of this Memoizing is not free — it costs a hook, a dependency array to keep correct, and reader effort — so know when to skip it. - **The value is a single primitive.** `<ThemeContext value={theme}>` where `theme` is the string `"dark"` needs nothing: primitives compare by value. - **The value is the state object itself.** `<UserContext value={user}>` where `user` comes straight from `useState` is already stable between updates. - **The provider component only ever re-renders when the value genuinely changes.** If the only state in the provider is the state in the value, and nothing above it re-renders it, a fresh literal is fresh precisely when the data changed. This is fragile — one added `useState` in that component breaks it silently — so most teams memoize anyway as a defensive habit. ## The diagnostic In the React DevTools Profiler, record an interaction and look at what rendered. If a wide, unrelated set of consumers rendered together and the profiler attributes it to a context change, look at the provider's value expression first. Nine times out of ten it is a literal. A useful mental model for review: **treat the `value` prop of a provider as a memoization boundary.** Anything constructed inline there is being handed to potentially the entire application as "this changed". ## The related mistake Do not respond to this problem by wrapping the consumers in `React.memo`. A consumer re-renders because it reads a context whose value changed; `React.memo` compares props and cannot block that. The fix has to happen at the provider — stabilize the value, or split it so fewer components care about the part that changes.