MV*

说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

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

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

1. Dispatcher

一个全局惟一的数据流解决核心。有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作为参数传入监听函数。

2. Store

个别有以下几个性能：

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

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

3. Controller-View/View

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只是一种设计约定，各人对其都有本人的观点和想法。与其余架构相比其实没有相对的劣势劣势，只是提供解决方案的一种。