🔌 Context API and Global State

The Problem: Prop Drilling

In React, data flows down through props: a parent hands values to its children. That is clean when the data has a short trip to make. But imagine the signed-in user lives at the top of your app and is needed by a tiny UserMenu buried five levels deep. Every component in between has to accept user and pass it along — even though none of them use it.

This is prop drilling: pushing props through layers of components that don't care about them, just to reach the one that does.

Four components (Layout, Header, Navigation, UserMenu) become couriers for data they never read. The costs add up:

• Noise — every intermediate component's signature is cluttered with pass-through props.
• Fragility — add one new field and you edit five files.
• Reduced reuse — those middle components are now welded to a specific prop shape.

💡 Not every shared value needs Context. Prop drilling through one or two levels is perfectly fine — it's explicit and easy to follow. Context earns its keep when data is truly "global" and travels far.

What Context Actually Is

Context lets a component broadcast a value to its entire subtree. Any descendant can read that value directly, no matter how deep, without a single prop being passed by hand.

Good candidates for Context are values that many, scattered components need: the current theme, the authenticated user, the app's language, or UI flags like whether a sidebar is open.

Context in Three Steps

Every context follows the same rhythm: create it, provide it, consume it. Here is a complete theme example in modern React (function components + hooks).

Step 1 — Create the context

import { createContext, useContext, useState } from 'react';

// createContext returns an object holding a Provider (and legacy Consumer).
// The argument is a *default* value, used only when a component reads the
// context without a matching Provider above it.
const ThemeContext = createContext(null);

Step 2 — Provide a value

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  const toggleTheme = () =>
    setTheme((prev) => (prev === 'light' ? 'dark' : 'light'));

  // Everything inside <ThemeProvider> can now read { theme, toggleTheme }.
  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

Step 3 — Consume it anywhere below

function ThemeButton() {
  const { theme, toggleTheme } = useContext(ThemeContext);

  return (
    <button onClick={toggleTheme}>
      Switch to {theme === 'light' ? 'dark' : 'light'} mode
    </button>
  );
}

function App() {
  return (
    <ThemeProvider>
      <Header />
      <main>
        {/* ThemeButton is nested deep, yet reads the theme directly */}
        <ThemeButton />
      </main>
    </ThemeProvider>
  );
}

The Custom-Hook Pattern

Calling useContext(ThemeContext) directly works, but production codebases almost always wrap it in a custom hook. This does two things: it hides the raw context object, and it lets you throw a helpful error if a component tries to use the context outside its Provider.

// theme-context.jsx
import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext(null);

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');
  const toggleTheme = () =>
    setTheme((prev) => (prev === 'light' ? 'dark' : 'light'));

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

// The custom hook: consume + guard in one place.
export function useTheme() {
  const context = useContext(ThemeContext);
  if (context === null) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
}

Now components import a clean, purpose-built hook and never touch useContext or the context object:

import { useTheme } from './theme-context';

function ThemeButton() {
  const { theme, toggleTheme } = useTheme();
  return <button onClick={toggleTheme}>Current: {theme}</button>;
}

Context + useReducer for Complex State

Simple useState is fine for a theme flag. But when global state has many fields and many kinds of transitions — a cart, a notification queue, an auth session — useReducer gives you a single, predictable place where every change is defined. Pair it with Context and you get a lightweight, Redux-flavored store built entirely from React primitives.

Here is a shopping-cart store. Notice how all the update logic lives in one reducer, and the Provider exposes friendly helper functions so components never build raw action objects.

// cart-context.jsx
import { createContext, useContext, useReducer } from 'react';

const initialState = { items: [], itemCount: 0, total: 0 };

function cartReducer(state, action) {
  switch (action.type) {
    case 'ADD_ITEM': {
      const item = action.payload;
      const existing = state.items.find((i) => i.id === item.id);
      const items = existing
        ? state.items.map((i) =>
            i.id === item.id ? { ...i, qty: i.qty + 1 } : i
          )
        : [...state.items, { ...item, qty: 1 }];
      return recalc(items);
    }
    case 'REMOVE_ITEM':
      return recalc(state.items.filter((i) => i.id !== action.payload));
    case 'CLEAR':
      return initialState;
    default:
      throw new Error(`Unknown action: ${action.type}`);
  }
}

