Redux 存在的问题 #16
Description
Redux 存在的问题
优点就不多说了，文档上全是... 说几点应用中遇到的问题吧：
- Data Model（远程数据） 和 UI Model 的混合
这个是应用数据混乱的原因，Data Model 由服务器维护，UI Model 由本地浏览器维护。应用中需要填充的数据应该是： (Data Model).filter(UI Model) + UI Model。
Model 需要进行一定的抽象，尤其是 Data Model 需要提供缓存机制和自同步机制。
Falcor 是不错的选择：通过 dataSource 来实现 Model 抽象（async-Model），提供 get，set，call 等统一的异步操作接口；使用 JSON Graph 作为 Model 数据结构，通过 $ref 实现数据共享；提供缓存机制和自同步机制。 - 初始状态时渲染
初始状态时，远程数据一般为空，React Virtual DOM 是同步立即渲染的，所以组件初始渲染时需要考虑许多 props 为空的情况。
一种解决方案是 async-props ：在 route component(react-router) 处定义函数 loadProps（获取渲染所需要的 props）。 执行应用刷新时，先调用当前路由所有 route component 的 loadProps 来获取 props，然后再进行渲染。 - 在 action 处获取远程数据
容易混淆 action 的本质，action 实际上是用户的 UI 操作，只应该改变 UI 状态，数据更新只是带来的副作用。
这种行为会导致应用中会有很多单纯获取数据的 action，或者是带有回调（更新数据） action。（注：可以使用 redux-thunk 返回 promise 来实现 action 链式调用：https://github.com/onebook/redux-action）
上述的 async-props + falcor(async-model) 能很好地解决这个问题，action 中只执行 set/call 操作， 数据获取（get props）在渲染前执行（loadProps）。
Falcor 存在的问题是和传统 REST API 的不兼容，不过我们可以做一些调整：在前端定义 Data Model，在 Model router 中执行 REST API；关于数据自同步，则需要 Model 严格遵循 JSON Graph $ref 思想（引用实体），退化方案可能是手动使得"需要更新的数据"缓存失效。