📡 Creating Context Providers

What a Provider Really Does

Every context object created by createContext comes with a Provider component. Wrap it around part of your tree, hand it a value, and every descendant that calls useContext receives that value. When the value changes, React notifies those consumers so they re-render with the new data.

The minimal shape looks like this — a context, a Provider, and some state to feed it:

import { createContext, useState } from 'react';

const ThemeContext = createContext('light');

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

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

That works, but stuffing all the state and wiring directly into App gets messy fast. The rest of this lesson is about moving that logic somewhere better.

The value Prop

The value can be any JavaScript value: a string, a number, an object, an array, or functions. The most powerful and common choice is an object that carries both the current state and the functions to change it — so consumers can read and write.

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

  // Bundle the state and a friendly action together
  const value = {
    theme,
    setTheme,
    toggleTheme: () => setTheme((prev) => (prev === 'light' ? 'dark' : 'light')),
  };

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

Now a consumer can call toggleTheme() without ever seeing setTheme or knowing how the toggle is implemented. That encapsulation is exactly what we want.

Custom Provider Components

Instead of using Context.Provider inline, wrap it in your own component — a custom Provider. All the state, effects, and helper functions live in one place, and the rest of your app just renders <AuthProvider> without caring how it works.

Here's a realistic AuthProvider. It owns the user, exposes login/logout/signup, and syncs with an auth service. This example uses a small async auth API (swap in Firebase, Supabase, or your own backend):

// AuthContext.jsx
import { createContext, useState, useEffect, useMemo, useCallback } from 'react';
import { authApi } from './authApi';

export const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [currentUser, setCurrentUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  const login = useCallback(async (email, password) => {
    setError(null);
    try {
      const user = await authApi.signIn(email, password);
      setCurrentUser(user);
    } catch (err) {
      setError(err.message);
      throw err;
    }
  }, []);

  const logout = useCallback(async () => {
    await authApi.signOut();
    setCurrentUser(null);
  }, []);

  const signup = useCallback(async (email, password) => {
    setError(null);
    try {
      const user = await authApi.signUp(email, password);
      setCurrentUser(user);
    } catch (err) {
      setError(err.message);
      throw err;
    }
  }, []);

  // Restore the session once on mount, then subscribe to changes
  useEffect(() => {
    const unsubscribe = authApi.onAuthChange((user) => {
      setCurrentUser(user);
      setLoading(false);
    });
    return unsubscribe; // cleanup on unmount
  }, []);

  const value = useMemo(
    () => ({
      currentUser,
      loading,
      error,
      isAuthenticated: Boolean(currentUser),
      login,
      logout,
      signup,
    }),
    [currentUser, loading, error, login, logout, signup]
  );

  return (
    <AuthContext.Provider value={value}>
      {!loading && children}
    </AuthContext.Provider>
  );
}

Using it is a one-liner near the root of the app:

// App.jsx
import { AuthProvider } from './AuthContext';
import { BrowserRouter, Routes, Route } from 'react-router-dom';

function App() {
  return (
    <AuthProvider>
      <BrowserRouter>
        <Header />
        <Routes>
          <Route path="/login" element={<LoginPage />} />
          <Route path="/dashboard" element={<Dashboard />} />
        </Routes>
        <Footer />
      </BrowserRouter>
    </AuthProvider>
  );
}

Providers with useReducer

When a provider manages more than a value or two — with several related actions — useState starts to sprawl. Pairing Context with useReducer gives you a single, predictable place to describe every state transition, a lot like Redux but built into React.

import { createContext, useReducer, useMemo, useCallback } from 'react';

export const TodoContext = createContext(null);

const initialState = { todos: [], loading: false, error: null };

function todoReducer(state, action) {
  switch (action.type) {
    case 'ADD_TODO':
      return { ...state, todos: [...state.todos, action.payload] };
    case 'TOGGLE_TODO':
      return {
        ...state,
        todos: state.todos.map((todo) =>
          todo.id === action.payload
            ? { ...todo, completed: !todo.completed }
            : todo
        ),
      };
    case 'DELETE_TODO':
      return {
        ...state,
        todos: state.todos.filter((todo) => todo.id !== action.payload),
      };
    default:
      return state;
  }
}

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

  const addTodo = useCallback((text) => {
    dispatch({
      type: 'ADD_TODO',
      payload: { id: crypto.randomUUID(), text, completed: false },
    });
  }, []);

  const value = useMemo(
    () => ({ ...state, dispatch, addTodo }),
    [state, addTodo]
  );

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

