Context API and Its Trade-offs

Context Solves One Problem, Creates Another

React Context sounds perfect on paper: pass data through the component tree without threading props through every level. No more prop drilling — no more passing a value through 5 intermediate components that couldn't care less about it.

But here's the trade-off nobody mentions in the tutorials: every consumer re-renders when the provider value changes, regardless of which part of the value they actually use. And that's where the trouble starts.

const ThemeContext = createContext('light');

function App() {
  const [theme, setTheme] = useState('light');

  return (
    <ThemeContext.Provider value={theme}>
      <Header />
      <Main />
      <Footer />
    </ThemeContext.Provider>
  );
}

function DeepChild() {
  const theme = useContext(ThemeContext);
  return <div className={`card card--${theme}`}>Content</div>;
}

Creating and Using Context

// 1. Create the context with a default value
const UserContext = createContext(null);

// 2. Provider wraps the subtree that needs access
function App() {
  const [user, setUser] = useState(null);

  return (
    <UserContext.Provider value={{ user, setUser }}>
      <Dashboard />
    </UserContext.Provider>
  );
}

// 3. Consumers read the value with useContext
function UserAvatar() {
  const { user } = useContext(UserContext);
  if (!user) return <GuestAvatar />;
  return <img src={user.avatarUrl} alt={user.name} />;
}

The default value (null in createContext(null)) is used only when a component calls useContext without a matching Provider above it in the tree. This is primarily useful for testing or standalone component usage.

The Re-render Problem

Let's look at the problem most Context tutorials conveniently skip over:

const AppContext = createContext();

function App() {
  const [user, setUser] = useState({ name: 'Alice' });
  const [theme, setTheme] = useState('dark');

  // NEW object on every render!
  const value = { user, theme, setUser, setTheme };

  return (
    <AppContext.Provider value={value}>
      <Sidebar />    {/* Only uses theme */}
      <MainContent /> {/* Only uses user */}
    </AppContext.Provider>
  );
}

Every time App re-renders (any state change), value is a new object reference. Every consumer of AppContext re-renders — even if only user changed and Sidebar only reads theme.

Fix 1: Memoize the Value

function App() {
  const [user, setUser] = useState({ name: 'Alice' });
  const [theme, setTheme] = useState('dark');

  const value = useMemo(
    () => ({ user, theme, setUser, setTheme }),
    [user, theme]
  );

  return (
    <AppContext.Provider value={value}>
      <Sidebar />
      <MainContent />
    </AppContext.Provider>
  );
}

Now the value object only changes when user or theme actually changes. But consumers that use user still re-render when only theme changes — because they consume the entire context.

Fix 2: Split Into Separate Contexts

const UserContext = createContext(null);
const ThemeContext = createContext('light');

function App() {
  const [user, setUser] = useState({ name: 'Alice' });
  const [theme, setTheme] = useState('dark');

  return (
    <UserContext.Provider value={user}>
      <ThemeContext.Provider value={theme}>
        <Sidebar />     {/* useContext(ThemeContext) — only re-renders on theme change */}
        <MainContent />  {/* useContext(UserContext) — only re-renders on user change */}
      </ThemeContext.Provider>
    </UserContext.Provider>
  );
}

This is the recommended pattern. Each consumer subscribes only to the data it needs.

Composition: The Alternative to Context

Before you reach for Context, ask yourself this: can you solve the problem with composition instead?

// BEFORE: Prop drilling through 3 levels
function App() {
  const [user, setUser] = useState(currentUser);
  return <Layout user={user} />;
}
function Layout({ user }) {
  return <Sidebar user={user} />;
}
function Sidebar({ user }) {
  return <UserAvatar user={user} />;
}

// AFTER: Composition — pass the component as children
function App() {
  const [user, setUser] = useState(currentUser);
  return (
    <Layout>
      <Sidebar>
        <UserAvatar user={user} />
      </Sidebar>
    </Layout>
  );
}

// Layout and Sidebar do not need to know about user at all.
// They just render {children}.

When to Use Context

Context is the right choice for:

• Infrequently changing global values: theme, locale, auth status
• Deeply nested access: values needed by many components at many levels
• Dependency injection: providing implementations (API clients, feature flags)

Context is the wrong choice for:

• Rapidly changing values: mouse position, scroll offset, keystroke input
• Large objects: entire app state in one context (Redux-style)
• Simple prop passing: 2-3 levels deep — just pass the prop

Production Scenario: Theme Provider Pattern

const ThemeContext = createContext({
  colors: { primary: '#000', background: '#fff' },
  toggleTheme: () => {},
});

function ThemeProvider({ children }) {
  const [isDark, setIsDark] = useState(false);

  const theme = useMemo(() => ({
    colors: isDark
      ? { primary: '#fff', background: '#111' }
      : { primary: '#000', background: '#fff' },
    toggleTheme: () => setIsDark(d => !d),
  }), [isDark]);

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

// Custom hook for type safety and error handling
function useTheme() {
  const context = useContext(ThemeContext);
  if (!context) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
}

Challenge: Split a Monolithic Context

Context Splitting