Flux是一种架构模式,由Facebook团队提出,它的核心理念是单向数据流动,主要由四个组件构成,分别是Action,dispatcher,store和view,flux的数据流动方向如图:
为了响应用户的交互,view层还可能触发Action:
Action是一个动作的抽象,封装了动作类型和动作所产生的数据。Action可能由应用本身触发,比如在Ajax回调里面触发Action,还可以由用户的交互触发,比如在事件回调里面触发。Action中所封装的数据用于更新store中的数据。
Dispatcher充当Action和Store之间的桥梁,如果产生了一个Action,Action模块会调用Dispatcher所提供的接口把Action传递给dispatcher,dispatcher再把Action传给store。那dispatcher是怎么知道应该把Action传给哪个store的呢?dispatcher有一个注册接口,store可以调用这个注册接口来注册一个回调函数。自此以后,每当dispatcher接收到一个Action,它就会调用这个注册的回调函数,并且把接收到的Action作为参数,这样,Action就传递到了Store。
Store是数据模型,不同的view可能共享同一个Store中所存储的数据,并且store也可能封装了业务逻辑。Store中所封装的数据不会再提供公共的setter函数来更改数据,Store中数据的更改由自己完成,而且一般封装在向dispatcher注册的回调函数中。Store中的数据更改后,会广播一个事件,告诉监听该事件的View Store中的数据已经发生改变。view接收到事件后,会自己获取Store中的数据来更新自己。
View是视图层,它可以拥有自己的私有数据和公有数据,公有数据来自Store。View的另一个职责是监听用户的动作,通过注册事件监听器,在事件回调函数中根据不同的用户事件产生不同的Action。
由上图可知,在Flux中数据流向是从Action开始,经过dispatcher,流到Store并且更新Store中的数据,Store最后再通知View更新自己。
想要更多的了解Flux,请参考下面的连接: