Learn when to use React Context API vs props drilling. Master state distribution patterns with performance considerations, trade-offs, and real-world examples from production applications.

# Context vs Props Drilling: Mastering State Distribution

Every React developer hits the same problem: data needs to flow from a parent component deep into a nested child component. You have two primary approaches—passing props through every intermediate component or using React's Context API. This decision shapes your application's maintainability, performance, and debugging experience. In this guide, we'll explore when each approach wins and how to make the right choice for your specific scenario.

# Understanding the Problem

Before comparing solutions, let's establish why this problem exists and why it matters.

In React's unidirectional data flow model, data flows from parent to child via props. This design prevents circular dependencies and makes reasoning about data flow straightforward. However, when you have deeply nested components—which is common in real applications—passing data through every intermediate component becomes cumbersome.

Consider a typical e-commerce application structure:

      
typescript

<App>
  <Header theme="dark" />
  <MainLayout>
    <Sidebar>
      <CartSummary /> {/* needs theme */}
      <WishlistItem /> {/* needs theme */}
    </Sidebar>
    <ProductGrid>
      <ProductCard theme="dark" /> {/* needs theme */}
    </ProductGrid>
  </MainLayout>
  <Footer theme="dark" />
</App>

If theme is managed at the App level but needed at CartSummary, without Context you'd pass it through MainLayout → Sidebar → CartSummary, even though the intermediate components don't use it.

# What is Props Drilling?

Props drilling (also called "prop threading" or "prop chains") occurs when you pass props through multiple component layers solely to forward them to deeper components.

# Props Drilling in Action

TypeScript Version

      
typescript

import { ReactNode } from 'react';

interface ThemeConfig {
  primaryColor: string;
  fontSize: number;
  isDark: boolean;
}

// Layer 1: App component manages theme state
interface AppProps {
  theme: ThemeConfig;
}

function App({ theme }: AppProps) {
  return (
    <MainLayout theme={theme}>
      {/* theme is passed here but App doesn't use it directly */}
    </MainLayout>
  );
}

// Layer 2: MainLayout doesn't need theme, but must pass it down
interface MainLayoutProps {
  theme: ThemeConfig;
  children?: ReactNode;
}

function MainLayout({ theme, children }: MainLayoutProps) {
  return (
    <div className="layout">
      <Sidebar theme={theme} />
      {children}
    </div>
  );
}

// Layer 3: Sidebar doesn't need theme either
interface SidebarProps {
  theme: ThemeConfig;
  children?: ReactNode;
}

function Sidebar({ theme, children }: SidebarProps) {
  return (
    <aside className="sidebar">
      <CartSummary theme={theme} />
      {children}
    </aside>
  );
}

// Layer 4: Finally, CartSummary actually uses theme
interface CartSummaryProps {
  theme: ThemeConfig;
}

function CartSummary({ theme }: CartSummaryProps) {
  return (
    <div style={{ color: theme.primaryColor }}>
      {/* actually uses the theme */}
    </div>
  );
}

JavaScript Version

      
javascript

function App({ theme }) {
  return (
    <MainLayout theme={theme}>
      {/* theme passed but not used */}
    </MainLayout>
  );
}

function MainLayout({ theme, children }) {
  return (
    <div className="layout">
      <Sidebar theme={theme} />
      {children}
    </div>
  );
}

function Sidebar({ theme, children }) {
  return (
    <aside className="sidebar">
      <CartSummary theme={theme} />
      {children}
    </aside>
  );
}

function CartSummary({ theme }) {
  return (
    <div style={{ color: theme.primaryColor }}>
      {/* finally uses the theme */}
    </div>
  );
}

# Problems with Props Drilling

1. Reduced Component Reusability: Components like MainLayout and Sidebar become tied to specific props they don't use, making them harder to reuse in different contexts.

2. Refactoring Overhead: Adding or removing a piece of shared data requires modifying every component in the chain, increasing the risk of bugs.

3. Implicit Dependencies: Components don't declare what they actually use—they just pass props through. This makes the code harder to understand.

4. Increased Type Safety Complexity: TypeScript interfaces for intermediate components must include props they don't directly use, creating unnecessary complexity.

