关于javascript:说一说-Flux的小白知识

说 Flux 之前，先说说熟知的 MV* 模式。MV* 个别指 MVC/MVVM.
MVC 如咱们熟知：

M = Model，负责数据的保留，测验，获取等。
V = View，数据的展现，DOM 元素。
C = Controller，与传统的 controller 定义不同，前端中的 controller 的定义比拟含糊。但个别作为 Model 和 View 之间的协调。

而 MVVM，就是在 MVC 的根底上，用 VM(ViewModel)代替 Controller。
也就是 数据绑定，界面与 VM 的数据状态能够相互影响。

说到这里，其实不难想象，数据能够多方影响，来源不明且多样。凌乱的数据流向导致我的项目前期，开发保护的难度加大。Model 的构建数量过多，会影响 View 的构建构造与渲染优化。

Flux 的命名来自于拉丁语 Flow。是一套基于 dispatcher 的前端利用架构模式。
\> 核心思想是 数据和逻辑永远单向流动。
比照 MV* 构造，Flux 模式有着数据起源繁多，数据变动可溯源的长处。让逻辑架构更加审慎清晰。

这里和 React 组件间的单向流动不同。React 的单向数据流动是个别指基于 Props 的组件间通信设计。而 Flux 的单向数据流，则是基于整个架构上的。

一个全局惟一的数据流解决核心。有 3 个次要 API：

dispatch(object payload) : void

用于散发 action。执行已注册的监听。

* **register(function callback) : string**
注册监听用于响应 dispatch。返回一个 token 可供 waitFor()应用。* **waitFor(array ids) : void**
当在回调中遇到 waitFor()时，该回调暂停执行。在 waitFor()实现执行并回调之后，再继续执行原始回调。此办法能够用于期待并执行其余 store 操作。

*action 是一个对象类型，在 FSA 标准中对其字段进行了列举：type，error，payload，meta。其中 type（或者 name）为必须，是 store 依据 action 批改数据的根据。
在 Facebook 的 Flux 实例源码中，在 Dispatcher 类里定义了一个 \_callbacks 数组，保留了在 register 办法中注册的监听器。并在 dispatch 办法中遍历执行，且把 action 作为参数传入监听函数。

个别有以下几个性能：

保留状态数据(state)。
裸露一个 Getter 用于获取状态
定义批改数据的逻辑。
调用 Dispatcher.register 办法将本人注册为一个监听器。
定义一个更新监听办法

当调用 dispatch 散发 action，store 在 register 办法中注册的监听就会被调用，同时失去传入 action。
store 将依据 action 携带的 type 判断是否响应操作。如响应，调用外部的数据批改逻辑。并在执行结束后触发更新事件。

Controller-View 个别作为最顶层的 View，负责 Store 和 View 之间的数据传递。

** 进行 store 与 View 的绑定，定义数据更新及传递形式。** 这里说的 View 个别是 React，当然也能够是其余框架。
** 监听 Store 收回的更新事件。** 当 Store 更新后，Controller-View 会从新获取 store 中的数据，并触发界面重绘。

class CounterContainer extends Component {
static getStores() {
return [CounterStore];
}

static calculateState(prevState) {
return {
counter: CounterStore.getState(),
};
}

render() {
return ;

}
}

const container = Container.create(CounterContainer);
下面是 Flux 官网文档中将一个 React Class 创立为 Controller-View 的简略调用实例。class 向外裸露 getStores、calculateState 两个办法：

getStores 用于绑定 Class 关联的 Store。
calculateState 用于获取 Store 中的数据转化为本身的 State，并作为 props 传给子组件。

Container.create 办法中，会获取绑定的 Store 中 dispatchToken，而后依据 dispatchToken 利用 waitFor 办法期待 Store 实现数据更新逻辑，而后执行更新回调。
当 Store 触发更新后，Container 会调用 setState 办法更新 State，同时触发画面渲染更新。
当然关联 store、更新回调等能够有多种实现办法，以上只是其中一种思路。

View 就是界面体现了，View 能够通过 props 取得 Container 传入的数据。
如果 View 须要批改数据，必须应用 dispatcher 散发 action的形式进行批改。
这也是单向数据流的重要特色，view 不能间接批改数据。

说起 Flux，很多第一句就是单向数据流。但其实数据中心化管制，也是特点之一。
所有的更改，必须通过 action 收回，dispatcher 调配。store 中心化管制了数据，令数据管理和问题追究变得清晰容易。
action 的治理，令架构不必关怀分别数据更新的触发形式，所有触发形式都形象成了 action。Flux 架构并非 React 独有，也能作为其余组件框架的状态治理计划。
后面说到 Flux 对于 MV* 架构的长处，当然 Flux 自身也有的坑。尽管前面提出的 Redux，则对 Flux 中 state 与更新逻辑没有拆散形象，没有对 URL 路由进行治理等问题进行改良。但 Flux 只是一种设计约定，各人对其都有本人的观点和想法。与其余架构相比其实没有相对的劣势劣势，只是提供解决方案的一种。

关于javascript:说一说-Flux的小白知识

MV*

Flux

1. Dispatcher

2. Store

3. Controller-View/View