Consumers dispatch actions or call the friendly helpers — they never mutate state directly:

import { useContext } from 'react';
import { TodoContext } from './TodoContext';

function TodoItem({ todo }) {
  const { dispatch } = useContext(TodoContext);

  return (
    <li style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
      <span onClick={() => dispatch({ type: 'TOGGLE_TODO', payload: todo.id })}>
        {todo.text}
      </span>
      <button onClick={() => dispatch({ type: 'DELETE_TODO', payload: todo.id })}>
        Delete
      </button>
    </li>
  );
}

Memoizing the Value

Here's a subtle trap. Every time a Provider component re-renders, any object or function created inline in its body is a brand-new reference. Since Context compares the new value to the old one by identity, a fresh object looks like a change — and every consumer re-renders, even if nothing meaningful changed.

The fix is to stabilize the value with useMemo, and stabilize functions with useCallback:

import { useState, useMemo } from 'react';

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

  // Only rebuilt when theme or fontSize actually change
  const value = useMemo(
    () => ({ theme, setTheme, fontSize, setFontSize }),
    [theme, fontSize]
  );

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

A second, structural tactic from the previous lesson still applies: split contexts by how often they change. Keep rarely-changing identity data apart from frequently-changing preferences so an update to one doesn't wake the other's consumers:

const UserDataContext = createContext(null);       // rarely changes
const UserPrefsContext = createContext(null);       // changes often

function UserProvider({ children }) {
  const [userData] = useState({ id: 123, name: 'John Doe' });
  const [prefs, setPrefs] = useState({ theme: 'light', fontSize: 'medium' });

  const userValue = useMemo(() => userData, [userData]);
  const prefsValue = useMemo(() => ({ prefs, setPrefs }), [prefs]);

  return (
    <UserDataContext.Provider value={userValue}>
      <UserPrefsContext.Provider value={prefsValue}>
        {children}
      </UserPrefsContext.Provider>
    </UserDataContext.Provider>
  );
}

🏙️ A city-infrastructure analogy. One giant power grid means maintenance anywhere risks blacking out the whole city. Separate grids per district (multiple contexts) contain the disruption. Memoization is like only powering a building when its own service actually changes.

Composing Providers

Real apps have several providers. Nesting them directly works but leads to a deep, awkward pyramid nicknamed "provider hell":

function App() {
  return (
    <AuthProvider>
      <ThemeProvider>
        <NotificationProvider>
          <AppContent />
        </NotificationProvider>
      </ThemeProvider>
    </AuthProvider>
  );
}

A cleaner approach is a single AppProviders component that gathers them, so App stays flat:

function AppProviders({ children }) {
  return (
    <AuthProvider>
      <ThemeProvider>
        <NotificationProvider>{children}</NotificationProvider>
      </ThemeProvider>
    </AuthProvider>
  );
}

function App() {
  return (
    <AppProviders>
      <AppContent />
    </AppProviders>
  );
}

For maximum flexibility, compose providers programmatically:

// Fold an array of providers into one wrapper
function composeProviders(...providers) {
  return function Composed({ children }) {
    return providers.reduceRight(
      (acc, Provider) => <Provider>{acc}</Provider>,
      children
    );
  };
}

const AppProviders = composeProviders(
  AuthProvider,
  ThemeProvider,
  NotificationProvider
);

Hands-on Exercise

import { createContext, useState, useMemo, useCallback } from 'react';

export const ThemeContext = createContext({ theme: 'light', toggleTheme: () => {} });

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

  const toggleTheme = useCallback(() => {
    setTheme((prev) => (prev === 'light' ? 'dark' : 'light'));
  }, []);

  const value = useMemo(() => ({ theme, toggleTheme }), [theme, toggleTheme]);

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

Best Practices

Summary & Quiz

📚 Further Reading

• React docs — Context.Provider
• React docs — useReducer
• React — Scaling Up with Reducer and Context

🚀 What's Next?

You can now publish rich values into the tree. Next we'll focus on the other end of the wire — consuming context with useContext, wrapping it in custom hooks, and guarding against missing providers.