The Evolution of React State Management: From Props Drilling to Zustand

Introduction

“How can state be managed elegantly?” This is a core question that every React developer must face as a project grows. From simple state inside a component to complex global state shared across components, the React community has explored many solutions. The evolution of these solutions also reflects our deepening understanding of component-based development.

Stage One: The Simple Era — useState and Props Drilling

At the beginning, we only had useState (or this.state in class components). When state needed to be shared by multiple components, React’s official recommendation was “Lifting State Up.” We moved the state to the nearest common parent of those components, then passed the state and its update function down through props.

When the component hierarchy became deep, this pattern led to Props Drilling: some intermediate components received props only to pass them to descendants, without using those props themselves. This increased coupling between components and made refactoring and maintenance more difficult.

Stage Two: The Official Answer — Context API

To solve props drilling, React officially introduced the Context API. It lets us create a “context,” provide a value at the top of a component tree, and consume that value directly from a child component at any depth without manually passing it through every level.

// 1. 创建 Context
const ThemeContext = React.createContext('light');

// 2. 在顶层提供值
<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

// 3. 在子组件中消费
const theme = useContext(ThemeContext); // 'dark'

However, the Context API has a pitfall: performance. Whenever a Provider’s value changes, every component that consumes that Context rerenders, even if it only cares about a small part of the value object. This makes the Context API unsuitable for complex global state that changes frequently.

Stage Three: The Era of Unification — Redux

Before the Context API matured, Redux burst onto the scene and quickly became the de facto standard for state management in large, complex applications. Drawing on the Flux architecture and functional-programming ideas, it introduced:

• Single Source of Truth: The state of the entire application is stored in one store.
• State is read-only: The only way to change state is to dispatch an action.
• Changes are made with pure functions: A reducer receives the previous state and an action, then returns the new state.

With its predictability, powerful debugging tools (time travel), and rich middleware ecosystem, Redux solved state-management problems in large applications. But its drawback was equally apparent: cumbersome boilerplate. To implement a simple feature, developers had to write Actions, Reducers, and Dispatchers, creating a substantial mental burden.

Stage Four: The Renaissance — Lightweight, Hooks-First Solutions

As React Hooks became popular and developers reconsidered Redux’s complexity, a new generation of lighter state-management libraries emerged in the community. They shared a concise API, a simple mental model, and extensive use of Hooks.

Zustand is a standout example. It provides an extremely simple create function for building a store, and offers:

• No Provider required: The store exists outside the React component tree and can be imported anywhere.
• A minimal API: State can be accessed and updated through a single Hook.
• Selective subscriptions and better performance: A component can subscribe only to the part of state it needs, avoiding the Context API’s performance problem.

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

function Counter() {
  // 只订阅 count 的变化
  const count = useStore(state => state.count);
  return <h1>{count}</h1>;
}

Conclusion: There Is No Silver Bullet—Choose for the Situation

The history of React state management tells us there is no once-and-for-all “best solution,” only the solution that best fits the current situation.

• useState: Always the first choice for local component state.
• Context API: Suitable for global data that does not change often, such as themes and user authentication information.
• Zustand / Jotai: For most applications that need global client-side state, they strike an excellent balance between performance and developer experience.
• Redux (Redux Toolkit): Still a reliable choice for very large applications that require strict data-flow conventions, complex middleware, and powerful debugging capabilities.