React State Management: Context API vs. Redux & Building a Theme Switcher

The State Management Dilemma

In the React ecosystem, state management is often the first architectural bottleneck developers hit. For years, Redux was the default answer. If you needed data accessible across the component tree, you wrapped the app in a Provider, wrote a reducer, created an action, and dispatched it. It was verbose, but it worked.

Then came the revamped Context API in React 16.3, and later, the useContext hook. Suddenly, we had a native way to blast through the component tree without prop drilling, no external libraries required.

As someone building micro-SaaS tools and AI agents, I prioritize efficiency and maintainability. I see too many developers reaching for Redux boilerplate to toggle a sidebar, and conversely, developers trying to force complex e-commerce logic into a simple Context provider.

Today, we’re going to define exactly when to use which tool, and then we’re going to build a system where Context shines: a global Theme Switcher.

Redux: The Heavy Artillery

Redux (and modern Redux Toolkit) is a predictable state container. It implies a strict unidirectional data flow. It is not just a way to pass data; it is a way to enforce how state changes happen.

When to use Redux:

• High-Frequency Updates: If your state updates rapidly (e.g., a stock market dashboard or a real-time collaborative canvas), Redux is optimized to prevent unnecessary re-renders via selectors.
• Complex State Logic: If one action triggers multiple state changes across different domains of your app (e.g., "Checkout" clears the cart, updates inventory, and logs analytics), Redux middleware (Thunk/Saga) manages this orchestration beautifully.
• Debugging Requirements: The Redux DevTools are unparalleled. Time-travel debugging is essential for large-scale enterprise applications where tracking why a state changed is as important as the change itself.

Context API: The Native Transport

Context is strictly a transport mechanism. It is designed to share data that can be considered "global" for a tree of React components. It doesn't manage state logic itself; it relies on useState or useReducer for that.

When to use Context API:

• Static or Low-Frequency Data: Authenticated user data, UI themes (Dark/Light), and language settings. These don't change 60 times a second.
• Avoiding Prop Drilling: When you just need to pass a value from a parent to a great-grandchild without touching the components in between.
• Simplicity & Bundle Size: You want zero external dependencies. You want to keep your bundle lightweight for a performant micro-SaaS.

The Verdict: The Decision Matrix

Before we write code, here is the rule of thumb I use for my projects:

Use Context if you are tackling "prop drilling" for global settings.
Use Redux (or Zustand/Jotai) if you are tackling "complex state orchestration" or performance bottlenecks in high-frequency data applications.

Let's Build: A Theme Switcher with Context API

For a feature like a Theme Switcher, Redux is overkill. We don't need middleware, and the state only changes when the user explicitly clicks a toggle. This is the perfect candidate for Context.

We are going to build a robust, typed (assuming TypeScript mental model), and reusable Theme Context.

Step 1: The Architecture

We need three things:

1. The Context: The pipe that holds the data.
2. The Provider: The component that manages the state and wraps the app.
3. The Hook: A custom hook to consume the context easily.

Step 2: Creating the Theme Context

I prefer to keep my context logic in a dedicated file, usually src/context/ThemeContext.js.

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

// 1. Create the Context with a default value (good for intellisense/testing)
const ThemeContext = createContext({
  theme: 'light',
  toggleTheme: () => {},
});

export const ThemeProvider = ({ children }) => {
  // 2. State management logic
  // Check local storage first to persist user preference
  const [theme, setTheme] = useState(() => {
    const savedTheme = localStorage.getItem('app-theme');
    return savedTheme || 'light';
  });

  // 3. Side effect to update the actual DOM and LocalStorage
  useEffect(() => {
    const root = window.document.documentElement;
    
    // Remove old class and add new one
    root.classList.remove('light', 'dark');
    root.classList.add(theme);
    
    // Save to storage
    localStorage.setItem('app-theme', theme);
  }, [theme]);

  const toggleTheme = () => {
    setTheme((prevTheme) => (prevTheme === 'light' ? 'dark' : 'light'));
  };

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

// 4. Custom Hook for consumption
export const useTheme = () => {
  const context = useContext(ThemeContext);
  if (!context) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
};

Step 3: Wrapping the Application

In your index.js or App.js, wrap your top-level component. This ensures the context is available throughout the tree.

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';
import { ThemeProvider } from './context/ThemeContext';
import './index.css'; // Your Tailwind or CSS variables

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <ThemeProvider>
      <App />
    </ThemeProvider>
  </React.StrictMode>
);

Step 4: The Toggle Component

Now, we can build a switch anywhere in the app without passing props down. Let's create a header component that uses our custom hook.

import React from 'react';
import { useTheme } from '../context/ThemeContext';
import { SunIcon, MoonIcon } from './Icons'; // Assuming you have icons

const Header = () => {
  const { theme, toggleTheme } = useTheme();

  return (
    <header className="flex justify-between items-center p-4 bg-white dark:bg-gray-900 transition-colors duration-200">
      <h1 className="text-xl font-bold text-gray-900 dark:text-white">
        DevPortfolio
      </h1>
      
      <button
        onClick={toggleTheme}
        className="p-2 rounded-full bg-gray-200 dark:bg-gray-700 focus:outline-none"
        aria-label="Toggle Theme"
      >
        {theme === 'light' ? (
          <MoonIcon className="w-6 h-6 text-gray-800" />
        ) : (
          <SunIcon className="w-6 h-6 text-yellow-400" />
        )}
      </button>
    </header>
  );
};

export default Header;

Why This Approach Works

Notice the simplicity here. We aren't defining actions or reducers. We are simply exposing a value and a setter function.

1. Persistance: By initializing state with a callback, we check localStorage before the first render, preventing that annoying "flash of wrong theme" on page load.
2. CSS Integration: The useEffect hook directly manipulates the <html> class list. This works perfectly with frameworks like Tailwind CSS, which uses the dark: variant based on parent classes.
3. Isolation: The logic is contained. If we want to change how the theme is stored (e.g., move to a database setting instead of local storage), we only edit the ThemeProvider. The UI components remain untouched.

Performance Consideration: The Context Trap

While this works perfectly for a theme, be careful. Context triggers a re-render in all consuming components whenever the value changes.

If you put your theme, user data, and real-time notifications all in one massive Context object, updating a notification count would cause your Theme Toggle button to re-render. For a Theme Switcher, this is negligible. For high-velocity data, separate your Contexts (e.g., UserContext, ThemeContext, DataContext) or switch to Redux/Zustand.

Final Thoughts

As a developer, your job isn't to use the most complex tool available; it's to ship reliable systems. For global UI states like theming, the Context API is the most elegant solution. It keeps your dependency tree small and your logic clear.

Save Redux for the battles that require it. For everything else, keep it native.