理解Flux

2020-03-10 本文已影响0人 FoxLayla

原文：https://laylawang17.github.io/2020/03/10/%E7%90%86%E8%A7%A3Flux/

Flux 是一种前端应用开发架构，是一种管理数据流的模式。当访问数据对象时，一个组件实例只是简单的代理访问。如果有一处需要被多个实例共享的状态，可以简单的通过维护一份数据来实现共享。

Flux 中的关键概念

Dispatcher：是 App 的调度中心，接收 action 并分发给 store。一个 App 里只有一个 dispatcher。
Store：存储 App 的 data 和逻辑，且 store 中的 data 只能经由 action 修改，当 data 发生变化时会出发 change 事件通知 view 更新。store 注册在 dispatcher 上，并且给 dispatcher 提供一个回调函数用来更新自身，该回调函数接收 action 作为参数。一个 App 里可以有多个 store。
Action：是一个简单的对象，可以理解为 App 内部的 API，由 type 和 data 组成，用于语义化的描述 App 内发生的变化。每个 action 都会被所有的 store 接收到。一个组件里会存在很多 action。
View：请求 store 中的 data 用于展示，在用户与 App 进行交互时发出 action，并通过监听 store 的 change 事件重新渲染。

以 Todo List 这样的简单 App 展示一下上述概念之间的关系：

Flux原理

上图表明的是 Flux 架构是如何工作的，需要注意的是，在 Flux 架构中，数据的流动是单向的，可以理解为

数据的流动

Flux 架构带来的优势是，不存在数据双向绑定的情况，App 的状态完全由 store 控制，App 中各组件可以做到较好的解耦。

比如下图中的情况，如果底层组件 G 的某个行为想改变组件 F 的状态，数据需要先从 G 传递到根组件 A 再传递给 F。当 App 中有大量类似的复杂的数据传递路径后，用户与 App 的一次交互所引起的 App 的状态变更将会变得难以预测。即存在

多个视图依赖于同一状态。

来自不同视图的行为需要变更同一状态。

而在 Flux 架构中，store 作为一个类似于全局变量的存在持有着 App 所有的公共状态，并与每个组件间维持单一的数据流，我们很容易看到一个状态的变更引起了哪个组件的变化。

Flux架构给组件间数据流动带来的改变