关于redux:从-MVC-到-Flux从-Redux-到-Mobx

前端状态治理的工具库纷杂，在开启一个新我的项目的时候不禁让人纠结，该用哪个？其实每个都能达到我的目标，咱们想要的无非就是治理好零碎内的状态，使代码利于保护和拓展，尽可能升高零碎的复杂度。

应用 Vue 的同学可能更违心置信其官网的生态，间接上 vuex/pinia，不必过多纠结。因为我平时应用 React 较多，故就以后利用较宽泛的 Redux、Mobx 俩工具库为例，研读了一番，记录下本人的一些闲言碎语。

留神：以下不会波及到各个库的具体用法，多是探讨各自的设计理念、推崇的模式（patterns），提前阐明，免得耽搁大家工夫。

Redux、Mobx 或多或少都借鉴了 Flux 理念，比方大家常常听到的“单向数据流”这项准则最开始就是由 Flux 带入前端畛域的，所以咱们先来聊聊 Flux。

Flux

Flux 是由 facebook 团队推出的一种架构理念，并给出一份代码实现。

为什么会有 Flux 的诞生？

Facebook 一开始是采纳传统的 MVC 范式进行零碎的开发

但随着业务逻辑的简单，慢慢地发现代码里越来越难去退出新性能，很多状态耦合在了一起，对于状态的解决也耦合在了一起

造成了 FB 团队对 MVC 吐槽最深的两个点：

1. Controller 的中心化不利于扩大，外围是因为 Controller 里须要解决大量简单的对于 Model 更改的逻辑
2. 对于 Model 的更改可能来源于各个方向。可能是开发者自身想对 Model 进行更改、可能是 View 上的某个回调想对 Model 进行更改，可能是一个 Model 的更改引发了另一个 Model 的更改。

咱们能够大略总结出，基于 MVC 的数据流向就有三种：

• Controller -> Model -> View
• Controller -> Model -> View -> Model -> View … (loop)
• Controller -> Model1 -> Model2 -> View1 -> view2 …

并且这三种数据流向在理论业务中还很有可能是交错在一起。

为了改善以上 MVC 在简单利用中的缺点，升高零碎整体复杂度，FB 团队推出了 Flux 架构，联合 React 重构了他们的代码，这就是 Flux 架构诞生的起因。

Flux 具体是什么

Flux 由几个局部组成：

• Store
• Action
• View
• Dispatcher

Store 就是寄存 Model 的中央，View 和 MVC 的 View 一样就是视图，Action 能够了解为操作 Model 的行为，Dispatcher 能够了解为找到 Action 对应 Store 并执行操作的散发执行者。

Dispatcher 是 Flux 的外围，它把对 Model 的操作给对立了起来，在 Flux 里，Dispatcher 与 View 能够视为 Model 的惟一输入输出。

那么绝对于 MVC 带来的变动或者说益处是什么呢？

首先，数据流对立了，无论谁想要操作 Model，必须通过 disptacher，同时 dispatcher 与 Action 配合，等同于是给 Model 约定了无限的、分来到的几种操作。比照 MVC 里中心化的 Controller 中对大量简单的 Model 逻辑的操作，在 Flux 中就是被形象拆散到一个个 Action 里去了。所以状态在整个零碎里的流向就是：

Action -> dispatcher -> Model -> View -> Action -> dispatcher -> Model -> View …

这就是所谓的“单向数据流”。绝对于 MVC 中多种数据流穿插，单向数据流明显降低了零碎的复杂度。

又因为 Action 给 Model 约定了无限的几种操作，仅依据 Action 的输出，开发者就晓得会产生怎么的变更，进步了 代码的可预测性。

基于 MVC 范式的代码，我的项目的长期维护者可能分明各个中央状态变更会引发什么操作，然而若团队来了新人，想搞清楚这些必定须要费不少劲，如果基于 Flux 架构，开发者只须要追踪一个 Action 是怎么在整个零碎中流动的，就晓得零碎的其余部分是怎么工作的了。因为 Flux 的数据流动是单向的且统一的。比方通过 Action 就晓得要对状态做怎么的变更，再搜一下哪里用了变更的状态就晓得这里的视图会 rerender，同样的搜一下哪个中央 disptach 了这个 action，就晓得谁想对状态做出扭转。

另外，还能够联合纯函数的概念来感触下 Dispatcher 的设计

这在 Redux 的实现中体现地尤为显著，就是在找到 Action 对应的 Store 后，单纯只负责依据 Action 解决对 Model 的改变逻辑，不会扭转入参或内部变量，雷同的输出始终对应雷同的 Store 更改。意味着之后任意一个工夫点做出一个之前工夫点的 Action，失去的更改后的状态与之前失去的是统一的。这就是所谓的“工夫旅行”性能的原理，“工夫旅行”实质就是记录下每一次数据批改，只有每次批改都是无状态的，那么咱们实践上就能够通过批改记录还原之前任意时刻的数据。

联合纯函数的设计至多能够带来两点益处：

2. 不便开发者调试。咱们能够利用“工夫旅行”复现之前任意工夫点的状态，能够对立地在 dispatcher 里加日志看到何时做了什么扭转。
3. 基于纯函数构建的代码更容易写单测

Redux

Redux 就是基于 Flux 架构理念的一种函数式地实现，并做出了一些优化，所以 Redux 领有 Flux 架构的所有长处。

上图是 Redux 官网给的展现 Redux 工作原理的 gif 图，奢侈一点展现 Redux 的外围组成就是：

其中，Reducer 就是 Flux Dispatcher 的纯函数式实现，找到 Action 对应的 Model，返回一个更改后的对象给 Redux，Redux 在 Store 上利用更改。

据以上俩图，能够显著感知到 Redux 数据流动是单向的:

action -> middleware -> reducer -> store -> view -> action -> middleware -> reducer -> store -> view …

解释 Redux 三个根本准则

Redux 官网表明能够用三个根本准则形容 Redux：“繁多数据源“、“只读的 state“、“应用纯函数来执行批改“。

“繁多数据源“绝对于扩散数据源必定是劣势的，除非各个数据源之间毫无分割。但只有是有分割的多个数据源，你始终要通过某些操作把各个数据源给分割起来，无疑减少了复杂度。

“只读的 state”也就是不容许间接批改 Model，必须创立个 action，交给 reducer 解决，保障 Model 只有惟一输出，这是践行单向数据流的根本要求。

“应用纯函数来执行批改”就是要求用户编写的 reducer 必须得是纯函数，不便不便开发者调试也易于写单测。

另外，要求开发者编写纯函数的 reducer 还有个想突出点就是 Redux 推崇的 Immutable 个性。

Immutable 与 Mutable

什么是 Immutable，什么是 Mutable？

Immutable 意为「不可变的」。在编程畛域，Immutable Data 是指一种一旦创立就 不能更改 的数据结构。它的理念是：在更改时，产生一个与原对象齐全一样的新对象，指向不同的内存地址，互不影响。

Mutable 意为「可变的」。与 Immutable 相同，Mutable Data 就是指一种创立后能够间接更改的数据结构。

对于 JS 而言，所有原始类型 (Undefined, Null, Boolean, Number, BigInt, String, Symbol) 都是 Immutable 的，然而援用类型的值都是 Mutable 的。

举两个例子直观感触下：

例一：

let a = {x: 1};
let b = a;
b.x = 6;

a.x // 6

例二：

function doSomething(x) {/* 在此处扭转 x 会影响到 str 和 obj 吗？*/};
var str = 'a string';
var obj = {an: 'object'};
doSomething(str); // 根底类型都是 immutable 的, function 失去的是一个正本
doSomething(obj); // 对象传递的是援用，在 function 内是 mutable 的
doAnotherThing(str, obj); // `str` 没有被扭转, 然而 `obj` 可能曾经变动了。

