Flux介绍
一.简介
Flux与React都是出自于Facebook,Flux的核心思想是利用单向数据流和逻辑单向流来解决MVC架构中状态混乱,数据流管理混乱的问题.
二.Flux组成
Flux是由3个部分组成:Dispatcher,Store和View.
Dispatcher(分发器) 用于分发事件Store(数据仓库) 用于存储应用状态,同时响应事件并更新数据View (视图层) 订阅来自Store的数据渲染页面
Flux的核心是单向数据流,运作方式是如下图:
也就是:Action-> Dispatcher ->Store ->View
整体流程如下图:
1.创建Action,提供给Dispatcher2.在View层交互,触发事件,然后传递一个Action3.Dispatcher收到Action,要求Store进行相应的更新4.Store更新,通知到View5.View收到通知,然后渲染页面
所以呢,上面的流程可以看出,Flux数据流向是单向的,不会发生双向流动的情况,从而保证了数据流向的脉络,比较清晰.而MVC和MVVM中的数据流向是可以双向的,状态在Model和View之间,来回浮动,难以追踪和预测数据的变化.而Flux利用强制规定Store是不可以直接被修改的,从而保证了数据的纯粹和干净
三.深入Flux
1.Dispatcher
Dispatcher是Flux中的黑心概念,它是一个调度中心,管理着所有的数据流,所有的事件通过它来分发.Dispatcher处理Action(动作)的分发,维护Store之间的依赖关系.负责处理View和Store之间建立Action的传递.
Dispatcher用于将Action分发给Store注册的回调函数.其中有个dispatch()函数,用于分发payload的函数
2.Action
可以看做是一个交互的动作,改变应用状态或View的更新,都需要通过触发Action来实现.Action执行的结果就是调用了Dispatcher来处理相应的事情.
实际上Action是一个对象,用来描述 一个行为,里面包含了相关的信息.Action对象包含2个部分:
- type (类型) 一般是字符串常量,用来标记这个动作
- payload (载荷) 一般是动作的数据
export function changMsg(payload) {
return {
type: "HOME",
payload
}
}
3.Store
Store包含应用状态和逻辑,不同的Store管理不同的应用状态.Store负责保存数据和定义修改数据的逻辑.同时调用Dispatcher的register()方法.将自己设为监听器,每当发起一个动作(Action),去触发Dispatcher,Store的监听器就会被调用用于执行是否更新数据的操作.若更新,那么View中的状态也会获取最新状态并更新.
Store在Flux中的特性是:管理所有的应用数据,只对外暴露getter方法.用于获取Store的数据.而没有暴露setter方法,说明不能通过Store修改数据,如果要修改,必须通过Action动作去触发Dispatcher实现.
只要Store发生变更,它就会使用emit()方法通知View更新并展示新的状态数据
4.小结
上面是关于Flux的流程.总结下:
当用户在View上发起一个交互动作Action时,Dispatch会派发Action(包含Action类型和数据的对象),然后Store对Action进行响应,如果数据改变,Store就会通知View界面进行重绘, 在一个应用中,Dispatcher注册了各种不同的Action,用来满足我们的功能需求
四.Flux缺点
Fulx的缺点主要体现在增加了很大的冗余代码,很多时候,会带入大量的概念和文件,单元测试难以进行,在Flux中,组件依赖Store等其他依赖,使单元测试变得非常复杂
虽然Flux缺陷比较明显,但是我们可以看到它其中蕴含的思想.比MVC更加清晰的数据流和可预测的状态.Flux的核心思想是单向数据流,然后加之中心化控制的特点,让数据的改变源头可控,Flux的Action提高了系统抽象的程度,对于用户来说,仅仅就是一个动作而已
五,衍生的思想
虽然Flux的写法让应用产生了很多冗余代码,但是,我们了解到了它的思想.目前市面上,由Flux衍生的状态管理机制比较火的是Mobx和Redux,最出名的就是Redux,但是他们的思想都是来源于Flux.