ReFlux细说

Flux作为一种应用架构&＃xff08;application architecture&＃xff09;或是设计模式&＃xff08;pattern&＃xff09;&＃xff0c;阐述的是单向数据流&＃xff08;a unidirectional data flow&＃xff09;的思想&＃xff0c;并不是一个框架&＃xff08;framework&＃xff09;或者库&＃xff08;library&＃xff09;。

前言

在细说Flux之前&＃xff0c;还是得提一下React &＃xff0c;毕竟Flux这个名字&＃xff0c;是因为它才逐渐进入到大众视野。

React是facebook提出来的一个库&＃xff0c;用来构建用户界面&＃xff08;User Interface&＃xff09;&＃xff0c;它的三大特点&＃xff08;来自官方&＃xff09;&＃xff1a;

1. JUST THE UI&＃xff1a; 仅仅是一个View&＃xff08;components&＃xff09;&＃xff0c;可以认为是MVC中V&＃xff0c;用来构建UI界面。
2. VIRTUAL DOM &＃xff1a; 虚拟dom&＃xff0c;为的是&＃xff1a;高性能dom渲染&＃xff08;利用diff算法&＃xff09;、组件化&＃xff08;向web components看齐&＃xff09;、多端同构&＃xff08;node&＃xff0c;react native&＃xff09;。
3. DATA FLOW&＃xff1a; 单向数据流&＃xff08;one-way data flow&＃xff09;&＃xff0c;指的是&＃xff1a;一种自上而下的渲染方式&＃xff08;top-down rendering&＃xff09;。

总而言之&＃xff0c;对于一个react web应用&＃xff0c;它的UI将会由无数个组件&＃xff08;react component&＃xff09;嵌套组合而成&＃xff0c;它们之间存在着层级&＃xff08;hierarchy&＃xff09;关系&＃xff08;通过JSX的语法糖可以轻易看出&＃xff09;&＃xff0c;也就因此有了父组件&＃xff0c;子组件和顶层组件的概念。

然而就像上述第一点所说&＃xff0c;React仅仅是一个View&＃xff0c;对于一个web应用&＃xff0c;没有数据就显得毫无意义。

现在&＃xff0c;假使我们通过一个WebAPI模块取得了数据&＃xff0c;那么如何传递给React 组件&＃xff08;components&＃xff09;&＃xff0c;从而实现UI渲染呢&＃xff1f;结合组件的层级关系&＃xff0c;想到上述所说的第三点&＃xff1a;自上而下的渲染&＃xff0c;我们将数据传递给顶层组件(controller-view)&＃xff0c;同样作为父组件的它&＃xff0c;便可以通过组件的属性&＃xff08;properties&＃xff09;将一些有用数据传递给它的各个子组件&＃xff08;各取所需数据&＃xff09;&＃xff0c;就这样一级一级自上而下地传递下去&＃xff08;直到每一个叶子组件&＃xff09;&＃xff0c;最终&＃xff0c;每一个组件都将得到自己渲染所需要的数据&＃xff0c;从而完成UI的渲染。

那么&＃xff0c;倘若此时数据变化了&＃xff08;比如&＃xff1a;对于一个列表而言&＃xff0c;用户点击删除按钮&＃xff0c;删除了一条数据&＃xff09;&＃xff0c;我们又该如何通知各个组件进行UI更新呢&＃xff1f;

有这样一种清晰的思路&＃xff1a;

• 首先&＃xff0c;我们应该需要一个数据存储&＃xff08;Store&＃xff09;&＃xff0c;存储着react web应用当前的状态&＃xff08;State&＃xff09;&＃xff0c;就像MVC中的Model一样。
• 然后&＃xff0c;当用户点击删除按钮时&＃xff0c;将会触发一个消息&＃xff08;Action&＃xff09;&＃xff0c;告诉Store数据变化了&＃xff0c;以及哪里变化了&＃xff08;payload&＃xff09;。
• 最后&＃xff0c;Store修改了数据之后&＃xff0c;再将新的数据传递给最顶层组件&＃xff0c;重新完成一次自上而下的渲染&＃xff08;re-render&＃xff09;&＃xff0c;从而更新了UI&＃xff08;不要过分担心性能问题&＃xff0c;VIRTUAL DOM就是用来解决这个的&＃xff09;。

显然上述的几步&＃xff0c;React作为一个View是不可能做到的&＃xff0c;也正因为这样&＃xff0c;Flux作为一种架构方案才被提出来&＃xff0c;它的思想大体就是上述这几步&＃xff0c;通过一个单向数据的流动&＃xff0c;完成了UI的更新&＃xff0c;用一张图可以表示&＃xff0c;如下&＃xff08;以Facebook Flux为例&＃xff09;&＃xff1a;

当然&＃xff0c;作为应用数据处理的模式&＃xff0c;除了Flux&＃xff0c;还有很多&＃xff08;如&＃xff1a;传统的MVC&＃xff0c;MVVM&＃xff09;&＃xff0c;只是Flux凭借其单向数据流特点&＃xff0c;使得数据流变得简单&＃xff0c;易于调试和追踪问题&＃xff0c;所以更适合与React进行组合使用。

前面&＃xff0c;我们就一直在说&＃xff0c;Flux是一种架构&＃xff0c;一种模式&＃xff0c;并不是一个框架&＃xff0c;也不是一个库&＃xff0c;就像我们说MVC&＃xff08;VM&＃xff09;的概念一样&＃xff0c;所以&＃xff0c;遵循着Flux模式所阐述的思想自然就会出现一些库&＃xff0c;如&＃xff1a;Facebook Flux、Reflux、Fluxxor、Redux等等。