# What is Context API?

React's Context API provides a mechanism to pass data through the component tree without having to pass props down manually at every level.

# How Context Works

Context consists of three parts:

Creating the context with createContext()
Providing the context with a Provider component
Consuming the context with useContext() hook

TypeScript Version

      
typescript

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

// Step 1: Create context with proper typing
interface ThemeConfig {
  primaryColor: string;
  fontSize: number;
  isDark: boolean;
}

interface ThemeContextType {
  theme: ThemeConfig;
  setTheme: (theme: ThemeConfig) => void;
}

const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

// Step 2: Create a provider component to manage state
interface ThemeProviderProps {
  children: ReactNode;
}

function ThemeProvider({ children }: ThemeProviderProps) {
  const [theme, setTheme] = useState<ThemeConfig>({
    primaryColor: '#3b82f6',
    fontSize: 16,
    isDark: false,
  });

  const value: ThemeContextType = { theme, setTheme };

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

// Step 3: Create a custom hook for convenient access
function useTheme(): ThemeContextType {
  const context = useContext(ThemeContext);
  
  if (!context) {
    throw new Error('useTheme must be used within ThemeProvider');
  }
  
  return context;
}

// Now any component can access theme without prop drilling
function CartSummary() {
  const { theme } = useTheme();
  
  return (
    <div style={{ color: theme.primaryColor }}>
      {/* Uses theme directly */}
    </div>
  );
}

// No intermediate component needs to know about theme
function MainLayout({ children }: { children: ReactNode }) {
  return (
    <div className="layout">
      <Sidebar />
      {children}
    </div>
  );
}

// Application setup
function App() {
  return (
    <ThemeProvider>
      <MainLayout />
    </ThemeProvider>
  );
}

JavaScript Version

      
javascript

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

const ThemeContext = createContext(undefined);

function ThemeProvider({ children }) {
  const [theme, setTheme] = useState({
    primaryColor: '#3b82f6',
    fontSize: 16,
    isDark: false,
  });

  const value = { theme, setTheme };

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

function useTheme() {
  const context = useContext(ThemeContext);
  
  if (!context) {
    throw new Error('useTheme must be used within ThemeProvider');
  }
  
  return context;
}

function CartSummary() {
  const { theme } = useTheme();
  
  return (
    <div style={{ color: theme.primaryColor }}>
      {/* Uses theme directly */}
    </div>
  );
}

function App() {
  return (
    <ThemeProvider>
      <MainLayout />
    </ThemeProvider>
  );
}

# Head-to-Head Comparison

Aspect	Props Drilling	Context API
Setup Complexity	Simple—just pass props	Requires Provider setup
Data Flow Clarity	Explicit—visible in every component	Implicit—only visible at usage point
Component Reusability	Lower—components tied to specific props	Higher—components independent of prop chain
Performance	Efficient—only re-renders when props change	Potential issues—can trigger unnecessary re-renders
Debugging	Easier—trace props through tree	Harder—Context dependencies not obvious
Type Safety	Straightforward TypeScript	Requires custom hooks for best experience
Bundle Size	No overhead	No overhead
Testing	Easier—fewer props to mock	Requires Provider wrapper in tests
Refactoring	Expensive—chain changes are widespread	Cheap—single point of change

# When to Use Each Approach

The choice isn't binary—use both in the same application, strategically deployed.

# Use Props Drilling When:

✅ Shallow nesting (1-2 levels): If data only needs to pass through one or two intermediate components, the overhead of props is minimal.

      
typescript

// Props drilling is fine here - just 2 levels
<Parent data={value}>
  <Child data={value} />  {/* Component actually uses it */}
</Parent>

✅ Component reusability is critical: When you want a component to work in multiple contexts without knowing about specific data structures.

      
typescript

// This button works anywhere - doesn't care about application state
function Button({ onClick, children }: { onClick: () => void; children: ReactNode }) {
  return <button onClick={onClick}>{children}</button>;
}

✅ Explicit dependencies matter: When you want to see exactly what each component depends on at a glance.

      
typescript

// Clear: LoadingButton depends on isLoading and onClick
<LoadingButton isLoading={isLoading} onClick={handleClick} />

# Use Context API When:

✅ Deep nesting (3+ levels): When data needs to pass through multiple layers of intermediary components.

      
typescript

// Context makes sense: many layers of nesting
<App>
  <Layout>
    <Sidebar>
      <UserMenu>
        <Avatar /> {/* needs user data from App */}
      </UserMenu>
    </Sidebar>
  </Layout>
</App>

✅ Cross-cutting concerns: Theme, authentication, notifications—data used across many unrelated components.

      
typescript

// Theme should be available everywhere without prop drilling
const { theme } = useTheme();
const { user } = useAuth();
const { addNotification } = useNotifications();

✅ Avoiding component coupling: You want intermediate components to be reusable and not tied to specific data structures.

      
typescript

// MainLayout is now reusable anywhere, not just with theme
<MainLayout>
  {/* Works with any children, doesn't care about theme prop */}
</MainLayout>

✅ Reducing prop interface complexity: TypeScript interfaces become cleaner when components don't forward unused props.

      
typescript

// Without Context: every component needs theme prop
interface MainLayoutProps {
  theme: ThemeConfig;
  children: ReactNode;
}

// With Context: clean interface
interface MainLayoutProps {
  children: ReactNode;
}

# Performance Implications

This is where many developers get confused. Context doesn't magically solve performance problems—it can actually create new ones if misused.

# Props Drilling Performance

Props drilling has minimal performance impact because:

Only the parent component re-renders when data changes
Children only re-render if their props actually change
React's reconciliation algorithm is highly optimized for this pattern

      
typescript

// Performance is fine here - only App re-renders theme changes
function App() {
  const [theme, setTheme] = useState(initialTheme);
  
  return (
    <MainLayout theme={theme}>
      {/* Only MainLayout re-renders when theme changes */}
    </MainLayout>
  );
}

// MainLayout only re-renders if theme prop actually changes
function MainLayout({ theme }: { theme: ThemeConfig }) {
  return <div>{/* ... */}</div>;
}

# Context Performance Challenges

Context can cause unexpected re-renders:

      
typescript

// ❌ PROBLEMATIC: All consumers re-render on any context change
const ThemeContext = createContext(null);

function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState(initialTheme);
  const [notifications, setNotifications] = useState([]);
  
  // Every time either theme or notifications changes,
  // ALL context consumers re-render
  const value = { theme, notifications };
  
  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

# Optimizing Context Performance

      
typescript

// ✅ GOOD: Split contexts by data type
const ThemeContext = createContext<ThemeContextType | null>(null);
const NotificationContext = createContext<NotificationContextType | null>(null);

function App({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState(initialTheme);
  const [notifications, setNotifications] = useState([]);

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      <NotificationContext.Provider value={{ notifications, setNotifications }}>
        {children}
      </NotificationContext.Provider>
    </ThemeContext.Provider>
  );
}

// Now: components using only theme don't re-render when notifications change
const ThemeConsumer = () => {
  const { theme } = useContext(ThemeContext)!;
  return <div style={{ color: theme.primaryColor }} />;
};

const NotificationConsumer = () => {
  const { notifications } = useContext(NotificationContext)!;
  return <div>{notifications.length} notifications</div>;
};

# Real-World Implementation

Let's build a practical example: an authentication system used across an entire e-commerce application.

TypeScript Version

      
typescript

import { createContext, useContext, useState, useCallback, ReactNode } from 'react';

// Type definitions
interface User {
  id: string;
  email: string;
  name: string;
  role: 'user' | 'admin';
}

interface AuthContextType {
  user: User | null;
  isLoading: boolean;
  error: string | null;
  login: (email: string, password: string) => Promise<void>;
  logout: () => void;
  register: (email: string, password: string, name: string) => Promise<void>;
}

// Create context
const AuthContext = createContext<AuthContextType | undefined>(undefined);

// Provider component
interface AuthProviderProps {
  children: ReactNode;
}

export function AuthProvider({ children }: AuthProviderProps) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  const login = useCallback(async (email: string, password: string) => {
    setIsLoading(true);
    setError(null);

    try {
      const response = await fetch('/api/auth/login', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ email, password }),
      });

      if (!response.ok) {
        throw new Error('Login failed');
      }

      const data = await response.json();
      setUser(data.user);
      // Store token in localStorage
      localStorage.setItem('authToken', data.token);
    } catch (err) {
      setError(err instanceof Error ? err.message : 'Unknown error');
      throw err;
    } finally {
      setIsLoading(false);
    }
  }, []);

  const logout = useCallback(() => {
    setUser(null);
    localStorage.removeItem('authToken');
  }, []);

  const register = useCallback(async (email: string, password: string, name: string) => {
    setIsLoading(true);
    setError(null);

    try {
      const response = await fetch('/api/auth/register', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ email, password, name }),
      });

      if (!response.ok) {
        throw new Error('Registration failed');
      }

      const data = await response.json();
      setUser(data.user);
      localStorage.setItem('authToken', data.token);
    } catch (err) {
      setError(err instanceof Error ? err.message : 'Unknown error');
      throw err;
    } finally {
      setIsLoading(false);
    }
  }, []);

  const value: AuthContextType = {
    user,
    isLoading,
    error,
    login,
    logout,
    register,
  };

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

