useContext Hook — Complete React Interview Guide

Creating and using Context — the three-step pattern

import { createContext, useContext, useState } from 'react'
 
// Step 1: Create the context
// The argument is the DEFAULT value — used when no Provider exists above
const ThemeContext = createContext('light')
 
// Step 2: Provide a value to the subtree
function App() {
  const [theme, setTheme] = useState('light')
 
  return (
    // Any component inside this Provider can read theme/setTheme
    <ThemeContext.Provider value={{ theme, setTheme }}>
      <Navbar />
      <Main />
      <Footer />
    </ThemeContext.Provider>
  )
}
 
// Step 3: Consume anywhere in the subtree — no prop drilling
function ThemeToggle() {
  const { theme, setTheme } = useContext(ThemeContext)
 
  return (
    <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>
      Current: {theme}
    </button>
  )
}
// ThemeToggle can be nested 10 levels deep — still reads theme directly

The default value — when is it used?

const UserContext = createContext(null)
// null is the default — used when component renders OUTSIDE any Provider
 
function ProfileAvatar() {
  const user = useContext(UserContext)
  // If rendered without UserContext.Provider above it, user is null (the default)
  return user ? <img src={user.avatar} /> : <GuestIcon />
}
 
// Inside app — Provider exists
<UserContext.Provider value={currentUser}>
  <ProfileAvatar />  {/* user = currentUser */}
</UserContext.Provider>
 
// In Storybook / unit test — no Provider
<ProfileAvatar />  {/* user = null (default) — no crash */}

The re-render trap — every consumer re-renders

This is the most important thing to understand about Context performance:

const AppContext = createContext(null)
 
function App() {
  const [user, setUser]         = useState(null)
  const [theme, setTheme]       = useState('light')
  const [notifications, setN]   = useState([])
 
  // ✗ One context for everything
  return (
    <AppContext.Provider value={{ user, theme, notifications, setUser, setTheme, setN }}>
      <Navbar />  {/* re-renders when ANYTHING in value changes */}
      <Main />    {/* re-renders when ANYTHING in value changes */}
    </AppContext.Provider>
  )
}
 
// Navbar only uses theme — but re-renders when user changes or notifications change!
function Navbar() {
  const { theme } = useContext(AppContext)  // reads one field
  // Re-renders when user changes or notifications change — wasteful!
  return <nav className={theme}>...</nav>
}

Solution 1 — Split contexts by update frequency

// Separate contexts — each only triggers its own consumers
const UserContext         = createContext(null)   // changes on login/logout
const ThemeContext         = createContext('light') // changes on toggle
const NotificationContext  = createContext([])      // changes frequently
 
function App() {
  const [user, setUser]         = useState(null)
  const [theme, setTheme]       = useState('light')
  const [notifications, setN]   = useState([])
 
  return (
    <UserContext.Provider value={{ user, setUser }}>
      <ThemeContext.Provider value={{ theme, setTheme }}>
        <NotificationContext.Provider value={{ notifications, setN }}>
          <AppContent />
        </NotificationContext.Provider>
      </ThemeContext.Provider>
    </UserContext.Provider>
  )
}
 
// Navbar only re-renders when theme changes — not when user or notifications change
function Navbar() {
  const { theme } = useContext(ThemeContext)  // isolated
  return <nav className={theme}>...</nav>
}

Solution 2 — Separate state from dispatch

Since useReducer's dispatch function is always stable, putting it in a separate context means "dispatch-only" components never re-render when state changes:

const StateContext    = createContext(null)  // changes on every action
const DispatchContext = createContext(null)  // NEVER changes — dispatch is stable
 
function AppProvider({ children }) {
  const [state, dispatch] = useReducer(appReducer, initialState)
 
  return (
    <DispatchContext.Provider value={dispatch}>   {/* stable forever */}
      <StateContext.Provider value={state}>         {/* changes on updates */}
        {children}
      </StateContext.Provider>
    </DispatchContext.Provider>
  )
}
 
// Button that only dispatches — NEVER re-renders due to state changes
function AddButton() {
  const dispatch = useContext(DispatchContext)  // stable reference
  return <button onClick={() => dispatch({ type: 'ADD' })}>Add</button>
}
 
// Display that reads state — re-renders when state changes (expected)
function Counter() {
  const { count } = useContext(StateContext)
  return <p>Count: {count}</p>
}

Custom hook wrapper — safer context consumption

// Expose context through a custom hook with runtime error checking
const AuthContext = createContext(null)
 
export function AuthProvider({ children }) {
  const [user, setUser] = useState(null)
  const login  = useCallback(async (creds) => { /* ... */ }, [])
  const logout = useCallback(async () => { setUser(null) }, [])
 
  return (
    <AuthContext.Provider value={{ user, login, logout }}>
      {children}
    </AuthContext.Provider>
  )
}
 
export function useAuth() {
  const ctx = useContext(AuthContext)
  if (!ctx) throw new Error('useAuth must be inside AuthProvider')
  return ctx
}
 
// Usage — clear error if Provider is missing instead of silent null crash
function ProfilePage() {
  const { user } = useAuth()  // throws immediately if no AuthProvider above
  return <div>{user.name}</div>
}

Context vs prop drilling vs state management