簡介
在如今的 Web 開發領域，Flux 最流行也最容易被大家所誤解的技術之一。本教程打算以一種大家都能了解方式圖解 Flux。
問題
首先必須先說明一下 Flux 到底解決什麼問題。Flux 是一種應用處理的資料的模式。雖然 Flux 和 React 一同在 Facebook 成長起來的，很多人把它們合到一起來了解，但你仍然可以單獨使用它們。它們是被設計用來解決一些 Facebook 碰到的一系列問題的。
一個衆所周知的例子就是關于通知的錯誤。 當您登入Facebook時，您會看到通知消息圖示。 但是，當您單擊郵件圖示時，将不會有新消息， 通知将消失。 然後，幾分鐘後，與該網站進行了一些互動，通知就會回來。 你再次點選消息圖示…仍然沒有新消息。 它會在這個循環中繼續往複。
這種循環不僅僅影響了網站的使用者，還包含 Facebook 的開發團隊。 他們修複這個bug，好上一段時間，然後bug會回來。 周而複始，修一次，來一次。
是以Facebook正在尋找一種擺脫這種循環的方式。 他們不想一次次的修複。 他們希望使系統可預測，以確定這個問題不會重制。
深層問題
然而更深入的了解後，工程師們發現根本問題是應用資料傳遞的問題。
注意：這是我從他們在會談中分享的簡化版本中收集到的。 我确定實際的架構看起來不一樣。
他們用Model 儲存資料，并将資料傳遞到
View
層以呈現資料。
由于使用者互動是通過視圖發生的，是以視圖有時需要根據使用者輸入更新模型。 有時模型需要更新其他模型。
最重要的是，這些行為有時候會觸發一連串的變化。我把這想象成一種激動人心的乒乓遊戲——很難判斷球的落點在哪裡（或者是跑到了螢幕之外。）
我們還不能忽略這些變化可能會異步發生的事實。 一個變化可能引發多種其他變化。 我想這就是把一包乒乓球扔進你的乒乓球遊戲中，他們胡亂的飛。
總而言之，它很難調試資料流。
解決方案：單向資料流
是以，Facebook決定嘗試一種不同的架構，資料在一個方向上流動(隻有一個方向)當您需要插入新資料時，流程會從頭開始重新開始。 他們稱這種架構為
Flux
。
在 Facebook 的 Flux 文檔中也可以找到這張圖，本身要比看起來更酷，真的，非常酷……但光看上面這張圖可能無法完全明白。
一旦你了解了Flux，這個圖就很清楚了。 問題是，如果你對Flux完全是一個新手，我不認為這個圖可以幫助你了解它……然而這就是圖表應該做的。 在你開始深入了解你如何做特定事情之前，它應該讓你對系統有一個全面的了解。
幫助我更好地了解Flux的并不是這樣的圖表，而是根據不同角色以團隊形式共同實作目标的方式來考慮系統。 是以我想向你介紹我腦海中的角色。
認識一下角色
在我解釋這些角色間如何互動前，先逐個介紹下它們。
Action Creator
他的第一個角色是
Action Creator
。 它負責建立Action，這是所有變化和互動的喀什。 無論何時你想改變應用程式的
state
，或者讓
View
渲染的方式不同，你需要觸發一個 Action。
我認為Action Creator是電報操作員。 你帶着你需要發送出的消息，找到Action Creator，它以一種其他系統可以了解的方式将你的資訊進行格式化。
Action Creator使用
type
和
payload
(有效載荷)建立一個 Action。 該
type
将是您在系統中定義的
type
之一（通常是常量清單）。 一個Action的例子就像
MESSAGE_CREATE
或
MESSAGE_READ
。
讓你系統的一部分知道所有可能的行為或許存在一個副作用。 新開發人員可以參與該項目，打開Action Creator檔案并檢視系統提供的整個API - 所有可能的狀态更改，它們都是你的系統提供的。
一旦它建立了Action，Action Creator将該action傳遞給Dispatcher。
Dispatcher
Dispatcher基本上是一個巨大的回調函數系統資料庫。 這有點像電話交換機上的電話接線員。 它保留了它需要發送Action的所有store的清單。 當動Action跑到Action Creator這兒來時，Action Creator會将Action傳遞給不同的store。
Dispatcher它是以同步的方式完成的，對我之前講的多個乒乓球遊戲有所幫助。 如果你需要在store之間建立依賴關系，那麼你可以讓Dispatcher用
waitFor()
來為你管理它。
Flux的Dispatcher與許多其他體系結構中的Dispatcher不同。 無論action類型是什麼，該action都會發送到所有注冊的store。 這意味着store不僅僅訂閱一些操作。 它聽取了所有的action，并過濾掉了它所不關心的事情。
Store
接下來是store。 store可以保持應用程式中的所有狀态，并且所有狀态狀态變化的邏輯都位于store内部。
我覺得 store 就是一個充滿控制欲的長官。所有的狀态變化都必須由它來親自操作的。 所有的狀态改變都必須由它自己完成。 你不能直接要求它改變狀态。 store裡沒有setter API。 要請求狀态更改，您必須遵循适當的過程…您必須通過Action Creator/Dispatcher 送出動作。
正如我上面提到的，如果store在Dispatcher中注冊了，則所有action都将發送給它。 在store内部，通常會有一個switch語句來檢視action的類型，以決定該store是否關心此操作。 如果商店确實關心這個動作，它會根據這個action找出需要做出哪些更改并更新的
state
。
一旦
sotre
對
state
進行了更改，它将發出
change
事件。 這将通知控制器視圖狀态已經改變。
Controller View 和 View
View 層負責将 state 渲染給使用者，并接受使用者的輸入。
視圖更像是一位主持人。 它不知道應用程式中的任何内容，它隻知道送出給它的資料以及如何将資料格式化為人們可以了解的輸出（通過HTML）。
Controller View 就像store和View之間的中間管理者。store在state改變時告訴它。 它收集新state，然後将更新後的state傳遞給它下面的所有View。
它們如何在一起工作？
那麼讓我們來看看所有這些角色如何一起工作。
開始
首先在應用啟動時：應用程式初始化隻發生一次。
- Store 告知 Dispatcher他們希望在action産生時得到通知。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾 - Controller View 從 Store 中擷取最新的 state。
- 當 Controller View 接到來自 store 的 state，就将其傳遞給它所管轄的子 View 去渲染。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾 - Controller View 同時讓 store 在 state 變化的時候通知自己。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾
- Controller View 同時讓 store 在 state 變化的時候通知自己。
資料流
應用啟動後，就準備好接受使用者的輸入了。現在我們讓使用者做一些操作，觸發一個 action。
- View 告知 Action Creator 準備一個 action。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾 - Action Creator 做好 action 并将其發送給 Dispatcher。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾 - Dispatcher 按照順序将 action 傳遞給 store。每一個 store 都會受到所有的 action 通知，然後自行覺得是否對這個 action 做出響應，更新 state。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾 - 一旦 store 更新 state 完畢，就會告知訂閱了該 store 的 controller view。
- 這些 controller view 就會向 store 請求更新了的 state。
- 從 store 中獲得 state 之後，view controller 将會讓它所管轄的子 view 渲染新的 state。
圖解Flux簡介問題深層問題解決方案：單向資料流認識一下角色它們如何在一起工作？結尾
結尾
以上就是圖解Flux，接下來請看圖解Redux
原文