前陣子 Facebook 推出一套名為 FLUX 的前端程式架構，期望能幫過去沒有條理，程式多了結構就亂得像一團麵條的 Javascript 程式寫法找到一個理想的組織方法。
FLUX 簡介
視圖（View）-> 操作（Action）-> 分配器（Dispatcher）-> 資料處理器（Store）-> 繪圖者（Renderer）-> 視圖（View） FLUX 的基本原理有別於常用的 MVC（Model/View/Controller）或 MVVM（Model/View/ViewModel）是在 M，Ｖ，C（VM）三者之間互相傳遞或修改資料，
MVC (image from fluxxer)
FLUX 重新定義整個組織架構為單向的視圖（View）-> 操作（Action）-> 分配器（Dispatcher）-> 資料處理器（Store）-> 繪圖者（Renderer）-> 視圖（View）的運作流程。
FLUX (image from fluxxer)
就我的理解，FLUX 的架構可以拆分為三個重點流程：
- 跟視圖（View）有關的操作（Action），都透過事件註冊到分配器（Dispatcher）去。
- 分配器 （Dispatcher）負責將操作（Action）傳遞給需要的資料處理器（Store）。
- 資料處理器（Store）負責跟資料直接相關的操作。若資料處理器（Store）修改的結果需要反映到視圖（View）上，可以透過發送訊息通知給繪圖者（Renderer）處理。這邊講到了原本 FLUX 概念圖中沒有提到的繪圖者（Renderer）這個角色，在 Facebook 中他們是用 ReactJS 處理。
瞭解其基本架構之後，我發現其實就算不用他們提供的函式庫，用 Javascript 內建的 addEventListener, handleEvent, customEvent 等方法，也可以利用前面所提的三個重點，漸進寫出符合 FLUX 精神的程式。
目前的 JS 組織方式
一個常見的 JS 檔案，一般的架構是
var App = { init: function app_init() { // get view this.view1 = document.getElementById('xxx1'); this.view2 = document.getElementById('xxx2'); // do stuff this.view1.addEventListener('click', function() { // do something }); this.view2.addEventListener('keyup', function() { // do something }); } }; 若我們想要將視圖（View）的操作從 init 分離開來，大部分的人會這樣做
var App = { init: function app_init() { // get view this.view1 = document.getElementById('xxx1'); this.view2 = document.getElementById('xxx2'); // do stuff this.view1.addEventListener('click', this.clickView1); this.view2.addEventListener('keyup', this.keyupView2); },
clickView1: function app_clickView1() { // do something },
keyupView2: function app_keyupView2() { // do something }
}; 如果在 clickView1 或 keyupView2 中要呼叫到 App 裡的參數或方法，那麼我們需要在 addEventListener 時使用 bind (this)
var App = { init: function app_init() { // get view this.view1 = document.getElementById('xxx1'); this.view2 = document.getElementById('xxx2'); // do stuff this.view1.addEventListener('click', this.clickView1.bind(this)); this.view2.addEventListener('keyup', this.keyupView2.bind(this)); },
clickView1: function app_clickView1() { // do something },
keyupView2: function app_keyupView2() { // do something this.clickView1(); }
}; 大多數書籍的範例大概就停在這裡，沒有再進一步探討程式的組織架構了。即使是龐大的 Javascript 專案如 Gaia，不少部分的程式碼組織方式也是如此。在這種組織方式裡，若有很多的視圖（View）需要操作或修改，我們的程式碼就會開始亂起來。
下面來試著將以上程式漸進改為 FLUX 架構。
改進建議一：將 handleEvent 當作 Dispatcher 來使用
跟視圖（View）有關的操作（Action），都透過事件註冊到分配器（Dispatcher）去。 （溫馨提示：IE 9 以上版本才有支援 handleEvent 方法，在之前版本上使用要加 polyfill）
我們先來想想看視圖（View）跟操作（Action）在前端 Javascript 程式中分別代表著什麼。 視圖（View）很明顯，就是透過 getElementById 等方法，從 HTML 中取得代表對應節點（Node）的元素（element）。
若想要套用 FLUX 架構，我們可以將附加在各個元素（element）上的事件行為分離，將事件註冊到一個統一的地方（分配器），在這個地方對不同的事件進行操作。
Javascript 內建的分配器叫做 handleEvent，它可以拿來處理任何事件 Event，寫法如下。
var App = { init: function app_init() { // get view this.view1 = document.getElementById('xxx1'); this.view2 = document.getElementById('xxx2'); // do stuff this.view1.addEventListener('click', this); this.view2.addEventListener('keyup', this); },
handleEvent: app_handleEvent(evt) { switch (evt.type) { case 'click': switch (evt.target) { case this.view1: this.clickView1(); break; } break; case 'keyup': switch (evt.target) { case this.view2: this.keyupView2(); break; } } },
clickView1: function app_clickView1() { // do something },
keyupView2: function app_keyupView2() { // do something this.clickView1(); }
}; 這麼做帶來的明顯好處是所有的呼叫都統一在 handleEvent 中，可以更容易地追查到。
這麼寫也可以在 addEventListener/removeEventListener 時不用使用 bind (this)，而 bind (this) 經常有些 side effect 需要特別留意。
例如假使我們想要反註冊 view1 上的 click 方法，使用以下寫法
this.view1.removeEventListener ('click', this.clickView1.bind (this)); 其實並沒有將第一個 event 移除。因為使用了 .bind(this) 後，回傳的其實是一個新的 instance...。 正確的寫法是 this.bindClickView1 = this.clickView1.bind (this) this.view1.addEventListener ('click', this.bindClickView1); ... this.view1.removeEventListener ('click', this.bindClickView1); 用 handleEvent 可以省點事，要反註冊時也傳入 this 即可。 this.view1.removeEventListener ('click', this);
改進建議二：將資料處理的部分分離，使用自訂事件來改變 Store 狀態
分配器 （Dispatcher）負責將操作（Action）傳遞給需要的資料處理器（Store） 資料處理器（Store）負責跟資料直接相關的操作。在稍大的 Web App 中，我們可以另外定一個 Object 來處理資料相關的事宜。一般我們的寫法會是
// Store.js function Store() { this._data: 0; };
Store.prototype = { getSomething: function s_getSomething() { return this._data; },
doSomething: function s_doSomething() { this._data += 1; },
setSomething: function s_setSomething(val) { this._data = val; } };
// App.js var App = { this.store = new Store(); this.store.init(); this.store.getSomething(); this.store.doSomething(); this.store.setSomething (2); }; 若想要套用 FLUX 架構，首先我們要避免從資料處理器（Store）外部直接改變資料處理器（Store）。我們可以透過在呼叫端使用 window.DispatchEvent 發送自訂事件（CustomEvent），並在資料處理器（Store）中接收自訂事件來做到。
如此一來，資料處理器（Store）將只留下 get 方法來讓外部取得 Store 想提供的資料。
另外如果程式碼改善進入到下一個重點，在操作（Action）時應該不需要再呼叫 Store.getSomething 了，我們將資料處理器（Store）的 getSomething 方法留著給繪圖者（Renderer）使用 。
// Store.js function Store() { this._data: 0; };
Store.prototype = { init: function s_init() { window.addEventListener('store_do', this); window.addEventListener('store_set', this); },
handleEvent: s_handleEvent(evt) { switch(evt.type) { case 'store_do': this.doSomething(); break; case 'store_set': this.setSomething(evt.detail.val); break; } },
getSomething: function s_getSomething() { return this._data; },
_doSomething: function s_doSomething() { this._data += 1; },
_setSomething: function s_setSomething(val) { this._data = val; } };
// App.js var App = { this.store = new Store(); this.store.init(); //this.store.getSomething(); window..dispatchEvent(new CustomEvent('store_do')); **window..dispatchEvent(new CustomEvent('store_set',** {'detail':{'val':2}} )); }; 這麼做帶來的明顯好處是測試時可以簡單地將 Store 與 App 分開來測試，這對大型 App 是很重要的。
改進建議三：讓 Renderer 來處理視圖
若資料處理器（Store）修改的結果需要反映到視圖（View）上，可以透過發送訊息通知給繪圖者（Renderer）處理 > // Renderer.js var ClickRenderer = { init: function s_init(element, Store) { this.element = element; this.store = Store; window.addEventListener('render_view1', this); },
handleEvent: s_handleEvent(evt) { switch(evt.type) { case 'render_view1': this.element.textConent = this.store.getSomething(); break; } }};
// Store.js function Store() { this._data: 0; };
Store.prototype = { init: function s_init() { window.addEventListener('store_do', this); window.addEventListener('store_set', this); },
handleEvent: s_handleEvent(evt) { switch(evt.type) { case 'store_do': this.doSomething(); break; case 'store_set': this.setSomething(evt.detail.val); break; } },
getSomething: function s_getSomething() { return this._data; },
_doSomething: function s_doSomething() { this._data += 1; window..dispatchEvent(new CustomEvent('render_view1')); },
_setSomething: function s_setSomething(val) { this._data = val; } };
// App.js var App = { init: function a_init() { // get view this.view1 = document.getElementById('xxx1'); this.view2 = document.getElementById('xxx2'); this.store = new Store(); this.store.init(); ClickRenderer.init(this.view1, **this.store);** },
handleEvent: a_handleEvent(evt) { window..dispatchEvent(new CustomEvent('store_do')); //Store.setSomething(2) window..dispatchEvent(new CustomEvent('store_set', {'detail':{'val':2}} )); }; 上段程式在 App 中註冊了 ClickRenderer，並傳入 Store 與 所需的 View 元件。所有的介面更新全交由 ClickRenderer 處理。
（另一個方法是讓繪圖者（Renderer）監看資料處理器（Store）的狀態，然後去改變視圖（View）） http://fluxxor.com/documentation/store-watch-mixin.html
總結
整理完後，一般 javascript 套用 flux 架構的運作流程如下：
簡而言之，上面的各種建議是鼓勵大家多使用 Javascript 內建的 addEventListener, handleEvent, customEvent 等方法。透過大量使用 event，我們可以改善 Javascript 程式邏輯，資料，與介面元件之間的關聯程度。
將 FLUX 架構拆分為三個重點流程來理解或實踐的好處，是我們能漸進地遵循其中一些方法來改善我們現有的程式架構。
以上是我關於如何使用 FLUX 架構在一般 Javascript 組織方式的第三個版本，可能有些錯謬之處，還迎大家討論或給予建議。
