理解reflux中的事件結合

reflux是一個flux的實現框架，但又在部分概念和實現上與flux的產生了分歧。分歧點主要是爲了：

1. 簡化Flux的編碼量，讓機器完成那些重複的體力活。
2. 邁向Reactive Programming，而不是Imperative Programming.

一個重要的分歧點是reflux中取消了flux中的waitFor的概念，取而代之的是：

1. store之間能夠相互監聽。當一個Store完成數據獲取後，trigger出來的數據會傳遞到另外一個store，產生連鎖反應。
2. store監聽的actions能夠聚合，這是在flux中沒有的。

如下着重談談事件的聚合。

reflux主要提供了四個函數：

• joinLeading: 只響應第一次emit出來的，在完成一次trigger前，剩下的emission無論了。
• joinTrailing: 在一次trigger前，無視最後一次emission出來的數據。
• joinConcat: 在一次trigger前，保存全部emission的數據。
• joinStrict: 若是在一次trigger以前屢次emit，拋異常。

上次的說法仍是挺抽象的，具體到例子：

javascriptvar reflux = require('reflux');

var actions = reflux.createActions([
  'hello',
  'greet',
  'say'
  ]);

var store = reflux.createStore({
  init: function () {
    this.joinTrailing(actions.hello, actions.greet, actions.say, this.trigger);
  }
});

store.listen(function() {
  console.log('triggering with', arguments);
});


actions.hello('bubu');
actions.greet('chacha');
actions.say('dockers');
actions.hello(1,2,3);
actions.greet('miku');
actions.say('dockers');

結果：
triggering with { '0': [ 'bubu' ], '1': [ 'chacha' ], '2': [ 'dockers' ] }
triggering with { '0': [ 1, 2, 3 ], '1': [ 'miku' ], '2': [ 'dockers' ] }

上面例子表示，store監聽一系列action的集合，只有每一個Action都觸發了，纔會最後觸發store上註冊的回調函數。

而joinTrailing的意義在何處呢？若是把上面的action觸發順序換成下面：

actions.hello('bubu');
actions.hello(1,2,3);
actions.greet('chacha');
actions.say('dockers');
actions.greet('miku');
actions.say('dockers');

結果：

triggering with { '0': [ 1, 2, 3 ], '1': [ 'chacha' ], '2': [ 'dockers' ] }

會發現bubu已經被無視了，且因爲剩下的greet和say沒法完整地構成事件組合，故沒有觸發回調。

對於joinConcat可得：

javascriptactions.hello('bubu');
actions.hello(1,2,3);
actions.greet('chacha');
actions.say('dockers');
actions.greet('miku');
actions.say('dockers');

結果：

triggering with { '0': [ [ 'bubu' ], [ 1, 2, 3 ] ],
  '1': [ [ 'chacha' ] ],
  '2': [ [ 'dockers' ] ] }

joinLeading和joinStrict就不舉例了。