// Custom hook for consuming context
export function useAuth(): AuthContextType {
  const context = useContext(AuthContext);

  if (!context) {
    throw new Error('useAuth must be used within AuthProvider');
  }

  return context;
}

// Example: Using in different parts of the application
function UserProfile() {
  const { user, logout } = useAuth();

  if (!user) {
    return <div>Please log in</div>;
  }

  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
      <button onClick={logout}>Logout</button>
    </div>
  );
}

function HeaderUserMenu() {
  const { user, isLoading } = useAuth();

  return (
    <div className="user-menu">
      {isLoading ? (
        <span>Loading...</span>
      ) : user ? (
        <span>Welcome, {user.name}!</span>
      ) : (
        <span>Guest</span>
      )}
    </div>
  );
}

// Application setup - wrap at root level
function App() {
  return (
    <AuthProvider>
      <MainLayout />
    </AuthProvider>
  );
}

JavaScript Version

      
javascript

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

const AuthContext = createContext(undefined);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  const login = useCallback(async (email, password) => {
    setIsLoading(true);
    setError(null);

    try {
      const response = await fetch('/api/auth/login', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ email, password }),
      });

      if (!response.ok) throw new Error('Login failed');

      const data = await response.json();
      setUser(data.user);
      localStorage.setItem('authToken', data.token);
    } catch (err) {
      setError(err.message);
      throw err;
    } finally {
      setIsLoading(false);
    }
  }, []);

  const logout = useCallback(() => {
    setUser(null);
    localStorage.removeItem('authToken');
  }, []);

  const register = useCallback(async (email, password, name) => {
    setIsLoading(true);
    setError(null);

    try {
      const response = await fetch('/api/auth/register', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ email, password, name }),
      });

      if (!response.ok) throw new Error('Registration failed');

      const data = await response.json();
      setUser(data.user);
      localStorage.setItem('authToken', data.token);
    } catch (err) {
      setError(err.message);
      throw err;
    } finally {
      setIsLoading(false);
    }
  }, []);

  const value = { user, isLoading, error, login, logout, register };

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

