谈谈 Redux 与 Mobx 思想的适用场景

谈谈 Redux 与 Mobx 思想的适用场景

Redux 和 Mobx 都是当下比较火热的数据流模型，一个背靠函数式，彷佛成为了开源界标配，一个基于面向对象，低调的前行。

函数式 vs 面向对象

首先任何避开业务场景的技术选型都是耍流氓，我先耍一下流氓，首先函数式的优点，好比：

1. 无反作用，可时间回溯，适合并发。
2. 数据流变换处理很拿手，好比 rxjs。
3. 对于复杂数据逻辑、科学计算维的开发和维护效率更高。

固然，连原子都是由带正电的原子核，与带负电的电子组成的，几乎任何事务都没有绝对的好坏，面向对象也存在不少优点，好比：

1. javascript 的鸭子类型，代表它基于对象，不适合彻底函数式表达。
2. 数学思惟和数据处理适合用函数式，技术是为业务服务的，而业务模型适合用面向对象。
3. 业务开发和作研究不一样，逻辑严谨的函数式至关完美，但别期望每一个程序员都愿意消耗大量脑细胞解决平常业务问题。

Redux vs Mobx

那么具体到这两种模型，又有一些特定的优缺点呈现出来，先谈谈 Redux 的优点：

1. 数据流流动很天然，由于任何 dispatch 都会致使广播，须要依据对象引用是否变化来控制更新粒度。
2. 若是充分利用时间回溯的特征，能够加强业务的可预测性与错误定位能力。
3. 时间回溯代价很高，由于每次都要更新引用，除非增长代码复杂度，或使用 immutable。
4. 时间回溯的另外一个代价是 action 与 reducer 彻底脱节，数据流过程须要自行脑补。缘由是可回溯必然不能保证引用关系。
5. 引入中间件，其实主要为了解决异步带来的反作用，业务逻辑或多或少参杂着 magic。
6. 可是灵活利用中间件，能够经过约定完成许多复杂的工做。
7. 对 typescript 支持困难。

Mobx：

1. 数据流流动不天然，只有用到的数据才会引起绑定，局部精确更新，但免去了粒度控制烦恼。
2. 没有时间回溯能力，由于数据只有一份引用。
3. 自始至终一份引用，不须要 immutable，也没有复制对象的额外开销。
4. 没有这样的烦恼，数据流动由函数调用一鼓作气，便于调试。
5. 业务开发不是脑力活，而是体力活，少一些 magic，多一些效率。
6. 因为没有 magic，因此没有中间件机制，无法经过 magic 加快工做效率（这里 magic 是指 action 分发到 reducer 的过程）。
7. 完美支持 typescript。

到底如何选择

从目前经验来看，我建议前端数据流不太复杂的状况，使用 Mobx，由于更加清晰，也便于维护；若是前端数据流极度复杂，建议谨慎使用 Redux，经过中间件减缓巨大业务复杂度，但仍是要作到对开发人员尽可能透明，若是能够建议使用 typescript 辅助。