// Derive totals in one place so state never drifts out of sync.
function recalc(items) {
  return {
    items,
    itemCount: items.reduce((n, i) => n + i.qty, 0),
    total: items.reduce((sum, i) => sum + i.price * i.qty, 0),
  };
}

const CartContext = createContext(null);

export function CartProvider({ children }) {
  const [state, dispatch] = useReducer(cartReducer, initialState);

  const value = {
    ...state,
    addItem: (item) => dispatch({ type: 'ADD_ITEM', payload: item }),
    removeItem: (id) => dispatch({ type: 'REMOVE_ITEM', payload: id }),
    clear: () => dispatch({ type: 'CLEAR' }),
  };

  return <CartContext.Provider value={value}>{children}</CartContext.Provider>;
}

export function useCart() {
  const context = useContext(CartContext);
  if (context === null) {
    throw new Error('useCart must be used within a CartProvider');
  }
  return context;
}

Consuming it is a joy — components describe what should happen, never how:

function AddToCartButton({ product }) {
  const { addItem } = useCart();
  return <button onClick={() => addItem(product)}>Add to cart</button>;
}

function CartBadge() {
  const { itemCount } = useCart();
  return <span className="badge">🛒 {itemCount}</span>;
}

{
  items: [
    { id: 7, name: "Mug", price: 12, qty: 2 },
    { id: 3, name: "Sticker", price: 3, qty: 1 }
  ],
  itemCount: 3,
  total: 27
}

The Re-render Trap

Context has one sharp edge you must respect: when a Provider's value changes, every component that reads that context re-renders — even components that only use a slice of the value that didn't change.

// ⚠️ Problem: user and theme share one context.
function AppProvider({ children }) {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');

  // A NEW object every render — every consumer re-renders every time.
  const value = { user, setUser, theme, setTheme };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

There are two independent fixes, and good apps use both.

Fix 1 — Split contexts by concern

If theme and user change for unrelated reasons, they should not live together. Give each its own context so a theme flip never re-renders user-only components.

// Separate providers — a theme change no longer touches user consumers.
<UserProvider>
  <ThemeProvider>
    <App />
  </ThemeProvider>
</UserProvider>

Fix 2 — Memoize the value

Even within one context, wrap the value object in useMemo so a new object is created only when its real data changes, not on every render.

import { useMemo, useState } from 'react';

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');
  const toggleTheme = () =>
    setTheme((prev) => (prev === 'light' ? 'dark' : 'light'));

  // Same object reference until `theme` actually changes.
  const value = useMemo(() => ({ theme, toggleTheme }), [theme]);

  return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>;
}

Context vs. State Libraries

Context is a transport mechanism for shared values, not a full state-management system. For richer needs, dedicated libraries add selectors (subscribe to just the slice you use), devtools, and less boilerplate. Here's how the popular options compare.

The honest takeaway: reach for Context first because it's free and native. Graduate to a library when you feel real pain — constant re-render tuning, or state logic that's sprawling across many reducers.

Hands-on Exercise

// src/theme-context.jsx
import { createContext, useContext, useEffect, useMemo, useState } from 'react';

const ThemeContext = createContext(null);

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState(
    () => localStorage.getItem('theme') ?? 'light'
  );

  useEffect(() => {
    localStorage.setItem('theme', theme);
    document.documentElement.dataset.theme = theme;
  }, [theme]);

  const value = useMemo(
    () => ({
      theme,
      toggleTheme: () =>
        setTheme((t) => (t === 'light' ? 'dark' : 'light')),
    }),
    [theme]
  );

  return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>;
}

export function useTheme() {
  const ctx = useContext(ThemeContext);
  if (ctx === null) throw new Error('useTheme must be used within a ThemeProvider');
  return ctx;
}

// src/App.jsx
import { useTheme } from './theme-context';

export default function App() {
  const { theme, toggleTheme } = useTheme();
  return (
    <main>
      <h1>Current theme: {theme}</h1>
      <button onClick={toggleTheme}>Toggle theme</button>
    </main>
  );
}

Summary & Quiz

📚 Further Reading

• React docs — Passing Data Deeply with Context
• React reference — useContext
• React docs — Scaling Up with Reducer and Context

🚀 What's Next?

Our theme provider quietly used useEffect to sync with localStorage. Next up, Effects and Component Lifecycle takes useEffect apart in full — mounting, updating, cleanup, dependency arrays, and the mistakes that trip up nearly everyone.