export function useAuth() {
  const context = useContext(AuthContext);

  if (!context) {
    throw new Error('useAuth must be used within AuthProvider');
  }

  return context;
}

function UserProfile() {
  const { user, logout } = useAuth();

  if (!user) return <div>Please log in</div>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
      <button onClick={logout}>Logout</button>
    </div>
  );
}

# Advanced Patterns and Solutions

# Pattern 1: Hybrid Approach

Many production applications use both props and Context strategically. The key is understanding the boundary between them:

Props: Component-specific data, explicit dependencies, local communication
Context: Cross-cutting concerns, implicit dependencies, global concerns

      
typescript

// Context for global concerns (auth, theme, notifications)
<AuthProvider>
  <ThemeProvider>
    <NotificationProvider>
      <MainLayout>
        {/* Props for local component communication */}
        <ProductCard 
          product={product}
          onAddToCart={handleAddToCart}
          isOnSale={product.salePrice !== undefined}
        />
      </MainLayout>
    </NotificationProvider>
  </ThemeProvider>
</AuthProvider>

This hybrid approach is what you'll see in production applications from companies like Alibaba and ByteDance. The Context layer handles framework-level concerns, while props handle feature-level communication.

# Pattern 2: Context with useReducer

For complex state, combine Context with useReducer. This pattern is particularly useful when you have multiple related state updates:

      
typescript

