Context works well for a handful of relatively simple, infrequently-changing global values. Once an app has complex, frequently-updating global state with many different update patterns — a shopping cart, real-time collaborative data, complex UI state shared across many unrelated features — dedicated state management libraries offer better performance and tooling (like time-travel debugging).

// A conceptual overview - Redux Toolkit (the modern standard) simplifies this setup significantly
import { configureStore, createSlice } from "@reduxjs/toolkit";

const counterSlice = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducers: {
    increment: (state) => { state.value += 1; },
    decrement: (state) => { state.value -= 1; }
  }
});

const store = configureStore({ reducer: { counter: counterSlice.reducer } });

Redux centralizes all of an app's state into a single store, updated only through dispatched actions handled by reducers — the exact same reducer pattern from Chapter 23, just scaled up to manage an entire application's state instead of one component's.

import { create } from "zustand";

const useCounterStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

function Counter() {
  const { count, increment } = useCounterStore();
  return <button onClick={increment}>{count}</button>;
}

Zustand offers similar global-state capability with dramatically less boilerplate than traditional Redux — no Provider wrapping required, and state is accessed directly via a custom hook. It's become a popular choice for teams wanting global state without Redux's full ceremony.

Server state vs client state is an important related distinction: data fetched from an API (server state) has different needs — caching, refetching, staleness — than purely local UI state (client state). Libraries like React Query/TanStack Query are purpose-built for server state specifically, often used alongside Zustand or Context for client state.