useContext

1The Basic API

useContext reads a value from the nearest matching Provider above the calling component in the tree, without that value being threaded through every intermediate component's props ("prop drilling").

import { createContext, useContext } from "react";

type Theme = "light" | "dark";
const ThemeContext = createContext<Theme>("light"); // "light" is the DEFAULT value

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}

function Toolbar() {
  return <ThemedButton />; // Toolbar never touches theme — no drilling needed
}

function ThemedButton() {
  const theme = useContext(ThemeContext); // "dark" — read directly, however deep
  return <button className={theme}>Click me</button>;
}

createContext(defaultValue) creates the context object; <Context.Provider value={...}> makes a value available to everything beneath it; useContext(Context) reads whatever value the nearest enclosing Provider supplied.

2What the Default Value Is Actually For

The value passed to createContext(defaultValue) is used only when a component calls useContext with no matching Provider anywhere above it in the tree — it is not a fallback for "a Provider exists but forgot to pass a value prop," and it is not used if a Provider is present, even if that provider's value is undefined.

const ThemeContext = createContext<Theme>("light");

function OrphanButton() {
  return <ThemedButton />; // no <ThemeContext.Provider> anywhere above this
}
// useContext(ThemeContext) inside ThemedButton here returns "light" — the default,
// used purely because no Provider was found during the walk up the tree.

This makes the default value mostly useful for components rendered/tested in isolation, or as a documented "this is what you get if you forget to wrap the tree" contract.

3Re-render Behavior: All-or-Nothing per Provider

Every component that calls useContext(SomeContext) re-renders whenever the nearest Provider's value prop changes by reference — regardless of whether that specific component reads the part of value that actually changed.

interface AppState { user: { name: string }; settings: { fontSize: number } }
const AppContext = createContext<AppState | undefined>(undefined);

function UserName() {
  const ctx = useContext(AppContext);
  return <span>{ctx?.user.name}</span>; // only reads `user`...
  // ...but still re-renders every time `settings.fontSize` changes, because the
  // Provider's whole `value` object got a new reference on that update.
}

This is context's most common performance gotcha. The two standard fixes:

// Fix 1: split one big context into several narrower ones
const UserContext = createContext<{ name: string } | undefined>(undefined);
const SettingsContext = createContext<{ fontSize: number } | undefined>(undefined);
// UserName now only subscribes to UserContext — settings changes don't touch it

// Fix 2: memoize the value object so its reference is stable across unrelated renders
function AppProvider({ children }: { children: React.ReactNode }) {
  const [user, setUser] = useState({ name: "Ana" });
  const [settings, setSettings] = useState({ fontSize: 14 });
  const value = useMemo(() => ({ user, settings }), [user, settings]);
  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

Memoizing only helps if user and settings themselves don't change reference on unrelated renders — splitting contexts is the more robust fix when consumers genuinely only care about one slice.

4Composing Multiple Providers

Real apps typically nest several independent providers, each owning one concern:

function App() {
  return (
    <ThemeProvider>
      <AuthProvider>
        <Dashboard />
      </AuthProvider>
    </ThemeProvider>
  );
}

function Dashboard() {
  const theme = useTheme();   // custom hook wrapping useContext(ThemeContext)
  const { user } = useAuth(); // custom hook wrapping useContext(AuthContext)
  return <div className={theme}>Welcome, {user.name}</div>;
}

Nesting order only matters if one provider's logic depends on another (e.g. an AuthProvider that reads ThemeContext internally must be nested inside ThemeProvider).

5Typing Context Properly in TypeScript

The cleanest pattern: type the context as T | undefined, default it to undefined (no fake default object), and export a custom hook that throws immediately if called outside its provider — turning a silent "wrong default value" bug into a loud, immediate error at the call site:

interface AuthState { user: { id: string; name: string } | null; login: () => void; logout: () => void }
const AuthContext = createContext<AuthState | undefined>(undefined);

function AuthProvider({ children }: { children: React.ReactNode }) {
  const [user, setUser] = useState<AuthState["user"]>(null);
  const value: AuthState = {
    user,
    login: () => setUser({ id: "1", name: "Ana" }),
    logout: () => setUser(null),
  };
  return <AuthContext.Provider value={value}>{children}</AuthContext.Provider>;
}

function useAuth(): AuthState {
  const ctx = useContext(AuthContext);
  if (ctx === undefined) throw new Error("useAuth must be used within an AuthProvider");
  return ctx; // TypeScript now knows this is AuthState, not AuthState | undefined
}

This pattern — a context plus a custom hook wrapping useContext and validating it — is exactly the shape the Custom Hooks topic builds on.

⚠️ Common Pitfalls

1. Passing a brand-new object literal inline — <Context.Provider value={{ user, settings }}> creates a new object every render, defeating any memoization downstream and re-rendering every consumer on every Provider render, regardless of whether user/settings actually changed.
2. Assuming useContext only re-renders components that use the changed field — it doesn't; it's all-or-nothing per Provider value reference.
3. Forgetting a Provider entirely and silently getting the default value instead of a visible error — mitigated by the throw-on-undefined custom-hook pattern from section 5.
4. Overusing Context for frequently-changing, high-frequency state (mouse position, every keystroke) — every consumer re-renders on every change; prop drilling to a narrow subtree, or a dedicated state library with selector-based subscriptions, performs far better for high-frequency updates.

📋 Quick Reference

const Ctx = createContext<T>(defaultValue)        → create context, default used only w/o a Provider
<Ctx.Provider value={v}>...</Ctx.Provider>          → supply a value to the subtree
useContext(Ctx)                                     → read nearest Provider's value
createContext<T | undefined>(undefined) + throw     → recommended TS pattern via custom hook
useMemo(() => ({ ...}), [deps])                     → stabilize a Provider's value reference

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: react_usecontext_theory.md · generated by tools/build_lessons.py