js 中其实有几种形式能够让值变为 Immutable 的，为了不跑题，大家能够去 wikipedia 拓展浏览。要留神的是，无论是writeable: false 或 Object.freeze 或 const，其润饰 / 解冻 / 申明的属性 / 值都只在第一层失效，如果属性 / 值嵌套了援用类型值，则须要递归去润饰 / 解冻 / 申明能力达到整体 Immutable 的目标。

Immutable 与 Mutable 的优缺

Mutable

其实比拟不言而喻，Mutable 的数据，开发者能够间接更改，然而要累赘更改后副作用的思考。

长处：操作便当。

毛病：开发者心田要晓得更改了 Mutable 数据后，会导致哪些副作用，会怎么影响到其余用到该数据的中央。

Immutable

其实就是 Mutable 的相同，不过能够基于 Immutable 个性做一些额定的性能。

长处：

1. 防止了数据更改的副作用（在多线程语言中就是有了所谓“线程安全性”）

   JS 尽管没有多线程的概念，但有竞态的概念。JS 中援用类型的值都是按援用传递的，在一个简单利用中会有多个变量指向同一个内存地址的状况，如果有多个代码块同时更改这个援用，就会产生竞态。你须要关怀这个对象会在哪个对方被批改，你对它的批改会不会影响其余代码的运行。应用 Immutable Data 就不会产生这个问题——因为每当状态更新时，都会产生一个新的对象。

2. 状态可追溯

   因为每次批改都会创立一个新对象，且对象不会被批改，那么变更的记录就可能被保留下来，利用的状态变得可控、可追溯。Redux Dev Tool 和 Git 这两个可能实现「工夫旅行」的工具就是秉承了 Immutable 的哲学。

毛病也是绝对于 Mutable 形式的：

1. 额定的 CPU、内存开销
2. 达到批改值的目标要做额定的操作

只管生态内有如 Immutable.js、Immer.js 等库帮忙咱们更便捷地操作 Immutable 更改，然而这两个毛病也是无奈防止的，只是尽可能地做优化。

至于是采纳 Immutable 还是 Mutable 的计划去写代码，集体感觉还是得 case by case 地去聊，显然 Redux 推崇 Immutable，基于此提供了工夫旅行的性能，React 举荐开发者应用 Immutable，是因为 React 的 UI = fn(states) 模型中，React 对 state 是 shallowMerge 的，如果 mutable state 没扭转援用，React 会认为不须要去 diff，天然不会 rerender。然而 Mobx 就是推崇 Mutable 的，开发者应用体验很好。

Mobx

Mobx 是一个推崇主动收集依赖与执行副作用的响应式状态治理库，举荐开发者应用 Mutable 间接更改状态，框架外部帮咱们治理（派生）每个 Mutable 的副作用并实现最优解决。

由上图可感知 Mobx 也是践行单向数据流的理念：

Action -> State -> Computed Value -> Reaction(like render) -> Action …

这里引入了新的概念是 Computed Value 和 Reaction。Mobx 是多 Store 的，分割多个数据源的数据能够用 Computed Value，同一个数据源想要多个数据派生出一个新数据也能够用 Computed Value。Reaction 的话就是 state 的所有副作用，能够是 render 办法，能够是 Mobx 自带的 autorun、when 等。

Mobx 想要达到的目标其实就是 开发者能自在地治理状态、让批改状态的行为简略间接，其余交给 Mobx。

想要达到这一目标，Mobx 外部就要做更多的事件，其作者 Michel Weststrate 有在一篇推文中论述过 Mobx 设计准则，然而有点过于细节，不相熟 Mobx 底层机制的同学可能不太看得懂。以下，在基于这篇推文联合对源码的探索，我提炼一下，感兴趣能够去看原文。

