一塊兒學react | 漫談Flux

要解決什麼問題

首先小編先給你們介紹下Flux爲何存在，是解決什麼問題的。Flux是一種開發模式，而不是具體的一個框架，關鍵是它內在的思想。它核心的概念就是單向數據流。

React出現的時候，就已存在了Flux,它們是一塊兒成長和發展的，他們剛開始是爲了解決Facebook網站開發中遇到的一系列的開發問題，好比消息通知場景：

開發過消息通知場景同窗們，估計會遇到相似的BUG，明明接收到新消息提醒了，點進去沒有任何消息。沒過多久，又收到新消息了，點擊進去，又沒看到任何消息。就這樣周而復始，這種感受確實糟透了。

FaceBook的工程師看到這個問題後，這怎麼能行，趕忙修復後就發佈了。沒過多久，Bug又出現了。

所以FaceBook的工程師不但願這樣的問題周而復始的出現，他們但願系統是能夠預測的，只改一次，直接定位到問題的緣由。

 

潛在的問題

潛在的問題是應用程序的數據流，下面的圖是咱們常見的應用設計模式:

能夠看出，若是MODEL變化了，會影響好幾個相關VIEW的變化，同時一個VIEW也會對應多個MODEL,就比如咱們打乒乓球，遇到高手時，不知道他打過來的球在什麼位置，咱們如何去接。若是咱們的業務愈來愈複雜，就可能以下圖：

這些改變動可能是異步發生的，一個發生改變，會引發多個改變。就比如多個乒乓球向你飛來，你很難確認這些球在什麼位置落下。

所以你要調試BUG，很難定位到問題的根源。

 

解決方案：單向數據流

爲了解決上述問題，FaceBook大膽嘗試一種不一樣類型的架構，好比插入一條數據需求，數據插入的觸發，只能有一種方式，數據流的方向只能是單向的，若是再次插入，還須要從頭開始，具體示意以下圖（來自官網）：

這張圖看起來十分簡單清晰明瞭，你真的能很清楚這個圖的原理？尤爲對於新手，越是簡單的圖不必定是越容易理解的，爲了讓你們更好的理解這張圖，小編仍是用卡通人物的場景給你們介紹下。

 

人物介紹

小編一一介紹完這些人物後，再給你們講解下他們是如何一塊兒工做的：

The action creator

第一個介紹的人物是The action creator，每當你須要改變the state或者讓頁面有所變化，你必須建立action。

The action creator 就至關一個發電報的打字員，你只須要告訴他要發什麼內容，他們就會把你的內容處理成系統認識的格式，把它發送出去。

The action creator 會建立一個你定義的類型和傳入的參數。例如MESSAGE_CREATE 和 MESSAGE_READ 的 action。

這樣的好處就是，對於一個新加入大家團隊新人來講，打開項目是清晰明瞭的，對應的state是有哪一個Action觸發的一一對應，明明白白。

一旦Action建立，the action creator 會把Action傳遞給the dispatcher。

The dispatcher

The dispatcher 翻譯過來就是調度員的意思，全部的Action傳遞到這裏後，統一由它進行調度。The dispatcher  註冊了對應的回調函數，就像一個管理電話交換機的管理員，它會把Action傳遞給對應store。store只會接受處理本身關心的Action，不符合的Action將會被無視。

The store

接下來要介紹的是The store，The store更像一個獨裁者，他控制着 the state 改變的業務邏輯。

全部的store必須在dispatcher 進行註冊，全部的Action發送dispatcher 後，在dispatcher 裏經過switch語句來決定請求哪一個store，store接收請求後就會作出state的改變。

一旦state改變後，將會觸發一個改變事件，the controller view 將會監聽到這個事件，從而在view 顯示 state的改變。

The controller view and the view

The views 負責獲取 state 狀態呈現給用戶而且接收用戶輸入的請求。

The view 就至關一個會議發言人，他只需將結果結論的東西告訴你們，他並不須要知道這些結果是如何出來的。在系統裏，它並不關心繫統中數據是如何處理的，它只負責將數據在用戶面前呈現出來。

The controller 就至關 store 和 view 之間的中間人，view 的管理者，若是store 告訴他state改變了，他負責收集和整理。而後讓The view 進行把新的state呈現給用戶。

 

他們是如何一塊兒工做的？

介紹完這些人物後，小編給你們介紹下他們是如何配合和工做的。

系統初始化

1. 應用加載初始化時，Stores 命令 dispatcher 讓他時刻注意任何action的建立。

2.而後the controller views 告訴 the stores 若是state有變化，請告訴他。

3.若是 the stores 把 the state 改變的信息通知了the controller views,  controller views 就會命令相關的 views 作出響應。

4. The controller views 告訴 the stores 時刻保持聯繫，以便他們能作及時的反饋與響應呈現給用戶。

The data flow

一旦應用程序初始化完畢，就等待着用戶發號施令，下面小編給你們演示這這個流程是如何完成的。

首先用戶在界面中輸入了一個指令要求

1. The view 告訴 the action creator 去建立一個action。

2. The action creator 將格式化後的 the action 傳遞給 the dispatcher。

3. The dispatcher 將 the action 發送給對應的store 。每一個 store 處理他們關心的 actions。而後 the store 決定是否改變 the state。

4.一旦 state 改變, the store就去通知view controllers。

5. view controllers 就會要求 the store 告訴他們更新後的state。

6.  the store 告知更新後的state, the view controller 告訴 views 在頁面中顯示新的state。

這就是我對於Flux的理解，若有不正確的地方歡迎你們指正，但願今天的分享對你們有所幫助，謝謝你們。