谈谈 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 辅助。

你可能感兴趣的:(谈谈 Redux 与 Mobx 思想的适用场景)