🔗 React Context API Fundamentals

The Problem: Prop Drilling

Before you can appreciate Context, you need to feel the pain it removes. That pain is called prop drilling: passing a piece of data down through many layers of components, where most of the components in the chain don't use the data themselves — they only forward it along.

Imagine your App holds the signed-in user, and a deeply nested ProductDetail needs that user to decide whether to show a premium-only button. Without Context, every component between them has to accept and re-pass the user prop:

// Without Context — the user prop is drilled through every level
function App() {
  const [user, setUser] = useState({ name: 'Alice', isPremium: true });

  return (
    <div>
      <Header user={user} />
      <MainContent user={user} />
    </div>
  );
}

// MainContent and ProductList don't USE user — they only pass it on
function MainContent({ user }) {
  return <ProductList user={user} />;
}

function ProductList({ user }) {
  return (
    <div>
      {products.map((product) => (
        <ProductItem key={product.id} product={product} user={user} />
      ))}
    </div>
  );
}

function ProductItem({ product, user }) {
  return <ProductDetail product={product} user={user} />;
}

// Only here is user actually consumed
function ProductDetail({ product, user }) {
  return (
    <div>
      {user.isPremium && <button>Premium Feature</button>}
    </div>
  );
}

💡 A useful analogy. Prop drilling is like delivering a package to Apartment 5D without a mailroom: you hand it to the doorman, who hands it to the elevator operator, who hands it to the hallway monitor, who finally hands it to 5D. The middlemen don't want the package — they're just links in a fragile chain. Context is the mailroom that delivers straight to the recipient.

Prop drilling isn't just verbose. Every intermediate component now has a fake dependency on user: rename the prop, add a second shared value, or insert a new layer, and you're editing files that shouldn't care. That coupling is what Context dissolves.

Enter the Context API

The Context API lets a parent publish a value and any descendant subscribe to it directly — the components in between are bypassed entirely. It's designed for data that is effectively "global" to a section of your UI: the current user, the theme, the language, a shopping cart.

Here is the same feature rebuilt with Context. Notice that MainContent, ProductList, and ProductItem no longer mention user at all:

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

// 1. Create a context object
const UserContext = createContext(null);

// 2. Provide a value to the whole subtree
function App() {
  const [user, setUser] = useState({ name: 'Alice', isPremium: true });

  return (
    <UserContext.Provider value={user}>
      <Header />
      <MainContent />
    </UserContext.Provider>
  );
}

// The middle layers are blissfully unaware of user now
function MainContent() {
  return <ProductList />;
}

function ProductList() {
  return (
    <div>
      {products.map((product) => (
        <ProductItem key={product.id} product={product} />
      ))}
    </div>
  );
}

function ProductItem({ product }) {
  return <ProductDetail product={product} />;
}

// 3. Consume the value directly, wherever you need it
function ProductDetail({ product }) {
  const user = useContext(UserContext);

  return (
    <div>
      {user.isPremium && <button>Premium Feature</button>}
    </div>
  );
}

The Three Moving Parts

Every use of Context is built from the same three pieces. Get these names straight and the rest of the module clicks into place.

When to Reach for Context

Context is a sharp tool, not a universal one. It shines when the same data is genuinely needed in many places at different depths, and it's overkill (or actively harmful) when the data is local.

Great fits

• Theming — dark/light mode read by components everywhere
• Authentication — the current user and login/logout helpers
• Localization — the active language and translation strings
• Feature flags — which capabilities a user is allowed to see

Poor fits

• Local state — if only one component (or a tiny subtree) uses it, plain useState is simpler
• High-frequency updates — values that change many times per second will re-render every consumer
• One or two levels deep — just pass a prop; Context earns its keep at depth
• A full app-state replacement — large apps with complex, interdependent state often still want Redux Toolkit (covered later this module)

Re-renders & Performance

The one behavior that surprises newcomers: when a Provider's value changes, every component that consumes that context re-renders — even if it only reads a slice of the value. A single mega-context that holds the user, theme, and cart will re-render theme-only components whenever the cart changes.

The primary fix is to split one broad context into several focused ones, so unrelated updates stay isolated:

// Split by concern so unrelated changes don't cascade
const UserContext = createContext(null);
const ThemeContext = createContext('light');
const CartContext = createContext([]);

function App() {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  const [cart, setCart] = useState([]);

  return (
    <UserContext.Provider value={user}>
      <ThemeContext.Provider value={theme}>
        <CartContext.Provider value={cart}>
          <AppContent />
        </CartContext.Provider>
      </ThemeContext.Provider>
    </UserContext.Provider>
  );
}

Now a component that only reads ThemeContext won't re-render when the cart updates. You'll go deeper on memoizing the provider value and other tactics in the next lesson, but the mental model to hold now is simple: one context per concern that changes together.

Default Context Values

The argument you pass to createContext is the default value. It's used only when a component calls useContext and there is no matching Provider above it in the tree. A well-chosen default keeps consumers from crashing on undefined:

// A default that matches the real shape means consumers can destructure safely
const UserContext = createContext({
  name: 'Guest',
  isPremium: false,
  login: () => {},   // no-op placeholders keep calls from throwing
  logout: () => {},
});

function ProfileButton() {
  const { name, logout } = useContext(UserContext);
  return <button onClick={logout}>Log out {name}</button>;
}

Good defaults are useful for testing a component in isolation, for optional contexts, and as a safety net during development. That said, many teams intentionally default to undefined and then throw a clear error from a custom hook when a Provider is missing — a pattern you'll build in the "Consuming Context" lesson.

Hands-on Exercise

function App() {
  const [language, setLanguage] = useState('en');
  return <Toolbar language={language} />;
}

function Toolbar({ language }) {
  return <Nav language={language} />;
}

function Nav({ language }) {
  return <Greeting language={language} />;
}

function Greeting({ language }) {
  return <h1>{language === 'en' ? 'Hello' : 'Hola'}</h1>;
}

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

const LanguageContext = createContext('en');

function App() {
  const [language, setLanguage] = useState('en');
  return (
    <LanguageContext.Provider value={language}>
      <Toolbar />
    </LanguageContext.Provider>
  );
}

// No more language prop passing through the middle
function Toolbar() {
  return <Nav />;
}

function Nav() {
  return <Greeting />;
}

function Greeting() {
  const language = useContext(LanguageContext);
  return <h1>{language === 'en' ? 'Hello' : 'Hola'}</h1>;
}

Best Practices

Summary & Quiz

📚 Further Reading

• React docs — createContext
• React docs — useContext
• React — Passing Data Deeply with Context

🚀 What's Next?

You understand the problem and the three pieces. Next we'll go deep on the middle piece — building robust, reusable Context Providers that bundle state with the functions to change it.