interface CartItem {
  id: string;
  name: string;
  price: number;
  quantity: number;
}

interface ContextState {
  items: CartItem[];
  total: number;
  isLoading: boolean;
}

type ContextAction = 
  | { type: 'ADD_ITEM'; payload: CartItem }
  | { type: 'REMOVE_ITEM'; payload: string }
  | { type: 'UPDATE_QUANTITY'; payload: { id: string; quantity: number } }
  | { type: 'SET_LOADING'; payload: boolean }
  | { type: 'CLEAR' };

function cartReducer(state: ContextState, action: ContextAction): ContextState {
  switch (action.type) {
    case 'ADD_ITEM': {
      const existingItem = state.items.find(i => i.id === action.payload.id);
      if (existingItem) {
        return {
          ...state,
          items: state.items.map(i =>
            i.id === action.payload.id
              ? { ...i, quantity: i.quantity + action.payload.quantity }
              : i
          ),
          total: state.total + action.payload.price * action.payload.quantity,
        };
      }
      return {
        ...state,
        items: [...state.items, action.payload],
        total: state.total + action.payload.price * action.payload.quantity,
      };
    }
    
    case 'REMOVE_ITEM': {
      const item = state.items.find(i => i.id === action.payload);
      return {
        ...state,
        items: state.items.filter(i => i.id !== action.payload),
        total: state.total - (item?.price || 0) * (item?.quantity || 1),
      };
    }
    
    case 'UPDATE_QUANTITY': {
      const item = state.items.find(i => i.id === action.payload.id);
      if (!item) return state;
      
      const quantityDifference = action.payload.quantity - item.quantity;
      return {
        ...state,
        items: state.items.map(i =>
          i.id === action.payload.id
            ? { ...i, quantity: action.payload.quantity }
            : i
        ),
        total: state.total + item.price * quantityDifference,
      };
    }
    
    case 'SET_LOADING':
      return { ...state, isLoading: action.payload };
    
    case 'CLEAR':
      return { items: [], total: 0, isLoading: false };
    
    default:
      return state;
  }
}

const CartContext = createContext<{ 
  state: ContextState; 
  dispatch: React.Dispatch<ContextAction> 
} | undefined>(undefined);

function CartProvider({ children }: { children: ReactNode }) {
  const [state, dispatch] = useReducer(cartReducer, {
    items: [],
    total: 0,
    isLoading: false,
  });

  return (
    <CartContext.Provider value={{ state, dispatch }}>
      {children}
    </CartContext.Provider>
  );
}

function useCart() {
  const context = useContext(CartContext);
  if (!context) {
    throw new Error('useCart must be used within CartProvider');
  }
  return context;
}

// Usage in components
function AddToCartButton({ product }: { product: CartItem }) {
  const { dispatch } = useCart();

  const handleAddToCart = () => {
    dispatch({
      type: 'ADD_ITEM',
      payload: { ...product, quantity: 1 },
    });
  };

  return (
    <button onClick={handleAddToCart}>
      Add {product.name} to Cart
    </button>
  );
}

# Pattern 3: Selective Context Subscription

Avoid re-rendering all consumers when unrelated context values change by splitting contexts:

      
typescript

// ❌ PROBLEMATIC: Single context with unrelated data
const AppContext = createContext<{
  user: User;
  theme: Theme;
  notifications: Notification[];
  language: 'en' | 'zh';
} | null>(null);

// ✅ BETTER: Split into separate contexts
const UserContext = createContext<User | null>(null);
const ThemeContext = createContext<Theme | null>(null);
const NotificationContext = createContext<Notification[] | null>(null);
const LanguageContext = createContext<'en' | 'zh'>('en');

// Components now subscribe only to what they need
function UserMenu() {
  // Only re-renders when user changes
  const user = useContext(UserContext);
  return <div>{user?.name}</div>;
}

