What is Context and When Should You Use It?

As the MERN Blog grows, certain data needs to be accessible in many components at many different levels of the component tree — the currently logged-in user, the active theme, a notification count. Passing this data as props through every intermediate component is called prop drilling, and it quickly makes the codebase tedious and fragile. React Context is the built-in solution: it lets you make data available to any component in the tree without threading it through props. Understanding when Context is the right tool — and when it is overkill — is the key decision this lesson addresses.

The Prop Drilling Problem #

// Without Context: user passed as prop through every intermediate component
function App() {
  const [user, setUser] = useState(null);
  return <PageLayout user={user} setUser={setUser} />;
}

function PageLayout({ user, setUser }) {
  return (
    <div>
      <Header user={user} setUser={setUser} /> {/* passes down */}
      <main><Outlet /></main>
    </div>
  );
}

function Header({ user, setUser }) {
  return <nav><UserMenu user={user} setUser={setUser} /></nav> {/* passes down */}
}

function UserMenu({ user, setUser }) {
  // Only this component actually uses user — all the above were just passing it
  return user
    ? <span>{user.name} <button onClick={() => setUser(null)}>Log Out</button></span>
    : <Link to="/login">Log In</Link>;
}
// Problem: PageLayout and Header know about user/setUser but never use it
// Adding a new prop means updating every component in the chain

Context vs Props vs Lifting State — Decision Guide #

How Context Works — Mental Model #

Without Context:
  App → PageLayout → Header → UserMenu
  data flows through props at every step — all components know about user

With Context:
  AuthProvider wraps the tree
       │
       ├── PageLayout (does not touch user — transparent)
       │       ├── Header (does not touch user — transparent)
       │       │       └── UserMenu ← useAuth() reads user directly
       │       └── PostDetailPage ← useAuth() reads user directly
       └── DashboardPage ← useAuth() reads user directly

  Components that need user read it directly from context
  Components that don't need user are completely unaware of it

What Belongs in the MERN Blog Contexts #

Common Mistakes #

Mistake 1 — Using Context for data that only two components share #

❌ Wrong — creating a context for a search query shared between SearchBar and PostList:

// SearchContext.jsx — overkill for two adjacent siblings
// Just lift query to BlogPage and pass as props ✓

✅ Correct — lift state to the nearest common ancestor for nearby components.

Mistake 2 — Putting fast-changing data in a broad context #

❌ Wrong — putting the post list in AuthContext alongside user data:

// Every time a post is liked, ALL context consumers re-render (including Header!)
const AuthContext = createContext({ user, posts, likedPostIds, ... });

✅ Correct — keep AuthContext focused on auth state only; post data belongs in page-level state.

Mistake 3 — Reading context outside a Provider #

❌ Wrong — using useAuth() in a component rendered above AuthProvider:

// App.jsx — AuthProvider is NOT a parent of this component
function RootHeader() {
  const { user } = useAuth(); // undefined — no Provider above this component
  return <header>{user?.name}</header>;
}
// Used above <AuthProvider> in the tree

✅ Correct — every component that consumes a context must be a descendant of its Provider.

Quick Reference #