かかってこいよ NakamuraEmi
  1. 1 かかってこいよ NakamuraEmi
  2. 2 One Last You Jen Bird
  3. 3 Libertus Chen-U
  4. 4 Hypocrite Nush
  5. 5 Flower Of Life 发热巫女
  6. 6 BREAK IN TO BREAK OUT Lyn
  7. 7 Time Bomb Veela
  8. 8 Warcry mpi
  9. 9 Last Surprise Lyn
  10. 10 Life Will Change Lyn
2017-09-23 18:22:12

认识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中最流行的状态管理框架。我们在下一篇文章再介绍。

-- EOF --

添加在分类「 前端开发 」下,并被添加 「React」 标签。