1 媒介
许多同砚用过了Flux，也用过了Redux，但照样以为不满意？要不要本身造一个？一百行来代码就基本搞定，So easy, so good!
实在，本身造的框架实不实用，并不主要，主要的是头脑。有了设想框架的头脑后，再去看人家的框架，就会更多地关注人家为什么要这么设想？优点在哪？弊病在哪？是不是有革新的处所？邃晓了框架设想者的主意，才更好地运用框架。
如今，我们就一起来设想一个React框架，这个框架具有以下几个的特性：
单向数据流：营业数据从UI层触发，经处置惩罚到Module层便完毕，不再须要人为地将数据反应到UI层。
音讯机制：组件与效劳之间经由过程音讯总线完成，包括组件与组件之间的嵌套关联。
我们给这个框架起个嘹亮的名字——Rebus（React-Bus）。这里的Bus不是公交车的Bus，是计算机基本道理中“Bus”（总线）。很显然，我们要用“音讯总线”如许的头脑，完成ReactJs的单向数据流开辟情势。一句话归纳综合我们的框架：Rebus是一个基于音讯总线的，单向数据流的，ReactJs开辟框架。
这里是用Rebus写的一个TodoMVC实例：https://github.com/odebo/todomvc-rebus（看在我的代码写得云云粗拙的份上，大虾们赏颗星星勉励勉励下呗）。
2 什么是单向数据流情势
什么是“单向数据流情势”？这个观点对许多人来讲可以有点生疏。下面是Facebook的Flux官网（http://facebook.github.io/flux/）供应的申明图：
彷佛有点笼统？那我们先补补脑，看看什么是双向数据流情势。
什么是双向数据情势？简朴地说就是UI层的一个操纵经由UI层（View）、掌握层（Control）、情势层（Model），做完增、删、改、查等处置惩罚后，还得反过来，手动地将增编削查后的数据反应到UI层上。这就双向数据流情势。
而Flux中所谓的单向数据流情势是指：UI层监听运用的“状况”，当一个操纵（Action）经由Dispatch（分发器）、Store（状况容器），末了更新了“状况”，UI层自动依据“状况”的变化而更新界面。
这里的“状况”是指一个运用某个时刻的某个状况：比方左边菜单栏睁开与否——状况；导航中高亮项是谁——状况；用户是不是登录，用户是谁——状况；Table中多少个Item，离别是什么内容——状况。
简朴地说，单向数据流就是单向绑定，UI层与状况绑定，当状况发生变化，UI层自动更新。
可以有的同砚会问，既然有AngularJs如许的双向绑定的MVVM情势，还搞什么单向绑定情势，听起来弱爆了。双向绑定一定比单向绑定嵬峨上很多。
这个题目不太好下结论，双向绑定固然有双向绑定的优点，但也有它的弊病。而比拟单向数据流的逻辑处置惩罚思绪越发纯真清楚。
3 Rebus 框架的数据流模子
明白了单向数据流后，我们给出Rebus框架的数据流情势（如下图）。归纳综合起来就三个步骤：
UI层触发的一个Action。
Rebus总线依据Action路由表挑选对应的Service举行处置惩罚。
Service处置惩罚后，更新状况（State），完毕。
这里的Services层指的是营业效劳层，供应营业处置惩罚接口，包括对状况的修正，对背景数据的异步处置惩罚等等。假如以为这一层太厚，可以星散出特地的Modle接口层。但不论怎样，一个营业操纵从UI层到末了修正状况便完毕，数据流方向只需一个。
但光这么说照样太笼统了，我们直接上代码，看看在TodoMVC这个例子中，增添一个新的Todo这个操纵是怎样被处置惩罚的。
是不是是挺简朴，简约的三层构造，清楚的数据流：
ReactJs组件只担任衬着和触发Action，详细谁来相应Action，它不论。
Rebus总线依据Action路由表，挪用对应的Service举行处置惩罚。
Service层举行完逻辑处置惩罚后，经由过程Rebus.setState()要领更新状况。
但你一定会问：React组件是怎样监听状况的变化的？实在很简朴，直接看代码：比方我们愿望增添新的Todo后，TodoBody组件会自动更新。所以TodoBody组件应当监听状况“todos”的变化。
4 Rebus中的action
用过Flux的同砚都晓得Flux中有个叫Dispatch的模块，用来dispatch种种Action。而我们的Rebus.execute()的作用与Dispatch.dispatch()差不多（如下图）。
不一样的是Rebus.execute(actionHead, arg1,arg2,…)的第一个参数是action头，别的参数直接跟在action头背面。Action头中包括两个信息：要做什么？从那里来？
“从那里来”这个参数很主要，因为它给我们开辟、调试供应了极大的轻易。试想下，在Action路由表中，我们可以很清楚地看出一个Action将会到哪一个Service处置惩罚，但没法直观地看出一个Action是从那里触发的，而且一样的Action可以由差别的组件触发，这是没法从Action路由表中直寓目出来的。
所以，我们给Rebus增添了一个调试功用，只需翻开这个功用，便可以打印Action信息。
别的，假如一个Action被触发，却没在路由表中找到这个Action的路由，Rebus会经由过程打印错误信息的体式格局提示开辟者。
自从Action有了源信息，指导再也不必忧郁我找不到代码的出处了，欧耶!
5 Rebus中的Action路由表
Action路由表这个观点在Flux与Redux中没有，但也很好明白，就是一个很直观的路由设置信息表。它是在Web运用最先初始化时，加载进来的。
在这张Action路由表中，你可以直观地增添、修正、跟踪一个Action会被哪一个Service处置惩罚。当你愿望某个Action被另一个Service处置惩罚时，直接在这个Action路由表中举行修正就是。
别的，在这个Action路由表中，我们可以经由过程and()让一个Action触发多个service，如上图的第29行。我们写了一个日记效劳TodoLog.logAddTodo，愿望体系处置惩罚ADD_TODO的同时也纪录这个事宜。我们就可以经由过程and()函数将这个效劳绑定到ADD_TODO这条路由背面，and()的参数是一个数据，意义可以绑定多个效劳。
然则，必需提示的是，不提议and()中的效劳也修正State，除非你一定and()中的效劳修正的State与Rebus.connet()中的效劳修正的State的监听者没有任何交集。所以，再三提示and()中只绑定跟State无关的效劳，比方一些日记效劳、体系统计效劳等。
可以你会问，一个Web运用就一张Action路由表吗？是的，或许在后续的版本中我们可以支撑多个Action路由表。但一张路由表也有它的优点——唯一性。比方你设置了某个Action的路由，效果另一个同事在另一张路由表中也设置了同名的Action路由，一最先自力开辟时可以没有题目，一旦整合在一起，题目就涌现了。所以，只需一张路由表是有优点的，大点没紧要。
6 Rebus中的组件
我们都晓得ReactJs的一大特性就是支撑JSX语法，这使得JS代码中可以直接写“类标签代码”，而且一个组件可以被嵌套在另一个组件中，并接收从上级组件通报进来的参数。
这类一层一层嵌套的写法虽然很直观，但也很蛋疼。就拿上面Redux完成的Header组件增添新Todo这个操纵，实行的是通报进来的回调函数addTodo(…)。
这么做有几个题目：
1）写代码时，究竟是先商定Header组件要实行的回调函数叫addTodo，写上级组件时按商定通报叫addTodo的参数？照样先写好上级组件，依据上级组件通报的参数名来实行回调函数？究竟是先有蛋照样先有鸡？
2）果上级组件传参时传错了，或许子组件写回调函数时称号写错了，怎样跟踪代码，只晓得光从代码上看，我TM怎样晓得这个回调函数是从哪一个组件传进来的？虽然如今有些东西可以直接在浏览器上检察组件之间的嵌套关联，但那也是在运用可以一般跑起来的状况才Debug。
3）组件与组件之间的关联是经由过程硬编码完成，假如如今有个子组件须要替代，但是这个子组件被嵌入在多个组件中，试问这得怎样找？
组件嵌套是ReactJs的一大亮点，但也是许多人以为ReactJs不适合做大型项目的缘由。但我以为这并非ReactJs的题目，我们完全可以其他门路处理上面这些题目。比方我们的Rebus，组件与组件之间不会直接嵌套，而是跟挪用背景Service一样，经由过程Rebus.execute()要领，提议一个Action。比方TodoApp这个上层组件，它嵌套了TodoHead/TodoBody/TodoFoot这三个子组件，但你会发明TodoApp组件是经由过程execute了三个离别叫GET_TODOHEAD、GET_TODOBODY、GET_TODOFOOT的Action来引入三个子组件，详细引入是怎样的组件，它并不体贴。
Rebus总线依据Action路由表（rebus.route.js），离别找到这三个Action对应完成者（在这里我们经由过程一个“组件工场”CompFactory来相应这些Action）。当我们须要替代组件时，只须要在Action路由表中做出修正就是。
换句话说，在Rebus总线眼前，每一个组件都是同等的。组件只会跟Rebus总线沟通，不会直接嵌入别的组件，也不会被嵌到别的组件中。“组件树”这个观点在Rebus是经由过程Action音讯来完成的，是一种“动态嵌套”关联。
7 Rebus中的State
在Flux/Redux中，运用的种种状况以一棵“状况树”的情势都是从根组件上灌进去，一切子组件的状况一概从这个根组件上继续下来（不论组件树的构造有多深）。如许做的优点就是一旦某个状况发生变化，React组件自动从上到下举行更新。
然则，这么做真的好吗？并非说一个运用就一棵状况树这个主意不好，我也赞许这类设想，因为状况是Web运用中最主要但又异常轻易杂沓的信息，“唯一性”对状况来讲，异常主要。
但是假如一切子组件的状况都是从根组件一层一层通报进来的话，最少会有两个题目：
组件之间的耦合性高，难以并行开辟：子组件的状况是由父组件决议。那究竟先写父组件照样先写子组件？
状况变化后，难以跟踪变化的组件：假定你的某个操纵修正了某个状况，但这个状况的变化会致使哪些组件更新了？光从Store中是看不出的，也没法跟踪，只能从根组件一层一层往下查，看看这个State被通报到哪一个组件中。
在Rebus中，我们一样维系着一棵“状况树”，并在运用初始化的时就加载进来的。
但差别的是，组件的状况不是从上级组件中通报进来，是经由过程Rebus取得的，而且组件有权决议本身体贴哪一个State的变化。
如许做有几个优点：
轻易并行开辟：因为组件之间没有太甚的耦合性。状况都是经由过程Rebus取得的，大部分状况下都是直接返回状况树中的某个状况，如许的“浅处置惩罚”异常适用于庞杂体系开辟中。
轻易单元测试：因为组件直接与状况绑定（监听），要对一个组件举行单元测试，直接修正这个组件绑定的状况就是，等于没有上级组件的存在，也不影响测试。
轻易保护代码： 从上面的代码中可以清楚地看出某个组件监听哪些状况，但反过来，某个状况被哪些组件监听了？从组件的代码中是没法直寓目出来的。这个题目也不应当经由过程查阅代码的情势来处理，而应当经由过程我们的Rebus来处理。我们可以给Rebus增添一个要领，打印每一个State的监听者。如下图：
如今我们既可以清楚地看出一个组件监听了哪些状况，也能看出一个状况被哪些组件监听。这为代码的调试与保护供应极大的轻易。
别的，我们可以轻松地打印出某个时刻的状况树或详细某个状况的值。
8 总结
先给有耐烦看到这里的人鼓个掌……然后也给我本身鼓个掌……因为关于一个迁延症极端病患者来讲，用业余时间写这么一篇手艺贴至心不轻易。当我写这句话的时刻，间隔这个帖子的第一句话，整整隔了一个月！——老大，你是一禅指敲键盘的吗？
言归正传，总结下我们这个Rebus框架的特性：
完成了单向数据流情势，逻辑条理构造浅，思绪清楚。
React组件职责单一，只担任衬着与相应交互。
以路由表的情势掌握Action数据的流向，直观、易保护。
React组件之间经由过程音讯的情势完成动态嵌套。
