Unit 10: Global State Management

In React, state represents any data that changes over time and determines how a user interface is rendered. As frontend applications expand from simple interactive widgets to enterprise-grade web platforms, organizing where data lives and how it moves across components becomes the primary architectural challenge.

The Four Tiers of State in React

The Prop Drilling Dilemma

React enforces strict unidirectional (top-down) data flow: data passes from parent to child via props. When a deeply nested leaf component (such as an avatar in the header of a dashboard inside a workspace) needs data declared at the root, developers must pass that data through every intermediate component.

This phenomenon is known as prop drilling (or "threading"). Prop drilling introduces severe architectural problems:

• Tight Coupling: Intermediate components are forced to declare props they have no business caring about, simply to forward them downward.
• Refactoring Fragility: Renaming or reshaping a prop requires modifying every single file in the chain.
• Component Pollution: Components lose their generic reusability because their prop contracts are bloated with irrelevant global data.

React provides an official, built-in mechanism for bypassing prop drilling without installing third-party packages: the Context API.

The Context Triple: createContext, Provider & useContext

Working with Context involves three coordinated primitives:

1. createContext(defaultValue): Creates a unique context descriptor object. The default value is used only if a consuming component is rendered outside a matching Provider in the component tree.
2. <Context.Provider value={data}>: A component that wraps a subtree and broadcasts the supplied value to every descendant component.
3. useContext(Context): A hook that reads the current context value from the nearest matching Provider above it in the tree. (Replaced the legacy <Context.Consumer> render-props wrapper).

The Context Performance Trap: The Re-render Cascade

While Context is excellent for low-frequency global updates (such as theme switching or locale changes), it is not an optimized state manager for high-frequency data (such as live stock tickers, text input typing, or drag-and-drop coordinates).

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

// 1. Create Context token
const AuthContext = createContext(null);

// 2. Encapsulated Custom Provider
export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);

  const login = (userData) => setUser(userData);
  const logout = () => setUser(null);

  // Memoize value object to avoid passing fresh references on parent renders
  const contextValue = useMemo(() => ({
    user,
    isAuthenticated: user !== null,
    login,
    logout
  }), [user]);

  return (
    <AuthContext.Provider value={contextValue}>
      {children}
    </AuthContext.Provider>
  );
}

// 3. Ergonomic Consumer Hook with boundary verification
export function useAuth() {
  const context = useContext(AuthContext);
  if (!context) {
    throw new Error('useAuth must be invoked strictly within an <AuthProvider>');
  }
  return context;
}

In 2014, Facebook unveiled the Flux Architecture to solve unpredictable data cascades in complex client-side applications. In traditional Model-View-Controller (MVC) frameworks, models updated views, views triggered controller actions, and controllers mutated multiple models bidirectionally. Over time, this created entangled web topologies where updating a single chat badge triggered cascading mutations that were impossible to trace or reproduce.

Flux replaced this with a strict, non-negotiable rule: data flows in exactly one direction. Building on Flux, Dan Abramov created Redux in 2015, formalizing global state management into three core principles:

For years, traditional Redux was criticized for its steep learning curve and overwhelming boilerplate: developers had to manually write separate files for action type constants, action creators, reducers, and immutability spread gymnastics.

To eliminate this friction, the Redux team created Redux Toolkit (RTK). RTK is now the official, standardized, and required method for writing Redux code:

npm install @reduxjs/toolkit react-redux

Key RTK Primitives

• configureStore(): Wraps standard Redux store creation. Automatically enables Redux DevTools extension, injects default middleware (including Redux Thunk), and enables development-time checks that catch accidental state mutations.
• createSlice(): A function that accepts a slice name, an initial state, and an object of reducer functions. It automatically generates action creators and action type strings corresponding to each reducer!
• Immer.js Integration: Inside createSlice reducers, RTK uses the Immer library. Immer allows developers to write code that looks like direct mutation (e.g., state.items.push(action.payload) or state.count += 1). Under the hood, Immer detects changes made to a temporary "draft state" and produces a perfectly immutable, newly allocated state object.

import { createSlice, configureStore } from '@reduxjs/toolkit';
import { Provider, useSelector, useDispatch } from 'react-redux';

// 1. Create a Slice (Reducers + Action Creators unified)
const cartSlice = createSlice({
  name: 'cart',
  initialState: {
    items: [],
    totalCount: 0
  },
  reducers: {
    // Immer allows intuitive "mutating" syntax safely!
    addItem: (state, action) => {
      state.items.push(action.payload);
      state.totalCount += 1;
    },
    clearCart: (state) => {
      state.items = [];
      state.totalCount = 0;
    }
  }
});

// Auto-generated action creators
export const { addItem, clearCart } = cartSlice.actions;

// 2. Configure Store
export const store = configureStore({
  reducer: {
    cart: cartSlice.reducer
  }
});

