Flux 原始模型中一个应用有多个 “store”,每个都维护了不同维度的数据。这样导致了类似于一个 store “等待” 另一 store 操作的问题。Redux 中将 reducer 分解成多个小而美的 reducer,进而切分数据域,避免了这种情况的发生。
正如上述问题所述,“可能” 在一个页面中创建多个独立的 Redux store,但是预设模式中只会有一个 store。仅维持单个 store 不仅可以使用 Redux DevTools,还能简化数据的持久化及深加工、精简订阅的逻辑处理。
在 Redux 中使用多个 store 的理由可能包括:
然而,创建新的 store 不应成为你的第一反应,特别是当你从 Flux 背景迁移而来。首先尝试组合 reducer,只有当它无法解决你的问题时才使用多个 store。
类似的,虽然你 能 直接导入并获取 store 实例,但这并非 Redux 的推荐方式。当你创建 store 实例并从组件导出,它将变成一个单例。这意味着将很难把 Redux 应用封装成一个应用的子组件,除非这是必要的,或者为了实现服务端渲染需要为每一个请求创建单独的 store 实例。
借助 React Redux,由 connect()
生成的包装类实际上会检索存在的 props.store
,但还是推荐将根组件包装在 <Provider store={store}>
中,这样传递 store 的任务都交由 React Redux 处理。这种方式,我们不用考虑 store 模块的导入、 Redux 应用的封装,后期支持服务器渲染也将变得更为简便。
文档
讨论
next
和 dispatch
之间区别是什么?Redux middleware 就像一个链表。每个 middleware 方法既能调用 next(action)
传递 action 到下一个 middleware,也可以调用 dispatch(action)
重新开始处理,或者什么都不做而仅仅终止 action 的处理进程。
创建 store 时, applyMiddleware
方法的入参定义了 middleware 链。定义多个链将无法正常执行,因为它们的 dispatch
引用显然是不一样的,而且不同的链也无法有效连接到一起。
文档
讨论
Redux 提供了独立的 store.subscribe
方法用于通知监听器 store 的变更信息。监听器的回调方法并没有把当前的 state 作为入参,它仅仅代表了 有些数据 被更新。订阅者的逻辑中调用 getState()
获取当前的 state 值。
这个 API 是没有依赖及副作用的底层接口,可以用于创建高阶订阅者逻辑。类似 React Redux 的 UI 绑定能为所有连接的组件都创建订阅。也可以用于编写智能的新旧 state 比对方法,从而在某些内容变化时执行额外的逻辑处理。示例 redux-watch 和 redux-subscribe 提供不同的方式用于指定订阅及处理变更。
新的 state 没有传递给监听者,目的是简化 store enhancer 的实现,比如 Redux DevTools。此外,订阅者旨在响应 state 值本身,而非 action。当 action 很重要且需要特殊处理时,使用 middleware。
文档
讨论
库