Redux Toolkit中使用combineSlices与RTK Query的注意事项

背景介绍

在使用Redux Toolkit开发应用时，开发者经常会遇到需要将RTK Query与状态管理相结合的场景。特别是当应用需要实现撤销/重做功能时，如何正确处理RTK Query的状态就成为一个关键问题。

核心问题

在Redux Toolkit中，当开发者尝试将RTK Query生成的API与redux-undo这样的撤销库结合使用时，容易出现"Error: No data found at state.api"的错误。这是因为RTK Query期望其状态直接存储在根状态下的api属性中，而redux-undo等库会改变状态结构。

问题根源

RTK Query生成的API中间件和hooks都假设API状态位于state.api路径下。如果使用redux-undo这样的库包装整个根reducer，状态结构会变为state.present.api，导致RTK Query无法找到预期的状态位置。

解决方案

1. 避免全局包装

最直接的解决方案是避免使用redux-undo包装整个根reducer。因为RTK Query的状态不应该被撤销/重做，它管理的是缓存数据而非应用状态。

2. 选择性包装

如果需要实现部分状态的撤销功能，应该只对特定的slice进行包装，而不是整个根reducer。可以创建一个工具函数来帮助实现这一点：

function undoableSlice(slice) {
  return undoable(slice.reducer, {
    // 配置选项
  });
}

const rootReducer = combineReducers({
  api: api.reducer,
  undoableSlice: undoableSlice(someSlice),
  // 其他reducers
});

3. 状态结构调整

如果已经使用了全局包装，需要调整代码以适应新的状态结构。这意味着所有访问状态的代码都需要从state.api改为state.present.api。这种方法虽然可行，但不推荐，因为它增加了代码的复杂性。

最佳实践

1. 分离缓存状态与应用状态：RTK Query管理的API状态本质上是缓存，不应该与应用状态混为一谈。

2. 精细控制撤销范围：只对那些真正需要撤销功能的状态应用undoable包装。

3. 保持RTK Query状态结构：确保RTK Query的状态始终位于根状态的api属性下，避免中间件和hooks失效。

实施建议

对于新项目，建议从一开始就规划好状态结构，明确哪些状态需要撤销功能。对于已有项目，如果已经使用了全局包装，可以考虑逐步重构，将RTK Query状态移出undoable包装范围。

总结

在Redux Toolkit生态中，RTK Query是一个强大的数据获取和缓存工具，而redux-undo等库提供了有用的状态管理功能。理解它们各自的状态结构需求，合理设计应用架构，才能充分发挥它们的优势，避免常见的陷阱。