React with TypeScript 系列(五) --Flux

編者語：年末工作比較多，所以這麼遲才帶來Flux。話說廣州下雪也是奇景了，這個地球怎麼了。當倫敦是10度，廣州是4度也是醉了，還是那句大家要保護地球。
       對於React，更多是解決了UI層，也就是對於傳統MVC中的View.至於Model-Controller 如果要整合React的代碼又是如何實現呢？Facebook提出了一個叫做Flux([flʌks])的概念。
       在傳統MVC中，我們會遇到這樣一個問題，隨着項目功能和模塊的增長，所產生的Model和對應的View就會多起來，而系統的複雜性也隨之增加。如下圖：
       
       當然上圖的情況比較極端，但也是一個不能不面對的問題，特別是有雙向數據流產生的時候，就更難去解耦了。而Facebook所提供的Flux 是單向數據流的方式呈現，把MVC重新劃分成Action ,Dispatcher,Store,View 四個重要的組件。如圖：
       

       當Action觸發時，flux通過Dispatcher進行響應。換句話說，Dispatcher是一箇中轉站，它管理整個Flux架構的數據樞紐, 這看上去很像我們所說的Controller.而Store更接近我們的Model,負責數據的操作。但它也負責一些狀態變化。Dispatcher其實是一個Store的回調註冊。當Dispatcher響應Action時，通過已經註冊的回調函數，將Action所提供的數據傳送給對應的Store，而Store變化時，界面也會同步更新。

       聽上去有點複雜，我來說一個實例大家就會明白了，還是用回我們的主界面。我們把Facebook一個標準的Flux流圖作爲參考來說。
          
       當要加載頁面時，我們需要把Action Creators放在ComponentDidMount方法中，這樣才能把最後的數據給頁面。

         
         Dispatcher要做什麼，當然是把對應的Store回調處理好，如所對應的Action和返回的值。這裏要說我們需要做一個ActionType爲每個不同的Action事件做綁定（如增刪改查）。所以在定義Dispatcher時需要定義一個APIActionID的枚舉類型。如圖：
       

      注意：這個枚舉類型，分別會爲Store和Action作出對應ID。所以大家必須要注意。別以爲沒用了

      還有一個基本的對應類型APIAction

       
       Dispatcher的最後綁定是和APIAction做綁定
       
       當我們在componentDidMount中使用Action時，它是通過Dispatcher去尋找Store的回調把數據傳給Store保存，從而影響頁面的變化的。
       
      這裏就是Action中的加載，最後是要把返回的結果給Store的，所以會通過Dispatcher綁定actionType,和返回的結果。而在Store中,就只需要對應好actionType即可。下面的的方法就是我們針對不同的actionType，Store所要做的事情。
      
      Store涉及偵聽回調事件，所以通過EventEmitter去完成.這裏我們用到EventEmitter2
      
      這個時候，只要能匹配好actionType，數據就可以順利匹配上界面上了。
      Flux不是一個新的技術，而是一個設計模式。對於Flux更多的是優化項目架構。或者你更習慣MVC/MVVM,但當模塊增多的時候你會覺得它是更好的實現。