认识Flux架构

在React中管理应用数据比较麻烦，一般借助于Redux这种管理应用状态的框架处理数据流动。那么了解Redux前就必须先了解它的设计思想来源——Flux。这篇文章从Flux的核心思想谈起。

MVC

MVC的概念

实际上Flux设计之初就是为了弥补在当时大行其道的MVC框架的缺陷。MVC框架把应用分为3个部分：

• Model：负责保存应用数据并和后端交互同步或校验数据。不处理应用交互状态。
• View: 负责渲染应用视图界面，不处理应用数据。
• Controller: 负责接收用户输入，然后调用Model处理数据逻辑进而应用到View层。主要负责数据变动后Model和View间的协调。

MVC的缺陷

乍一看这种模式似乎很合理，但其实存在一个致命的缺陷——混乱的数据流动。本来应该由Controller去修改Model,由于Model层对外暴露了设置方法，导致View层可以随意改动Model，甚至Model层之间也能相互改变。

如果渲染View的函数只有一个并放在Controller中，无论谁要修改Model时应该调用Controller重渲染，这样就能保证数据的流动清晰了，但重渲染又会带来严重的性能和体验问题。

两难的选择是MVC无法解决的，于是Flux应运而生了。

Flux

Flux的概念

一个Flux大致分为以下四个部分：

• Dispatcher: 处理动作分发
• Store: 处理数据存储和数据更新的相关逻辑
• Action: 驱动Dispatcher
• View: 处理应用视图渲染

Flux可以说是MVC的演化版，类比的话Dispatcher类似于Controller,Store类似于Model,View类似于View了，多出来的Action可以理解为用户请求。区别在于MVC里每增加一个功能就要新增一个Contoller函数，而Flux只需要新增一个Action,Dispatcher始终只有一个对外接口。

Flux的核心思想就是数据和逻辑永远单向流动。接下来就根据常规工作流程详细介绍各部分是如何工作的。

dispatcher

首先所有的Flux应用都有且仅有一个Dispatcher。我们只需要关注两个核心API

• register(callback): 用来注册一个监听器
• dispatch(action): 用来分发一个action

register暂且不表，接下来我们先了解dispatch中需要分发的action及其作用。

action

action虽然代表着一个动作，但其本身是一个普通的JS对象，说是带有动作指令的纯数据更为合适。

一个action对象可以有一些字段去描述其信息，不过最关键的字段是type，用来描述这个action对象的类型，通常是string类型。

我们通常分为两个文件去定义aciton，一个文件定义action对象的类型，一个文件定义能够产生并派发aciton对象的函数，这个文件就是常说的action creator。当该文件内的creator被调用时，就能创造出对象的action对象并通过dispatcher派发出去。那么action对象被派发到哪了呢？这就是store的工作了。

store

store中负责保存数据并定义修改数据的逻辑，同时调用全局唯一的dispatcher的register方法将自己注册为一个监听器。这个注册方法会返回一个token用来标识这次dispatch，同时接受一个回调函数。

这里就是整个Flux架构最核心的部分了。当通过register把回调函数注册到dispatcher上之后，所有派发出的action对象都会传递到回调函数中。回调函数内部逻辑要做的，就是根据action来决定如何更新store中的数据。

这里就存在一个问题了，既然action对象会被派发给所有store中注册的回调函数，那么该以什么顺序调用呢？这个顺序是无法预期的。这里就要靠dispatcher提供的waitFor函数了。注册时返回的token就在这里派上用场，waitFor方法接受一个token组成的数组，表示直到这些token代表的回调函数执行完才执行。

需要特别说明的是store对外只暴露getter,即要更新store只能在store中的回调函数逻辑里处理，这就最大程度的保证了单向数据流的可控性。

view

当store响应aciton并更新数据后，会触发一个更新事件，此时view就可以根据store暴露出的getter去重新获取数据并调用setState方法进行重绘了。同时view中如果需要改变store状态，不能直接去改变store，必须派发acition重走上述流程。

Flux的优势

通过上述流程也可以看出，不同于MVC混乱的数据流动，其精髓就在于受限的单向数据流动。store只有get方法，如果view想要修改store的状态的话只能派发action到dispatcher。这看起来像是一个限制，倒不如说是便于管理的约束。

Flux的不足

• store之间存在依赖关系

之前我们也提到过，每个action都会被派发给所有store中注册的回调函数 ，而要保证回调有序触发则必须通过waitFor函数告知。换句话说不同store间为了确保运行顺序必须建立相互间的非业务逻辑上的依赖。

• store混合了逻辑和状态

在Flux中数据的保存和更新都封装到了store里。当我们需要动态替换store中的更新逻辑时，也就必须替换掉store中的状态了。

针对这些不足之处，Flux的改进框架Redux也就诞生了，也是目前在React中最流行的状态管理框架。我们在下一篇文章再介绍。