[轉]Redux状态管理之痛点、分析与改良

https://segmentfault.com/a/1190000009540007


WebApp场景下的隐患

举个我曾经在另一篇博客中提到过的例子，一个业务流程有三个页面A/B/C，用户通常按顺序访问它们，每步都会提交一些信息，如果把信息存在Store中，在不刷新的情况下C页面可以直接访问A/B页面存进Store的数据，而一旦用户刷新C页面，这些数据便不复存在，使用这些数据很可能导致程序异常。

它可以从两方面缓解上述问题：

1. 抽象问题：每个Page独立创建store，解决状态树的一对多问题，一个状态树(store)对应一个组件树(page)，page在设计store时不用考虑其它页面，仅服务当前页。当然，由于Reducer仍然需要独立于组件树声明，抽象问题并没有根治，面向领域数据和App state的抽象仍然比UI state更自然。它仅仅带给你更大的自由度：不再担心有限的状态树如何设计才能满足近乎无限的UI state。
2. 刷新、分享隐患：每个Page创建的Store都是完全不同的对象，且只存在于当前Page生命周期内，其它Page不可能访问到，从根本上杜绝跨页面的store访问。这意味着能够从store中访问到的数据，一定是可靠的。

2017.08.27 更新

这个方案在实践中，仍然遇到了一些问题，其中最最重要的，则是替换store后，跨页面action的问题

为了应对这个问题，我考虑了几种方案：

1. 回到应用单一store：pageReducer的特性通过store.replaceReducer完成。当初为每个页面创建store是想让状态彻底隔离，而在replaceReducer后页面之间如果有相同的reducer则状态不会被重置，这是一个担心点。同时一个副作用是牺牲掉每个page定制化middleware的能力
2. 为这类跨页面的action建立一个队列，在上个页面将action推进队列，下个页面取出再执行。此方案属于头痛医头，只能解决当前的case，对于websocket等类似问题比较无力。
3. 定制thunk middleware，通过闭包获取最新的store

在权衡方案的通用性、理解难度等方面后，目前选择了第一种。