Redux中CombineReducers多子Reducer与单对象键值Reducer对比

Great question! This is a common point of confusion when getting started with Redux, so let's break down the key differences between these two approaches clearly.

Core Differences #

1. Single Responsibility & Code Organization #

When you use combineReducers with slice reducers like foo and bar, each reducer only cares about its own slice of the state. The foo reducer never touches the bar part of the state, and vice versa. This follows the single responsibility principle—each piece of code does one thing and does it well.

In contrast, a single root reducer that modifies individual keys directly has to handle all actions and the entire state object. As your app grows (say, adding a baz slice later), this reducer will get bloated with more switch cases, making it harder to scan, maintain, or collaborate on.

2. State Update Safety & Isolation #

Slice reducers receive only their own portion of the state. For example, the foo reducer gets state.foo as its state argument, and returns a new value for just foo. combineReducers automatically handles merging this new value back into the full state object.

With a single reducer, you have to manually spread the entire state every time you update a key to avoid mutating state or losing other slices:

// Single reducer approach
function rootReducer(state = {foo: null, bar: null}, action) {
  switch(action.type) {
    case types.A:
      // Must spread existing state to preserve bar!
      return {...state, foo: action.value};
    case types.B:
      // Same here—can't forget to spread state
      return {...state, bar: action.value};
    default:
      return state;
  }
}

Forget the spread operator, and you'll accidentally wipe out other parts of the state—an easy bug to make, especially in larger apps.

3. Reusability & Scalability #

Slice reducers are standalone and reusable. If you need to manage a similar foo-like state elsewhere in your app (or even in another project), you can just import the foo reducer and drop it in.

Adding new state slices is also trivial with combineReducers: write a new slice reducer, add it to the combineReducers object, and you're done. No need to modify existing reducer code. With a single reducer, you'd have to add new switch cases and update the initial state definition, creating tighter coupling between parts of your state.

4. Debugging & Traceability #

Redux DevTools work beautifully with slice reducers. You can see exactly which slice reducer was triggered by each action, and how that specific slice of state changed. This makes it way easier to track down bugs—you don't have to scan a giant switch statement to find where a state update went wrong.

With a single reducer, all state updates are lumped together in one place. Debugging becomes a chore, especially when multiple actions affect different parts of the state.

5. Initial State Management #

Slice reducers can define their own initial state. For example, your foo reducer could default to '' instead of undefined, and combineReducers will automatically assemble the full initial state from all slice defaults.

With a single reducer, you have to define the entire initial state in one place. As your state grows, this becomes a longer, harder-to-maintain object.

When to Use Which? #

• Use combineReducers (or modern Redux Toolkit's createSlice) for almost all apps: It's the official recommended approach, keeps your code clean, scalable, and less error-prone.
• Use a single reducer only for tiny apps: If your state has 2-3 keys and you don't expect it to grow, a single reducer might be simpler. But even then, slice reducers are a better habit to build.

内容的提问来源于stack exchange，提问作者xli