本文主要讲解的Reflux&＃xff0c;不过在这之前还是需要先提一下Facebook Flux&＃xff0c;从而为后面一些对比做一些铺垫。

Facebook Flux

Facebook Flux&＃xff0c;是Facebook在提出Flux架构后&＃xff0c;给出的一个对Flux的简单实现&＃xff0c;可以认为是Flux库的第一个范例&＃xff0c;所以&＃xff0c;也有人称之为Original Flux。

Facebook Flux中引入了四个概念&＃xff1a; Dispatcher、 Actions、Stores、Views&＃xff08;Controller-Views&＃xff09;&＃xff0c;而它们之间的关系就如同上面的那张图所描述的一样&＃xff0c;构成了一个单向数据流的闭环&＃xff0c;简化版如下&＃xff1a;

接下来&＃xff0c;将以官方的TodoMVC Demo为例&＃xff0c;来说明它们各自的作用&＃xff0c;以及它们之间是如何配合工作的&＃xff1f;&＃xff08;PS&＃xff1a;建议读者将源代码clone下来&＃xff0c;边看边调试&＃xff09;

Views and Controller-Views

Facebook Flux中所指的Views&＃xff0c;其实就是React Components&＃xff0c;用作UI渲染&＃xff0c;而相对特别的&＃xff0c;Controller-Views指的则是顶层React Component&＃xff0c;除了UI渲染外&＃xff0c;它还负责接收来自Store变化的数据&＃xff0c;并传递给它的Child Component&＃xff08;即Controller-View -> Child Views&＃xff09;&＃xff0c;用于子View的渲染。

在这个例子中&＃xff0c;TodoApp就是一个Controller-View&＃xff0c;它监听到TodoStore的数据变化后&＃xff0c;便会重新从TodoStore中获取数据&＃xff0c;然后通过调用组件setState()方法&＃xff0c;触发render()方法的执行&＃xff0c;从而得到UI的更新&＃xff08;自上而下的渲染&＃xff09;。