// 3. Consuming Component using React-Redux Hooks
export function CartDisplay() {
  // useSelector reads specific state slice with memoized equality checks
  const totalCount = useSelector((state) => state.cart.totalCount);
  const dispatch = useDispatch();

  return (
    <div className="card">
      <p>Active Cart Items: <strong>{totalCount}</strong></p>
      <button onClick={() => dispatch(addItem({ id: 101, name: 'React Manual' }))}>
        Add Book
      </button>
      <button onClick={() => dispatch(clearCart())}>
        Clear
      </button>
    </div>
  );
}

By strict definition, Redux reducers must remain 100% pure functions: they must calculate the next state synchronously based solely on their arguments, producing zero side effects. They cannot fetch data over HTTP, set timers, or generate random numbers.

What is a Redux Middleware?

To execute side effects in Redux, logic is placed inside Middleware. A Redux middleware sits directly between the dispatch() invocation and the moment the action arrives at the reducers:
Dispatch Action → [Middleware Pipeline] → Reducer → Store

The Redux Thunk Architecture

In computer science, a thunk is a subroutine used to delay a calculation. In Redux, Redux Thunk is a middleware that allows you to dispatch a function instead of a plain action object. The thunk function receives (dispatch, getState), allowing it to initiate asynchronous network requests and dispatch synchronous plain actions when promises resolve or reject.

RTK's createAsyncThunk

Redux Toolkit simplifies async flows through createAsyncThunk. When declared, it automatically manages a promise lifecycle by dispatching three standardized action types:

• [actionName]/pending: Dispatched immediately when the async function begins execution (used to set loading = true).
• [actionName]/fulfilled: Dispatched when the promise resolves successfully (passes API response data in action.payload).
• [actionName]/rejected: Dispatched if the promise rejects or throws an error (passes error message in action.error).

import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';

// 1. Define asynchronous thunk action
export const fetchUsers = createAsyncThunk(
  'users/fetchUsers',
  async (_, { rejectWithValue }) => {
    try {
      const response = await fetch('https://jsonplaceholder.typicode.com/users');
      if (!response.ok) throw new Error('Server returned an error');
      return await response.json(); // Becomes action.payload in fulfilled
    } catch (err) {
      return rejectWithValue(err.message);
    }
  }
);

// 2. Handle lifecycle in Slice using extraReducers builder
const usersSlice = createSlice({
  name: 'users',
  initialState: {
    data: [],
    status: 'idle', // 'idle' | 'loading' | 'succeeded' | 'failed'
    error: null
  },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchUsers.pending, (state) => {
        state.status = 'loading';
        state.error = null;
      })
      .addCase(fetchUsers.fulfilled, (state, action) => {
        state.status = 'succeeded';
        state.data = action.payload;
      })
      .addCase(fetchUsers.rejected, (state, action) => {
        state.status = 'failed';
        state.error = action.payload || 'Failed to fetch users';
      });
  }
});

export default usersSlice.reducer;

In recent years, the React community recognized a profound architectural truth: most global state in web applications is actually remote server cache.

Why TanStack Query Replaced Redux for Data Fetching

When using Redux for data fetching, developers must manually write actions, reducers, thunks, loading states, error states, and unmount cleanup logic for every single API endpoint.

TanStack Query completely automates this. It operates on the Stale-While-Revalidate (SWR) caching strategy:

• When a component mounts, TanStack Query immediately serves cached data from memory (zero loading lag for the user!).
• Simultaneously, it quietly dispatches a background fetch to verify if the server data has changed.
• If new data arrives, it silently updates the cache and re-renders the component.
• It automatically refetches data when the user refocuses the browser window or reconnects to Wi-Fi.

import { useQuery, QueryClient, QueryClientProvider } from '@tanstack/react-query';

// 1. Initialize Query Client
export const queryClient = new QueryClient();

// API fetcher function
async function fetchProducts() {
  const res = await fetch('https://dummyjson.com/products?limit=5');
  if (!res.ok) throw new Error('Network response was not ok');
  return res.json();
}

// 2. Component consuming useQuery
export function ProductList() {
  // Handles caching, background re-fetching, loading, and error states automatically!
  const { data, isLoading, isError, error, refetch } = useQuery({
    queryKey: ['products'],       // Unique cache identifier
    queryFn: fetchProducts,       // Promise-returning function
    staleTime: 1000 * 60 * 5      // Data considered fresh for 5 minutes (no background fetch)
  });

  if (isLoading) return <p>Loading product catalog...</p>;
  if (isError) return <p style={{ color: 'red' }}>Error: {error.message}</p>;

  return (
    <div className="card">
      <h3>Available Inventory ({data.products?.length})</h3>
      <ul>
        {data.products?.map((p) => (
          <li key={p.id}>{p.title} • ${p.price}</li>
        ))}
      </ul>
      <button onClick={() => refetch()}>Manual Refresh</button>
    </div>
  );
}

Modern frontend engineering does not prescribe a single universal tool for all state. Instead, high-performance architectures combine multiple complementary state solutions based on data characteristics: