Store 配置
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
Redux 常见问题：Store 配置
是否应该创建多个 store？能否直接导入 store 并在组件中使用？
原始的 Flux 模式描述了一个应用中可以存在多个 "store"，每个 store 存储不同领域的业务数据。但这种方式会引入一些问题，例如需要让一个 store 等待（waitFor）另一个 store 更新。在 Redux 中这种需求是不必要的，因为通过将单个 reducer 拆分为多个小 reducer 已经实现了数据域的分离。
与其他问题类似，在单个页面中创建多个独立的 Redux store 在技术上是可行的，但官方推荐的设计模式是只使用单一 store。单一 store 可以启用 Redux DevTools，简化数据持久化和恢复流程，并优化订阅逻辑。
在 Redux 中使用多个 store 的合理场景可能包括：
-
当通过性能分析确认应用存在因状态部分频繁更新导致的性能问题时
-
将 Redux 应用作为大型应用中的独立组件隔离时（此时可能需要为每个根组件实例创建独立 store）
然而，创建新 store 不应成为您的首选方案，特别是如果您有 Flux 使用背景。请优先尝试 reducer 组合方案，仅在无法解决问题时才考虑使用多个 store。
类似地，虽然您可以通过直接导入来引用 store 实例，但这在 Redux 中不是推荐模式。如果创建 store 实例后从模块导出，它会成为单例。这意味着在需要将 Redux 应用作为大型应用的组件隔离时，或者在启用服务端渲染时（因为服务端需要为每个请求创建独立的 store 实例），都会变得更加困难。
使用 React Redux 时，connect() 函数生成的包装类确实会检查是否存在 props.store，但最佳实践是将根组件包裹在 <Provider store={store}> 中，让 React Redux 处理 store 的传递。这样组件无需关心导入 store 模块，后续实现应用隔离或服务端渲染也会更加容易。
扩展阅读
文档
讨论
能否在 store 增强器中配置多个中间件链？中间件函数中的 next 和 dispatch 有何区别？
Redux 中间件的工作机制类似于链表。每个中间件函数可以选择调用 next(action) 将 action 传递给链中的下一个中间件，调用 dispatch(action) 重新从链表起点开始处理流程，或者直接终止 action 的后续处理。
中间件链由创建 store 时传递给 applyMiddleware 函数的参数定义。配置多个链无法正常工作，因为它们会有完全不同的 dispatch 引用，导致各中间件链实际上处于断开状态。
扩展阅读
文档
讨论
如何仅订阅部分状态？订阅时能否获取已分发的 action？
Redux 提供了单一的 store.subscribe 方法来通知监听器 store 已更新。监听器回调不会接收当前状态作为参数——它仅表示状态发生了变更。订阅逻辑随后可调用 getState() 获取当前状态值。
此 API 设计为无依赖的基础原语，可用于构建更高级的订阅逻辑。UI 绑定库（如 React Redux）可为每个连接的组件创建订阅。也可编写智能比较新旧状态的函数，当特定部分变更时执行额外逻辑。例如 redux-watch、redux-subscribe 和 redux-subscriber 提供了不同的订阅定义和变更处理方案。
新状态不传递给监听器是为了简化 Redux DevTools 等 store 增强器的实现。此外，订阅器设计用于响应状态本身而非 action。如需特别处理 action，可使用中间件方案。
扩展阅读
文档
讨论
相关库