// 从TodoStore中获取数据
function getTodoState() {return {allTodos: TodoStore.getAll(),areAllComplete: TodoStore.areAllComplete()};
}var TodoApp &＃61; React.createClass({componentDidMount: function() {// TodoApp监听TodoStore的数据变化TodoStore.addChangeListener(this._onChange);},render: function() {return (

Stores

Facebook Flux中的Stores&＃xff0c;作为数据存储的模块&＃xff0c;类似于MVC中的Model&＃xff0c;它负责接收Dispatcher分发过来的actions&＃xff0c;针对不同的actionType&＃xff0c;对数据就进行不同的操作&＃xff08;如&＃xff1a;增删改查&＃xff09;&＃xff0c;最后再通知View&＃xff0c;数据变化了&＃xff0c;需要进行UI更新。

在这个例子中&＃xff0c;TodoStore通过变量_todos变量存储着整个应用的数据&＃xff08;一个列表&＃xff09;&＃xff0c;并通过AppDispatcher&＃xff08;Dispatcher实例&＃xff09;注册回调&＃xff0c;来接收不同类型的Action指令&＃xff0c;进而执行不同的数据操作&＃xff08;mutate data&＃xff09;&＃xff0c;最后通知TodoApp View数据改变&＃xff0c;需要更新UI&＃xff08;re-render&＃xff09;。

// 数据存储&＃xff08;一个列表&＃xff09;
var _todos &＃61; {};// 操作数据的函数
function create(text) {/*此处代码省去*/}
function update(id, updates) {/*此处代码省去*/}
function destroy(id) {delete _todos[id];
}// 接收分发过来的Action
AppDispatcher.register(function(action) {var text;// 判断Action类型&＃xff0c;采取不同的数据操作switch(action.actionType) {// 新增case TodoConstants.TODO_CREATE:text &＃61; action.text.trim();if (text !&＃61;&＃61; &＃39;&＃39;) {create(text); // 创建数据&＃xff0c;并存储TodoStore.emitChange(); // 通知TodoApp数据变化&＃xff0c;需要更新UI}break;// 更新case TodoConstants.TODO_UPDATE_TEXT:/*此处代码省去*/break;// 删除case TodoConstants.TODO_DESTROY:/*此处代码省去*/break;/*此处省去部分代码*/}
});


Dispatcher

Facebook Flux中&＃xff0c;Dispatcher起到了一个中央枢纽&＃xff08;Central Hub&＃xff09;的角色&＃xff0c;它存储着一张Stores列表清单&＃xff0c;并且负责Actions的分发工作&＃xff0c;即Action的一旦触发&＃xff0c;Dispatcher将会通知列表清单上的所有的Stores&＃xff0c;每一个Store则选择性地针对该Action进行特定处理&＃xff08;或者不处理&＃xff09;。

在一个应用中&＃xff0c;Dispatcher实例只允许有一个&＃xff08;Single&＃xff09;&＃xff0c;也就是说它将作为一个单例而存在。

在这个例子中&＃xff0c;AppDispatcher就是这样一个单例&＃xff0c;我们在TodoStores通过AppDispatcher.register()注册回调&＃xff08;见上段代码&＃xff09;&＃xff0c;来接收不同类型的Actions&＃xff08;消息订阅&＃xff09;&＃xff0c;在TodoActions里通过AppDispatcher.dispatch()执行不同Actions的分发&＃xff08;消息发布&＃xff09;&＃xff0c;如下&＃xff1a;

var TodoActions &＃61; {// 新增Actioncreate: function(text) {AppDispatcher.dispatch({ // 通知TodoStore对数据进行修改&＃xff08;带有Action类型和关联数据&＃xff09;actionType: TodoConstants.TODO_CREATE, // Action类型&＃xff1a;createtext: text // 传递给TodoStore的数据});},// 更新ActionupdateText: function(id, text) {AppDispatcher.dispatch({actionType: TodoConstants.TODO_UPDATE_TEXT, // Action类型&＃xff1a;updateid: id,text: text});},// 删除Actiondestroy: function(id) {AppDispatcher.dispatch({actionType: TodoConstants.TODO_DESTROY, // Action类型&＃xff1a;destroyid: id});}/*此处省去部分代码*/
};

Actions

Facebook Flux中的有一个概念叫做Action Creator&＃xff0c;可以将它理解为一个方法&＃xff08;即helper method&＃xff09;&＃xff0c;专门用来创建某种类型的Action。

上一段代码中&＃xff0c;TodoActions模块就提供了这些helper methods&＃xff08;或者叫做Action Creators&＃xff09;&＃xff0c;如&＃xff1a;

• TodoActions.create(text)
• TodoActions.updateText(id, text)
• TodoActions.destroy(id)
• ...

上述每一个方法在内部&＃xff0c;都定义了自己的常量类型&＃xff08;actionType&＃xff09;&＃xff0c;并且将接收的参数作为数据&＃xff08;payload&＃xff09;&＃xff0c;从而封装成一个完整的Action&＃xff08;即actionType &＃43; payload &＃61; Action&＃xff09;。

最后&＃xff0c;再统一通过调用Dispatcher.dispatch()将特定的Action以消息的形式分发出去&＃xff08;即传递给Stores&＃xff09;&＃xff0c;Stores在得到Action后&＃xff0c;便可以通过Action.actionType来判定采取某种操作&＃xff08;或者忽略这个Action&＃xff09;&＃xff0c;而执行操作时需要用到的数据则来自Action.payload。

思考

Facebook Flux中提出的这四个概念&＃xff0c;承担着各自角色&＃xff0c;通过互相协作&＃xff0c;形成了一个单向数据流的闭环。
------【推荐大家看下这篇文章《A cartoon guide to Flux》&＃xff0c;生动形象地描述了这几个角色。】

说完了Facebook Flux&＃xff0c;让我们静静思考一下&＃xff0c;存在的不足&＃xff1a;

倘若&＃xff0c;有一个单页面应用&＃xff0c;程序中就可能存在N个store&＃xff0c;每个store都会监听1~N个action&＃xff0c;代码就会像这样&＃xff1a;

// storeA.js
Dispatcher.register(function (action) {switch(action.actionType) {case &＃39;actionA&＃39;: break;case &＃39;actionB&＃39;: break;/* ... 1~N个action */case &＃39;actionN&＃39;: break;}
});// storeB.js
Dispatcher.register(function () {// 同上
});/* ... */
/* ... 1~N个store */
/* ... */// storeN.js
Dispatcher.register(function () {// 同上
});

假使此时&＃xff0c;触发了一个actionX&＃xff0c;那么storeA~storeB的通过Dispatcher.register()注册的回调函数会按注册顺序依次被触发(无一例外)&＃xff0c;也就是说每个store都会得到actionX通知&＃xff0c;唯一不同的可能就是&＃xff1a;每个store模块&＃xff0c;会通过各自的switch语句进行判断&＃xff0c;有的对actionX做处理&＃xff0c;有的则不处理&＃xff08;忽略&＃xff09;&＃xff0c;那么问题来了&＃xff1a;

『既然有些store对actionX不需要处理&＃xff0c;那么它们注册的回调执行是否有必要&＃xff1f;毕竟是函数执行是有开销的&＃xff0c;如果有1000个store对actionX不"感冒"的的话&＃xff0c;会不会很浪费资源&＃xff1f;』

分析下这个问题&＃xff1a;Facebook Flux是以Dispatcher&＃xff08;发布者&＃xff09;作为消息中枢&＃xff0c;所有的Action消息都会统一从这里分发出去&＃xff0c;广播给所有的Store&＃xff08;订阅者&＃xff09;&＃xff0c;也就是说&＃xff1a;发布者&＃xff08;Dispatcher&＃xff09;和订阅者&＃xff08;Stores&＃xff09;之间存在着一对多的关系&＃xff0c;而事实上Actions&＃xff08;消息&＃xff09;和Stores&＃xff08;订阅者&＃xff09;之间却存在着一个多对多的关系&＃xff0c;如下图&＃xff1a;

这样的矛盾&＃xff0c;就使得&＃xff0c;每一个Store不得不在自己的回调函数里通过Switch语句&＃xff0c;来判断当前Action的类型&＃xff0c;来决定要不要进行处理&＃xff0c;那么暂且抛开性能不说&＃xff0c;显然&＃xff0c;这样写法&＃xff0c;却显得繁重且不够优雅。

于是&＃xff0c;接下来&＃xff0c;看看Reflux在Facebook Flux的基础之上&＃xff0c;做了那些优化&＃xff1f;

Reflux

Reflux&＃xff0c;是另一个实现Flux模式的库&＃xff0c;旨在使整个应用架构变得更加简单。

准确地说&＃xff0c;Reflux是由Facebook Flux演变而来&＃xff08;inspired by Facebook Flux&＃xff09;&＃xff0c;可以说是它的一个进化版本&＃xff0c;自然而言就会拿两者进行比较&＃xff1a;详见这里。

简要概括一下重点&＃xff0c;就是&＃xff1a;

1.Reflux保留了Facebook Flux中原有的三个概念&＃xff1a;Actions、Stores、Views&＃xff08;Controller-Views&＃xff09;&＃xff0c;去除了Dispatcher&＃xff0c;如果要用一张图表示的话&＃xff0c;就是这样&＃xff1a;

此时会有人问&＃xff1a;没有了消息中枢&＃xff08;Dispatcher&＃xff09;&＃xff0c;消息Actions如何发布出去&＃xff0c;并传递到Stores呢&＃xff1f;

答&＃xff1a;在Reflux中&＃xff0c;每一个Action本身就是一个Publisher&＃xff08;消息发布者&＃xff09;&＃xff0c;即自带了消息发布功能&＃xff1b;而每一个Store除了作为数据存储之外&＃xff0c;它还是一个Subscriber&＃xff0c;或者叫做Listener&＃xff08;消息订阅者&＃xff09;&＃xff0c;自然就可以通过监听Action&＃xff0c;来获取到变化的数据。

2.Store之间可以互相监听

这样的场景还是有的&＃xff0c;比如&＃xff1a;在单页面应用中&＃xff0c;如果不同Page拥有不同的Store&＃xff0c;那么就可能会出现&＃xff1a;子页面Store数据变化后&＃xff0c;需要通知到父页面Store进行相应修改的情况。

回顾上一节中&＃xff0c;对于Facebook Flux的思考&＃xff0c;所遗留的问题点&＃xff0c;在Reflux中是否解决了呢&＃xff1f;

答案是&＃xff1a;肯定的。

这里先简单说明下&＃xff1a;

前面讲到Actions和Stores&＃xff08;消息订阅者&＃xff09;间本身就存在着多对多的关系&＃xff0c;而作为Publisher&＃xff08;消息发布者&＃xff09;&＃xff0c;

• 在Facebook Flux中只有一个&＃xff0c;即Dispatcher&＃xff0c;所以&＃xff0c;不得不在消息发布时&＃xff0c;通过在payload中添加actionType字段来区分消息类型&＃xff0c;且Store也因此不得不在回调函数中用Switch语句进行判断actionType处理。

• 而在Reflux中&＃xff0c;由于每一个Action都是一个Publisher&＃xff0c;且具有特定的含义&＃xff08;actionType&＃xff09;&＃xff0c;即多个Publisher对应于多个Subscriber&＃xff08;或叫做Listener&＃xff09;&＃xff0c;Store便可以有目的性地选择订阅想监听的Action&＃xff0c;而不是监听所有的Action&＃xff0c;再通过Switch语句进行筛选&＃xff1b;另外&＃xff0c;Action&＃xff08;消息&＃xff09;的发布&＃xff0c;也只会通知给之前有订阅过的Store&＃xff0c;而不是所有Store&＃xff0c;所以并不会造成任何资源浪费。

归结一点&＃xff0c;就是Reflux将Dispatcher的功能合并到Action中去&＃xff0c;使得每一个Action都具有了消息发布的功能&＃xff0c;可以直接被Store所监听&＃xff08;即listenable&＃xff09;。

本质

无论是从具体的用法&＃xff0c;还是从源码的架构来看&＃xff0c;Reflux本质上可以理解为一个PubSub库。

可以用一张具体的图来表现这一说法&＃xff0c;如下&＃xff1a;

从图中可以看出&＃xff0c;Actions、Stores和Views在Reflux中分别承担着消息发布订阅模式中的一个或多个角色&＃xff0c;即&＃xff1a;发布者&＃xff08;Publisher&＃xff09;或者 订阅者&＃xff08;Subscriber/Listener&＃xff09;&＃xff0c;也正是基于这样的角色扮演&＃xff0c;才使得它能够实现作为Flux所应该具有的单向数据流特性&＃xff08;图中红线部分&＃xff09;。

总结一下&＃xff1a;

1. Reflux单向数据流的实现&＃xff0c;是完全基于PubSub设计模式的。
2. Action&＃xff0c;Store和View三者的角色分配以及分工合作&＃xff0c;如下&＃xff1a;
   • Action 是一个Publisher&＃xff0c;负责消息的分发&＃xff0c;一般是由用户行为&＃xff08;User Interaction&＃xff09;&＃xff0c;或是Web API触发。
   • Store 不仅是一个Publisher&＃xff0c;还是一个Subscriber&＃xff08;或者叫做Listener&＃xff09;&＃xff0c;作为Subscriber&＃xff0c;负责监听Action的触发&＃xff1b;作为Publisher&＃xff0c;则负责通知View更新UI。
   • View 是一个Subscriber&＃xff0c;负责监听Store的数据变化&＃xff0c;做到及时更新UI。

既然Reflux中的对象不是Publisher就是Subscriber/Listener&＃xff0c;那么代码是如何组织的呢&＃xff1f;

答&＃xff1a;Reflux抽取出两个模块&＃xff1a;PublisherMethods 和 ListenerMethods&＃xff0c;顾名思义&＃xff0c;这两个集合分别存储着一个对象作为Publisher和Listener所应该具有的方法。

比如&＃xff1a;

PublisherMethods中包括&＃xff1a;trigger、triggerAsync等消息发布方法。

ListenerMethods中就包括listenTo、listenToMany等消息订阅方法。

具体的细节&＃xff0c;感兴趣的同学可以看一下源码&＃xff0c;以及这篇文章《The Reflux data flow model》详细介绍了Reflux与PubSub的关系。

详解

这一节的主要目的是&＃xff1a;通过代码示例和应用场景&＃xff0c;尽可能地讲解Reflux每个API的全貌&＃xff0c;以及将代码如何写得更简洁优雅&＃xff1f;

Action

在Reflux中&＃xff0c;因为没有了Action Creator的概念&＃xff0c;所以&＃xff0c;Action的创建都是通过统一的API&＃xff1a;Reflux.createAction()或者Reflux.createActions()来实现。

1.通过Reflux.createAction()创建单个Action&＃xff0c;代码如下&＃xff1a;

// 拥有配置
var action &＃61; Reflux.createAction({actionName: &＃39;addItem&＃39;, // 其实这个actionName并没有什么用&＃xff0c;可不传asyncResult: true,sync: false,children: [&＃39;success&＃39;]
});// 简化
var action &＃61; Reflux.createAction(&＃39;addItem&＃39;)// 或者匿名
var addItemAction &＃61; Reflux.createAction();

注意&＃xff1a;Reflux.createAction()的返回值是一个特殊的对象 --- 函数&＃xff08;functor&＃xff09;&＃xff0c;这样的设计其实是为了方便Action的触发&＃xff0c;显得更加函数化编程(FRP) &＃xff0c;就像下面这样使用&＃xff1a;

addItemAction({a: 1});
action(&＃39;hello world&＃39;, &＃39;Lovesueee&＃39;);

action创建的时候&＃xff0c;可以进行参数的配置&＃xff0c;具体的参数意义如下&＃xff1a;

• sync&＃xff1a; 设置为true&＃xff0c;指定action的默认触发方式为同步
• children&＃xff1a; 用于创建子Action&＃xff08;主要是用在异步操作的时候&＃xff0c;后面会讲到&＃xff09;
• asyncResult&＃xff1a;设置为true时&＃xff0c;自动创建两个名为&＃39;completed&＃39;和&＃39;failed&＃39;的子Action&＃xff08;可以认为是设置子Action的一个快捷方式&＃xff09;

2.通过Reflux.createActions()创建多个Action&＃xff0c;即Actions集合&＃xff0c;代码如下&＃xff1a;

var actions &＃61; Reflux.createActions([&＃39;addItem&＃39;, &＃39;deleteItem&＃39;]);// 个别action配置
var actions &＃61; Reflux.createActions([&＃39;addItem&＃39;, {deleteItem: {asyncResult: true,children: [&＃39;success&＃39;],},updateItem: {...}
}]);// 也可以这样
var actions &＃61; Reflux.createActions({addItem: {},deleteItem: {asyncResult: true,children: [&＃39;success&＃39;]},updateItem: {...}
});

注意&＃xff1a;Reflux.createActions()返回的是一个普通的对象&＃xff0c;即Actions集合&＃xff0c;所以Action触发时&＃xff0c;需要指定actionName&＃xff0c;就像这样&＃xff1a;

actions.addItem({...});
actions.deleteItem();

一般说来&＃xff0c;在实际项目代码中&＃xff0c;由于涉及到的Action较多&＃xff0c;所以一般都是调用Reflux.createActions()一次性创建Actions集合&＃xff0c;比较方便。另外&＃xff0c;之后Store通过listenables字段与Action进行关联时&＃xff0c;需要的也是一个Actions集合。

之前就提到&＃xff0c;Action作为一个Publisher&＃xff0c;会拥有PublisherMethods集合里提供的一系列方法&＃xff0c;这里统一举例说明&＃xff1a;

• listen&＃xff1a;Action消息订阅

var addAction &＃61; Reflux.createAction();addAction.listen(function (url) {// 默认上下文this是addAction$.ajax(url).done(function () {// todo: save to store});
});addAction(&＃39;/xxx/add&＃39;);

• trigger 同步触发Action消息&＃xff0c;在触发具体的消息之前&＃xff0c;首先会先执行preEmit和shouldEmit回调。

  • preEmit返回值(非undefined)将作为shouldEmit函数的入参&＃xff0c;用于修改payload
  • shouldEmit的返回值(true or false)&＃xff0c;将作为是否真正触发消息的标志

举几个例子说明下&＃xff0c;preEmit和shouldEmit的使用&＃xff0c;如下&＃xff1a;

preEmit用于异步请求&＃xff0c;下面两种方法是等价的&＃xff1a;

var actions &＃61; Reflux.createActions({add: {asyncResult: true,preEmit: function (url) {$.ajax(url).done(this.completed).fail(this.failed);}}
});// 等价于var actions &＃61; Reflux.createActions({add: {asyncResult: true}
});actions.add.listen(function(url) {$.ajax(url).done(this.completed).fail(this.failed)
});


preEmit用于修改payload

var actions &＃61; Reflux.createActions([&＃39;takePhoto&＃39;]);// 映射
var maps &＃61; {&＃39;photo&＃39;: {maxSize: 1000 // 从相册获取},&＃39;camera&＃39;: { // 拍照maxSize: 2000,maxSelect: 10}
};actions.takePhoto.preEmit &＃61; function (type) {return maps[type] || maps[&＃39;photo&＃39;];
};actions.takePhoto.listen(function (options) {// do ajaxconsole.log(options);
});actions.takePhoto(&＃39;photo&＃39;);
// 或者
// actions.takePhoto(&＃39;camera&＃39;);

shouldEmit的使用&＃xff08;防止action的频繁触发&＃xff09;

var requesting &＃61; false;
var actions &＃61; Reflux.createActions([&＃39;submit&＃39;]);actions.submit.shouldEmit &＃61; function () {return !requesting;
}actions.submit.listen(function (url) {requesting &＃61; true;$.ajax(url).done(function () {// success}).fail(function () {// error}).always(function () {requesting &＃61; false;});
});// 点击按钮
$(&＃39;#btn&＃39;).click(function () {actions.submit(&＃39;url/submit&＃39;);
});

• promise: 语法糖&＃xff0c;用于简写异步Action&＃xff0c;下面两种方法是等价的&＃xff1a;

var addAction &＃61; Reflux.createAction({children: [&＃39;completed&＃39;, &＃39;failed&＃39;] // 等价于 asyncResult: true
});addAction.listen(function (url) {var me &＃61; this;$.ajax(url).done(function (data) {me.completed(data);}).fail(function () {me.failed();});
});// 等价于
addAction.listen(function (url) {this.promise($.ajax(url));
});addAction(&＃39;/url/add&＃39;);

• listenAndPromise: 是上述两个方法listen和promise方法的结合&＃xff0c;做了两件事情&＃xff1a;消息订阅和异步回调。

比如上面的例子&＃xff0c;就可以这样简写&＃xff1a;

addAction.listenAndPromise(function(url) {return $.ajax(url); // 注意&＃xff1a;返回promise对象
});

• triggerAsync: 异步触发Action消息&＃xff08;而trigger同步触发消息&＃xff09;&＃xff0c;类似于setTimeout(function () {action();}, 0)。

• triggerPromise 触发Action消息&＃xff0c;可以通过返回的promise将异步请求的数据直接带回&＃xff0c;而不需要经过Store。

改写上面的例子&＃xff0c;如下&＃xff1a;

var addAction &＃61; Reflux.createAction({asyncResult: true
});addAction.listenAndPromise(function(url) {return $.ajax(url); // 注意&＃xff1a;返回promise对象
});// 触发消息&＃xff0c;监听异步子action的成功与失败
// action这里可以获取到数据&＃xff0c;
addAction.triggerPromise(&＃39;/url/add&＃39;).then(function (data) {console.log(data);
}, function () {console.log(&＃39;failed&＃39;);
});


最后再说说&＃xff0c;子Action的概念&＃xff0c;其实之前都用到了&＃xff0c;主要是用于异步请求&＃xff0c;成功和失败回调的执行&＃xff0c;这里简单说明一下&＃xff1a;

在利用Reflux.createAction创建Action之初&＃xff0c;可以通过下面的两种方式创建子Action:

var addAction &＃61; Reflux.createAction({asyncResult: true
});// 等价于var addAction &＃61; Reflux.createAction({children: [&＃39;completed&＃39;, &＃39;failed&＃39;]
});


在创建之后这两个子Action在数据存储结构中&＃xff0c;便可以直接通过addAction.completed和addAction.failed访问。

Store

Store作为数据存储中心&＃xff0c;且因为介于Actions和Views之间&＃xff0c;所以同时承担着Publisher&＃xff08;消息发布者&＃xff09;和Subscriber&＃xff08;消息订阅者&＃xff09;两种角色。

Reflux中&＃xff0c;Store的创建同样是通过提供的API&＃xff1a;Reflux.createStore()&＃xff0c;就像下面这样&＃xff1a;

var action &＃61; Reflux.createAction();var store &＃61; Reflux.createStore({init: function () {// 存储数据this.data &＃61; {};// Action监听this.listenTo(action, this._onAction);// 或者// this.listenTo(action, &＃39;_onAction&＃39;);// 或者// action.listen(this._onAction);},_onAction: function (msg) {console.log(msg);}
});action(&＃39;hello world&＃39;); // 触发动作

不同于Action&＃xff0c;Store返回的是一个普通的对象&＃xff0c;通常我们会在init方法中进行数据的存储 和Action的监听。

在创建Store时&＃xff0c;我们可以通过传递一个特殊的字段mixins&＃xff0c;它的功能就有点类似于React Component中的mixins。

在mixin中&＃xff0c;对于几个特殊方法&＃xff1a;init, preEmit, shouldEmit会进行特殊处理&＃xff08;组合&＃xff09;&＃xff0c;保证mixins里面的方法都会被执行而&＃xff0c;对于其他自定义方法&＃xff0c;有一定的覆盖规则&＃xff0c;比如&＃xff0c;下面的例子中myMethod方法的覆盖优先级就是&＃xff1a;store > mixin3 > mixin2 > mixin。

var mixin &＃61; {init: function () {console.log(&＃39;mixin:init&＃39;)},myMethod: function () {console.log(&＃39;mixin.myMethod&＃39;);}
};var mixin2 &＃61; {init: function () {console.log(&＃39;mixin2:init&＃39;)},myMethod: function () {console.log(&＃39;mixin2.myMethod&＃39;);}
};var mixin3 &＃61; {mixins: [mixin2],init: function () {console.log(&＃39;mixin3:init&＃39;)},myMethod: function () {console.log(&＃39;mixin3.myMethod&＃39;);},otherMethod: function () {console.log(&＃39;mixin3.otherMethod&＃39;);}
};var store &＃61; Reflux.createStore({mixins: [mixin, mixin3],init: function () {console.log(&＃39;store:init&＃39;);},myMethod: function () {console.log(&＃39;store:myMethod&＃39;);}
});store.myMethod();// mixin:init
// mixin2:init
// mixin3:init
// store:init
// store:myMethod

再从PubSub的角度说说Store&＃xff1a;

作为消息的发布者&＃xff0c;拥有着和Action一样的能力&＃xff0c;即拥有PublisherMethods集合的所有方法&＃xff1b;同时作为消息的订阅者&＃xff0c;用来监听Action的触发&＃xff08;或其他Store的改变&＃xff09;&＃xff0c;从而改变自身数据&＃xff0c;Store还拥有ListenerMehthods集合提供的方法。

这里重点说一下&＃xff0c;Store作为消息订阅者这个角色&＃xff0c;拥有的几个比较重要的方法&＃xff1a;

• listenTo: 监听指定的listenable的变化&＃xff0c;从而执行回调&＃xff08;这里的listenable可以是Action&＃xff0c;也可以是Store&＃xff09;
  (注意&＃xff1a;reflux中&＃xff0c;Store之间是可以监听的&＃xff0c;但是不可以互相监听哦&＃xff0c;避免死循环&＃xff08;circular loop&＃xff09;)

举例几个例子&＃xff0c;说明&＃xff1a;

Store监听Action

var addAction &＃61; Reflux.createAction(&＃39;add&＃39;);var store &＃61; Reflux.createStore({init: function () {this.data &＃61; {flag: false};},getInitialState: function () {return this.data;}
});store.listenTo(addAction, function (flag) {this.data.flag &＃61; flag;
});addAction(true);

Store监听其他Store&＃xff08;设置listenTo第三个回调&＃xff0c;通过调用被监听Store的getInitialState方法获取其初始值&＃xff09;

var storeA &＃61; Reflux.createStore({init: function () {this.data &＃61; {a: 1};},getInitialState: function () {return this.data;}
});var storeB &＃61; Reflux.createStore({init: function () {this.data &＃61; {b: 2};}
});storeB.listenTo(storeA, function (a) {this.data.a &＃61; a;
}, function (data) {// storeB获取storeA的初始值this.data.a &＃61; data.a;
});console.log(storeB); // storeB.data &＃61;> {a: 1, b: 2}storeA.trigger(3);console.log(storeB); // storeB.data &＃61;> {a: 3, b: 2}

• listenToMany: 监听指定的listenables&＃xff08;对象集合&＃xff09;变化&＃xff0c;从而执行对应的回调&＃xff08;这里的listenables是一个对象&＃xff0c;它的每一个值可以是action&＃xff0c;也可以是store&＃xff09;

通常会这样使用&＃xff1a;

var actions &＃61; Reflux.createActions([&＃39;addItem&＃39;, &＃39;deleteItem&＃39;]);var store &＃61; Reflux.createStore({init: function () {this.items &＃61; [];this.listenToMany(actions);},onAddItem: function (item) {this.items.push(item);},onDeleteItem: function (item) {var items &＃61; this.items;items.forEach(function (val, index) {if (val &＃61;&＃61;&＃61; item) {items.splice(index, 1);// todo: break}});}
});actions.addItem(1);
actions.addItem(2);console.log(store); // store.items &＃61;> [1, 2]actions.deleteItem(1);console.log(store); // store.items &＃61;> [2]

当一个store监听listenables对象集合&＃xff08;即多个监听对象&＃xff0c;比如&＃xff1a;多个action&＃xff09;时&＃xff0c;实际上做的事情也还是单个消息订阅store.listenTo(actionName, onActionName)&＃xff0c;但是这里有一个约定&＃xff08;或者叫做映射关系&＃xff09;&＃xff0c;以上面的两个action为例:

actionName 对应的回调就是 on &＃43; actionName(驼峰写法)

然后Reflux还做了一些容错处理&＃xff0c;如果你不按照这个约定&＃xff08;即命名不规范&＃xff09;的话&＃xff0c;它会这样获取需要注册的回调&＃xff1a;

以名为addItemaction为例&＃xff0c;它的callback依次会取&＃xff1a;

this.onAddItem -> this.addItem -> undefined&＃xff08;不注册回调&＃xff09;

自然而然&＃xff0c;涉及到listenTo方法就会想起上面说的它的第三个参数defaultCallback用来初始化&＃xff0c;那么在listenToMany方法对此就有这样的约定&＃xff08;或者叫做映射关系&＃xff09;&＃xff1a;

以名为addItemaction为例&＃xff08;一般是store之间才会使用&＃xff0c;且很少使用&＃xff09;&＃xff0c;它的defaultCallback依次会取&＃xff1a;

this.onAddItemDefault -> this.addItemDefault -> undefined&＃xff08;没有初始化回调&＃xff09;

这里还需要再提起一次&＃xff0c;子Action的概念&＃xff0c;对于下面这段代码&＃xff1a;

之前会这样做&＃xff1a;

var addAction &＃61; Reflux.createAction({asyncResult: true
});var store &＃61; Reflux.createStore({init: function () {this.listenTo(addAction.completed, &＃39;onAddCompleted&＃39;);this.listenTo(addAction.failed, &＃39;onAddFailed&＃39;);},onAddCompleted: function (data) {console.log(&＃39;completed: &＃39;, data);},onAddFailed: function () {console.log(&＃39;failed&＃39;)}
});

如果用listenToMany方法来做的话&＃xff0c;就可以这样简化&＃xff1a;

var addAction &＃61; Reflux.createAction({asyncResult: true
});var store &＃61; Reflux.createStore({init: function () {this.listenToMany({add: addAction}); // 注意&＃xff1a;参数是一个对象},onAddCompleted: function (data) {console.log(&＃39;completed: &＃39;, data);},onAddFailed: function () {console.log(&＃39;failed&＃39;)}
});

也就是说&＃xff0c;listenToMany方法&＃xff0c;不但关联了action&＃xff0c;还会关联它的子action&＃xff0c;即addAction.completed和addAction.failed&＃xff0c;这里就又有一个约定&＃xff08;或者叫做映射关系&＃xff09;&＃xff1a;

即&＃xff1a;on &＃43; 主action名 &＃43; 子action名&＃xff08;驼峰&＃xff09;

然而&＃xff0c;在利用Reflux.createStore()创建之初&＃xff0c;我们可以利用更简洁的一种方式&＃xff0c;对Store和Actions进行关联。

之前是这样&＃xff1a;

var actions &＃61; Reflux.createActions([&＃39;addItem&＃39;, &＃39;deleteItem&＃39;]);var store &＃61; Reflux.createStore({init: function () {this.listenToMany(actions); // 关联actions},onAddItem: function () {// todo: add},onDeleteItem: function () {// todo: delete}
});

现在可以通过listenables字段来关联&＃xff1a;

var actions &＃61; Reflux.createActions([&＃39;addItem&＃39;, &＃39;deleteItem&＃39;]);var store &＃61; Reflux.createStore({listenables: actions // 关联actionsinit: function () {// init},onAddItem: function () {// todo: add},onDeleteItem: function () {// todo: delete}
});

这是一种快捷方式&＃xff0c;其实内部原理就是store在创建的时候&＃xff0c;调用了listenToMany方法。

注意&＃xff1a;listenables这里可以是actions组成的数组&＃xff0c;如&＃xff1a;[actions1, actions2]&＃xff0c;就相当于多调用几次listenToMany方法&＃xff0c;如&＃xff1a;

this.listenToMany(actions1);
this.listenToMany(actions2);

View

对于View&＃xff0c;只需在React Component里的生命周期函数里&＃xff0c;负责监听Store的变化&＃xff0c;并及时通过调用setState&＃xff08;&＃xff09;方法更新UI即可&＃xff0c;就像下面这样&＃xff1a;


var myStore &＃61; Reflux.createStore({init: function () {// init}
});class MyComponent extends React.Component {componentDidMount() {this.unsubscribe &＃61; myStore.listen(this.onChange);}componentWillUnmount: function() {this.unsubscribe(); // 注意&＃xff1a;在组件销毁时&＃xff0c;一定要解除监听}onChange(data) {this.setState(data); // re-render}
}

上述方式&＃xff0c;是通过myStore.listen()来进行消息订阅的&＃xff0c;而实际上&＃xff0c;View本身并没有消息订阅的能力&＃xff0c;所以Reflux提供了一个mixin&＃xff0c;叫做Reflux.ListenerMixin。

它的实现是这样的&＃xff1a;

module.exports &＃61; _.extend({componentWillUnmount: ListenerMethods.stopListeningToAll
}, ListenerMethods);

作为React Component的一个mixin&＃xff0c;它其实做了两件事情&＃xff1a;

1. 给View添加ListenerMethods集合里的方法&＃xff0c;使View具备了消息订阅的能力。
2. 在组件销毁componentWillUnmount生命周期方法里&＃xff0c;对之前监听的Action自动解绑。

所以&＃xff0c;上述代码可以简化为&＃xff1a;

import Reflux from &＃39;reflux&＃39;;
import ReactMixin from &＃39;react-mixin&＃39;;class MyComponent extends React.Component {componentDidMount() {this.listenTo(myStore, this.onChange); // View本身具备了订阅的能力}componentWillUnmount: function() {// nothing 无需手动解除监听}onChange(data) {this.setState(data); // re-render}
}// ES6 mixin写法
ReactMixin.onClass(MyComponent, Reflux.ListenerMixin);

然而还有更简单的写法&＃xff0c;就是通过Reflux.connect()来写&＃xff0c;如下&＃xff1a;

import Reflux from &＃39;reflux&＃39;;
import ReactMixin from &＃39;react-mixin&＃39;;class MyComponent extends React.Component {componentDidMount() {// nothing 无需手动监听}componentWillUnmount: function() {// nothing 无需手动解除监听}onChange(data) {// noting 无需手动setState}
}// ES6 mixin写法
ReactMixin.onClass(MyComponent, Reflux.connect(myStore));

原理是这样的&＃xff0c;React.connect(myStore)返回的一个mixin&＃xff0c;这个mixin内部在做了类似下面的事情&＃xff1a;

this.listenTo(myStore, (data) &＃61;> {this.setState(data);
});

所以&＃xff0c;这才帮我们省去了手动监听&＃xff0c;手动删除监听&＃xff0c;还有手动触发UI更新这三步。

最后

参考资料

1. Flux inspired libraries with React
2. A cartoon guide to Flux
3. Deconstructing ReactJS&＃39;s Flux
4. The Reflux data flow model

以上就是本人对Flux以及Reflux的一些理解和使用小结&＃xff0c;不对的地方还请指出。

原创文章&＃xff0c;转载请说明出处&＃xff1a;http://www.cnblogs.com/lovesueee/p/4893218.html