[譯]看漫畫學Flux

原文地址：A cartoon guide to Flux - by Lin Clark

Flux在目前web開發中最受歡迎也較不被人理解，本文會以簡單易懂的方式解釋它。

出現問題

首先，我要聲明Flux所解決的基本問題。Flux是一種幫助你處理數據的模式。Flux和React都由Facebook開發。許多人把他們放在一塊兒用，固然你也能夠單獨使用它們。它們的造成是爲了解決Facebook所面臨的一系列典型問題。
這些問題中一個廣爲人知的例子就是關於通知的錯誤(notification bug). 當你登陸Facebook時，你會經過消息圖標(message icon)看到一則通知(notification)。然而你點擊消息圖標後，可能根本沒有新消息，通知消失了。接着，在與網站進行幾回交互以後，通知又回來了。你再一次點擊消息圖標...依然沒有新消息。這個狀況會在循環中繼續往復發生。

這不只僅是發生在用戶裏的循環，對於Facebook團隊裏也會有這個循環。他們修復了錯誤，一切在一段時間裏看似表現很好，接着錯誤又回來了。這一直處於解決問題和再次出現問題之間來回切換。

因此Facebook在尋找跳出死循環的方法。他們不想僅僅是修復一次bug，他們但願保證系統可預測，這樣他們就能確保問題不會從新出現。

根本問題

他們發現根本問題在於數據流經應用程序的方式。
住：這是我從他們的分享會上展現的簡化版本中收集到的，我肯定實際的架構看起來並不同。
他們有保存數據的模型(Model)，並將數據傳遞到視圖層(View Layer)渲染。

由於用戶交互發生在視圖層，視圖有時候須要根據用戶輸入來更新模型。有時模型還須要去更新其餘的模型。最重要的是，這些行爲有時會引起其餘一系列的變化。我認爲這很是有趣，由於你沒法知道接下來會發生什麼！（做者此處用了比喻，I envision this as an edge-of-your-seat game of Pong — it’s hard to know where the ball is going to land (or fall off the screen)）

不考慮這些變化會引發異步發生的可能性。一個變化可能會一塊兒多種其餘變化。我想這就好像拋出一袋乒乓球到乒乓遊戲中，隨着他們飛過整個地方並穿太小徑。
總而言之，它使得調試數據流變得很困難。

解決方案：單向數據流

Facebook以爲嘗試一種不一樣的架構，數據向一個方向流動——只有一個方向——當你插入新數據時，這個流程就從頭從新開始。他們稱這一架構爲Flux。

實際上這個技術很是棒...但你可能沒法從上面這張圖裏看出來。
一旦你理解了Flux，這張圖就顯得很是清晰。問題是若是你要找到對Flux徹底新的文檔，我認爲這張圖不能幫助你理解它...這就是圖應該作的事。在你開始深刻了解如何作特定事情以前，圖會讓你對系統產生一個全面的瞭解。
幫助我更好理解Flux的不是這樣的圖，而是根據團隊中不一樣角色要實現共同目標來考慮這個系統。因此我會想你介紹我腦子裏的這些角色。

角色

在我將這些角色聯繫起來以前，我先對各個角色作簡單介紹。

行爲建立者(Action)

第一個角色是這個行爲建立者。他負責建立行爲，這是全部改變和交互必須經歷的路徑。不管你是否想改變程序的狀態，或者讓視圖的渲染方式不一樣，你都須要建立行爲。
我認爲行爲建立者就像電報員。他知道你想傳遞什麼消息，接着再以其餘系統能夠理解的方式格式化信息。

行爲建立者建立行爲時，會伴隨一個type和一個payload。type表示你在系統中定義爲行爲的類型之一（一般是常量列表），好比MESSAGE_CREATE或MESSAGE_READ。
讓系統的一部分知道全部可能的行爲有一個很好的做用，那就是，當新人蔘與到項目裏時，打開行爲建立者的文件就能看到整個API——系統提供的全部可能的狀態改變。
一旦建立了行爲消息，行爲建立者就會將該行爲傳遞給調度人員。

調度人員(Dispatcher)

調度人員有一個大的回調(callbacks)註冊表(registry)，在某種程度上像電話交換機上的接線員，保留數據層(store)中須要發送的行爲列表。當行爲被行爲建立者建立後，調度人員會將行爲發送給不一樣的數據層。
調度人員以同步方式完成工做，若是你須要在數據層之間設置依賴關係，以便在其餘數據層更新前更新，你可讓調度人員使用waitFor()進行管理。

Flux的調度人員與其餘不少架構中的不一樣。不管行爲類型是什麼，它都會被髮送到全部的註冊數據層裏。這意味着數據層不只僅收到一些行爲消息，而是接收所有消息再就實際狀況過濾。

數據人員(Store)

接下來就是數據人員了。數據人員掌控這程序裏全部的狀態，以及狀態的改變邏輯。
我把數據人員比喻成權力極大的爺，全部的狀態改變必須由他親自完成。你不能直接要求他改變狀態，要請求更改狀態，你必須遵循適當的步驟：經過行爲建立者或調度人員提交行爲。

正如我以前提到的，若是一個數據層被調度人員註冊，全部的行爲將會發送到那裏。在數據層裏，數據人員通常會用一個switch語句查看行爲類型，以決定這個數據層是否關心此行爲。若是數據層關心此行爲，那麼數據人員會根據這個行爲找出須要作出哪些更改並更新狀態。
一旦數據人員改變了狀態，他就會提交一個改變事件，這會提示視圖控制員知道狀態變了。

視圖與視圖控制員(Controller view & view)

視圖負責拿到狀態並將其渲染出來給用戶看，以及接收用戶輸入。
視圖是一個展現者，他並不知道程序裏發生任何事，只知道接收到的數據，以及如何將數據格式化成用戶能理解的方式（經過HTML）。
視圖控制員更像一個在數據人員和視圖之間的中層經理，數據人員告訴他狀態何時變了，他收集到新狀態再將更新狀態發送給他的子視圖。

他們怎麼一塊兒工做

接下來看看這些角色怎麼共同工做的。

初始化(setup)

首先有個初始化：只發生一次的程序初始化。

• 數據員(stores)使得調度員(dispatcher)知道，不管什麼時候有行爲(action)來了，數據員須要被通知。

• 視圖控制員(controller views)向數據員(stores)詢問最新狀態(state)。
• 當數據員向視圖控制員說明了狀態後，視圖控制員把這個狀態告訴其子視圖去渲染。

• 視圖控制員也告訴數據員當其狀態改變時記得通知本身。

數據流(date flow)

一旦初始化完成後，程序就準備好接收用戶輸入。如今，咱們假設用戶作改變引發了一個行爲(action)。
咱們經過用戶交互來啓動數據流。

• 視圖(view)告訴行爲建立者(action creator)準備行爲。

• 行爲建立者格式化行爲併發送給調度員(dispatcher)。

• 調度員按順序將行爲發送給數據人員(store)，每一個數據員都收到了全部行爲的提示，接着數據員篩選哪些是他關心的，再相應地改變數據層狀態(state)。

• 一旦狀態改變，數據員就會讓當時須要他通知的那些視圖控制員知道其狀態變化。
• 這些視圖控制員會向數據員要他們更新後的狀態。

• 在數據員給了本身更新後的狀態，視圖控制員就會告訴其子視圖根據新狀態從新渲染。

這就是我認爲的Flux，但願對你有用！

譯者：若有翻譯錯誤，請指正喲，謝謝！(＾Ｕ＾)ノ~ＹＯ