Redux Toolkit 中 action payload 设计的最佳实践

在 Redux 状态管理库的使用过程中，action payload 的设计是一个需要仔细考虑的环节。本文将以 Redux 官方文档中的一个示例为切入点，探讨如何合理设计 action payload 结构。

问题背景

在 Redux 核心概念中，action 是描述状态变化的普通对象，通常包含一个 type 字段和可选的 payload 字段。当开发者从纯 Redux 迁移到 Redux Toolkit 时，可能会对 payload 的结构产生困惑。

原始示例中展示了一个手动编写的 todoToggled action creator：

const todoToggled = id => ({
  type: 'todos/todoToggled',
  payload: { id }
})

对应的 reducer 处理逻辑是：

case 'todos/todoToggled':
  return state.map(todo => {
    if (todo.id !== action.payload.id) {
      return todo
    }
    return { ...todo, completed: !todo.completed }
  })

而当使用 Redux Toolkit 的 createSlice 自动生成 action creator 时：

const todosSlice = createSlice({
  name: 'todos',
  initialState: [],
  reducers: {
    todoToggled(state, action) {
      const todo = state.find(todo => todo.id === action.payload)
      if (todo) {
        todo.completed = !todo.completed
      }
    }
  }
})

关键差异分析

1. payload 结构差异：

   • 手动版本将 id 包装在 payload 对象的 id 属性中
   • RTK 版本直接将 id 作为 payload 本身

2. 使用方式差异：

   • 手动版本需要访问 action.payload.id
   • RTK 版本直接使用 action.payload

3. 设计理念：

   • 手动版本遵循了 Flux Standard Action 规范，payload 通常是一个对象
   • RTK 版本更注重实用性和简洁性，允许 payload 是任何类型

最佳实践建议

1. 保持一致性：

   • 在项目中统一 payload 结构风格
   • 要么总是将参数作为 payload 的直接值
   • 要么总是将参数包装在 payload 对象的属性中

2. 考虑可扩展性：

   • 如果未来可能需要添加更多参数，采用对象形式更易扩展
   • 如果确定只需要单一参数，直接使用更简洁

3. TypeScript 支持：

   • RTK 对两种形式都有良好的类型推断支持
   • 对象形式在类型定义上可能更明确

实际应用示例

推荐的使用方式（对象形式）：

const todosSlice = createSlice({
  name: 'todos',
  initialState: [],
  reducers: {
    todoToggled: {
      reducer(state, action) {
        const { id } = action.payload
        const todo = state.find(todo => todo.id === id)
        if (todo) {
          todo.completed = !todo.completed
        }
      },
      prepare(id) {
        return { payload: { id } }
      }
    }
  }
})

这种形式既保持了清晰的参数命名，又为未来可能的扩展预留了空间，是 Redux Toolkit 推荐的做法。