自荐对 Mobx 源码的解析文章：Mobx 源码与设计思维。文章较长，倡议专门找工夫宁静地一口气看完。

对状态扭转作出反应永远好过于对状态扭转作出动作

针对这点其实与 Vue 响应式传递的理念雷同，就是 数据驱动。

再剖析这句话，“作出反应”意味着状态与副作用的绑定关系由框架（库）给你做好，状态扭转主动告诉到副作用，不必使用者（开发者）人为地解决。

“作出动作”则是在使用者已知状态更改的状况下，手动去告诉副作用更新。这起码就有一个操作是使用者必做的：手动在副作用内订阅状态的变动，这至多带来两个缺点：

1. 无奈保障订阅量的冗余性，可能订阅多了可能少了，导致利用呈现不合乎预期的状况。
2. 会让业务代码变得更 dirty，不好组织

最小的、统一的订阅集

以 render 作为副作用举例，如果 render 里有条件语句:

render() {if (依赖 A) {return 组件 1;}
  return 依赖 B ? 组件 2 : 组件 3；}

首先，如果交给用户手动订阅，必须只能依赖 A、B 的状态一起订阅才行，如果订阅少了无奈呈现预期的 re-render。

而后交给框架去做解决怎么才好？依赖 A、B 一起订阅当然没故障，然而假如依赖 A、B 初始化时都有值，咱们有必要让 render 订阅依赖 B 的状态吗？

没必要，为什么？想一想如果此时依赖 B 的状态变动了 re-render 出现的成果会有什么不同吗？

所以在初始化时就订阅所有的状态是冗余的，如果应用程序简单、状态多了，没必要的内存调配就会更多，对性能有损耗。

故 Mobx 实现了 运行时解决依赖 的机制，保障副作用绑定的是最小的、统一的订阅集。源码见 Mobx 源码与设计思维 中“getter 里干了啥？”与“解决依赖”章节。

派生计算（副作用执行）的合理性

说人话就是：杜绝失落计算、冗余计算。

失落计算：Mobx 的策略是引入状态机的概念去治理依赖与派生，让数学的逻辑性保障不会失落计算。

冗余计算：

1. 对于非计算属性状态，引入事务概念，保障同一批次中所有对状态的同步更改，状态对应的派生只计算一次。
2. 对于计算属性，计算属性作为派生时，当其依赖变动，计算属性不会立刻从新计算，会等到计算属性本身作为状态所绑定的派生再次用到计算属性值时才去从新计算。并且计算出雷同值会阻止派生持续解决。

Redux vs Mobx

如下面剖析，Redux 是一个重思维轻代码的状态治理库，Mobx 则是相同，框架帮咱们做了更多的事，用起来简略。

略微总结下区别：

1. Redux 要求开发者按它的模式（patterns）写代码，Mobx 则自在许多，用起来更简略。绝对地，基于 Redux 开发的零碎健壮性要强一些，应用 Mobx 却治理不好状态的话，会使零碎更难保护（咦，这为啥没渲染？咦！这为啥渲染了这么屡次？？(逃）。
2. Redux 联合函数式与 Immutable 的个性提供了工夫旅行性能，更不便开发者调试与回溯状态。Mobx 则是有提供一个全局监听的钩子，监听每一个状态扭转与副作用的触发，咱们间接打日志调试，然而绝对于 Redux 必定是没那么不便的。
3. Redux 推崇单 Store 治理状态，升高状态治理的复杂度。Mobx 则不给开发者设限，开发者能够以任一模式治理状态，如果是多 Store，提供了 Computed Value 作为多 Store 数据的分割桥梁。
4. Mobx 框架外部会帮咱们实现最优渲染（副作用执行），Redux 则须要咱们编写各种 selector 或用 memo 手动去优化 …

以上，欢送有理有据地斧正、补充。

参考：

• Hacker Way: Rethinking Web App Development at Facebook
• Becoming fully reactive: an in-depth explanation of MobX
• Immutable object