RCT.03.05 Mid-level· 10 minCore — asked often

useContext and its performance: why one context can re-render your whole app

Context is for passing values deep without props, not for fast-changing state. Every consumer re-renders when the value changes, so split contexts, memoize the value, and know use(Context) in React 19.

Comes up in: React, Frontend system design

Learn#

Riya’s shop puts the user, the cart and the search text in one AppContext. Every keystroke in the search box re-renders the header, the avatar and 200 product cards, and typing feels slow on a mid-range phone.

Context passes a value deep into the tree without props. A provider sets the value; a consumer reads it with useContext. When the value changes, by Object.is, every consumer re-renders, even inside memo. A value written as a new object literal changes on every render:

import { GlobalRegistrator } from "@happy-dom/global-registrator";
GlobalRegistrator.register(); // a DOM for Node; in a browser you already have one
globalThis.IS_REACT_ACT_ENVIRONMENT = true;
const { createElement: h, createContext, useContext, useMemo, useState, memo, act } = await import("react");
const { createRoot } = await import("react-dom/client");

const UserContext = createContext(null);
let avatarRenders = 0;
const Avatar = memo(function Avatar() {
  useContext(UserContext);
  avatarRenders++;
  return null;
});
let type;
function AppNewObject() {
  const [user] = useState({ name: "Asha" });
  const [search, setSearch] = useState("");
  type = () => setSearch((s) => s + "a");
  return h(UserContext.Provider, { value: { user } }, h(Avatar)); // a new object every render
}
function AppMemoized() {
  const [user] = useState({ name: "Asha" });
  const [search, setSearch] = useState("");
  type = () => setSearch((s) => s + "a");
  const value = useMemo(() => ({ user }), [user]); // the same object until user changes
  return h(UserContext.Provider, { value }, h(Avatar));
}
for (const App of [AppNewObject, AppMemoized]) {
  avatarRenders = 0;
  const root = createRoot(document.createElement("div"));
  await act(() => root.render(h(App)));
  for (let i = 0; i < 5; i++) await act(() => type()); // typing in a search box
  console.log(App.name, "→ Avatar rendered", avatarRenders, "times");
}

This example uses Node.js, so it runs in our checks rather than in your browser.

Output (verified)

AppNewObject → Avatar rendered 6 times
AppMemoized → Avatar rendered 1 times

A new value object re-renders every consumerStep 1 of 4

State

value (render 1) = object #1

App holds the search text and the user. It passes value={{ user }} to UserContext.Provider.

Read the steps as text

App holds the search text and the user. It passes value={{ user }} to UserContext.Provider.
The user types a letter. App re-renders and the literal { user } creates object #2.
React compares the old and new value with Object.is. They differ, so every component that reads UserContext re-renders, even through memo.
With useMemo(() => ({ user }), [user]) the value stays object #1, so Avatar renders once in total.

Predict#

Predict first

A context holds { user, cart }. The cart changes. A component reads only user from the context. Does it re-render?

Interview angle#

Say it like this — about 30 seconds

“Context is for dependency injection: values many components need that change rarely, such as the theme, the current user or a service. When the provider’s value changes by Object.is, every consumer re-renders, even through memo, and context has no selectors. So I memoize the value object, split contexts by how often they change, and keep fast-changing state local or in a store with selectors, such as Zustand. In React 19, use(Context) reads context and can be called conditionally.”

Stays on your device. Nothing is uploaded.

Follow-up Why can context cause performance problems? How do you fix them?

Every consumer re-renders on any value change. Memoize the value, split contexts, pass state and dispatch in separate contexts, or use a selector-based store.

Follow-up Why put dispatch in its own context?

dispatch never changes, so components that only send actions never re-render because of state changes.

Follow-up What is different about use(Context)?

It reads context like useContext but can be called inside conditions and loops.

Practice#

Guided

Build a small store with selectors: the way libraries let a component listen to only the part it needs.

Done when

setState creates a new state object; it never mutates the old one.
A subscriber runs only when its selected value changes.
Unsubscribing stops notifications.

Your solution

// createStore(state): the pattern state libraries use to avoid context re-renders.
//   getState() → current state
//   setState(partial) → merge partial into a NEW state object, then notify subscribers
//   subscribe(selector, listener) → listener(selected) runs only when selector(state) changes (Object.is);
//                                   returns unsubscribe
// So a component that selects state.user is not notified when state.search changes.
export function createStore(state) {
  const listeners = [];
  return {
    getState: () => state,
    setState(partial) { Object.assign(state, partial); listeners.forEach((l) => l(state)); },
    subscribe(selector, listener) { listeners.push(listener); return () => {}; },
  };
}

Ctrl/⌘ + Enter

Remember#

Try to answer each card before you open it. Then add them to your reviews.

When do context consumers re-render?

Whenever the provider's value changes by Object.is.

Can memo stop a context consumer from re-rendering?

No. Context changes go through memo.

Name two fixes for slow context.

Memoize the value; split contexts by how often they change.

What can use(Context) do that useContext cannot?

Be called inside conditions and loops.

Go deeper

Four layers. Stop at the one your interview needs; each ends with a quick check.

The core ideaEvery round

Use context for dependency injection: the theme, the logged-in user, the locale, a data client. Fast-changing values, such as input text or scroll position, belong in local state or a store.

Check yourself: What is context best used for?

Values many components need that change rarely, such as theme, user or services.

How it works underneathSenior rounds

The provider compares old and new values with Object.is. Wrap object values in useMemo and functions in useCallback, or the React Compiler does it for you .

Check yourself: Why does a new object literal as value re-render consumers every time?

It is a new reference each render, so Object.is says it changed.

Edge cases and trapsWhere people slip

Split by change rate: a ThemeContext that rarely changes, a CartContext that changes often, and a separate context for dispatch, which is stable.

A component reading three contexts re-renders when any of them changes.

Check yourself: Why split state and dispatch into two contexts?

Components that only dispatch then never re-render on state changes.

In productionStaff-level answers

React 19’s use(Context) reads context and may be called conditionally .

For app-wide changing state, a store with selectors (built on useSyncExternalStore, RCT.02.03) re-renders only the components whose slice changed.

Check yourself: How do stores like Zustand avoid context re-renders?

Components subscribe with selectors and re-render only when their slice changes.

Finished the five steps? Mark it, and its cards join your reviews.

Last checked 2026-11-01. Spot a mistake? Use “Report an error” below — fixes are listed on the corrections page.

Interview questions this answers

Why can context cause performance problems? How do you fix them?

1Learn#

2Predict#

3Interview angle#

4Practice#

5Remember#

Go deeper

Interview questions this answers

Learn#

Predict#

Interview angle#

Practice#

Remember#