function ThemedButton() {
  // Only re-renders when theme changes
  const theme = useContext(ThemeContext);
  return <button style={{ color: theme?.primaryColor }}>Click me</button>;
}

This prevents the classic Context performance problem where changing any value in the context causes all consumers to re-render.

# FAQ

# Q: Will Context slow down my application?

A: Context itself isn't slow, but improper use can cause unnecessary re-renders. Follow these practices: split contexts by data type, memoize context values, and use custom hooks to create subscription patterns for specific fields.

Consider using useMemo to prevent unnecessary re-renders:

      
typescript

function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState(initialTheme);
  
  // Memoize the context value to prevent unnecessary re-renders
  const value = useMemo(() => ({ theme, setTheme }), [theme]);
  
  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

# Q: Should I use Context for all global state?

A: No. Use Context for data accessed by multiple unrelated components (auth, theme, notifications). For complex app-wide state (shopping cart, filters, form state), consider dedicated state management libraries like Redux, Zustand, or TanStack Query, which offer better debugging, DevTools, and performance optimization.

# Q: Can I nest multiple Contexts?

A: Yes, and it's common in production applications. Organize contexts by concern:

      
typescript

<AuthProvider>
  <ThemeProvider>
    <NotificationProvider>
      <ModalProvider>
        <App />
      </ModalProvider>
    </NotificationProvider>
  </ThemeProvider>
</AuthProvider>

Nesting is fine and doesn't cause performance issues if each context is properly memoized and split by concern.

# Q: How do I test components that use Context?

A: Wrap components in a test Provider:

      
typescript

function renderWithAuth(component: React.ReactElement, user?: User) {
  return render(
    <AuthProvider initialUser={user}>
      {component}
    </AuthProvider>
  );
}

test('displays user name when authenticated', () => {
  const user = { id: '1', name: 'John Doe', email: 'john@example.com', role: 'user' };
  renderWithAuth(<UserProfile />, user);
  expect(screen.getByText('John Doe')).toBeInTheDocument();
});

test('shows login prompt when not authenticated', () => {
  renderWithAuth(<UserProfile />);
  expect(screen.getByText('Please log in')).toBeInTheDocument();
});

# Q: Is props drilling considered bad practice?

A: No. Props drilling is perfectly valid for shallow trees and actually helps maintain explicit data flow. The problem only emerges with deep nesting and when intermediate components don't use the data themselves. Use props for explicit, local communication and Context for implicit, global concerns.

# Q: When should I migrate from props drilling to Context?

A: When you start passing the same data through 3+ levels of intermediate components, consider Context. Signs you should refactor:

You're modifying a component just to accept and forward a prop it doesn't use
Multiple components at different depths need the same data
Refactoring the data structure requires changes throughout your component tree

# Real-World Architecture Patterns

# Enterprise E-Commerce Application

Here's how a production e-commerce application (similar to those at Alibaba or JD.com) structures state distribution:

      
typescript

// Global Framework Contexts (always use Context)
<AuthProvider>
  <ThemeProvider>
    <NotificationProvider>
      <ModalProvider>
        {/* Feature-level state management */}
        <ShoppingProvider>
          <SearchProvider>
            <FilterProvider>
              {/* Application with localized prop drilling for features */}
              <App />
            </FilterProvider>
          </SearchProvider>
        </ShoppingProvider>
      </ModalProvider>
    </NotificationProvider>
  </ThemeProvider>
</AuthProvider>

In this architecture:

Context: auth status, theme, global notifications, modals (cross-cutting concerns)
Props: product data, shopping cart items, search filters (feature-specific)
useReducer: Complex state machines for checkout process, form management

# Decision Tree for Choosing

      
typescript

Does component A need data?
├─ YES, and only B → E (1-2 levels)?
│  └─ Use Props Drilling
├─ YES, and multiple components at different depths?
│  └─ Use Context
├─ YES, and complex state with many interactions?
│  └─ Use Context + useReducer
└─ Data is framework-level (auth, theme, notifications)?
   └─ Always use Context

Questions? Share your Context and state management patterns in the comments. What's your preferred approach for managing global state in React applications?