大家好，很高興可以在鐵人賽這個公眾場合上自我介紹，前幾年我也都有受邀來自介，很開心大家找我朋友 React，最後都會找到我這邊來。。。。值得開心（？），歡迎大家到我的網站逛逛。
我的名字 Flux 其實是拉丁文中的 Flow（台下有人會講拉丁文嗎？）。我不是函示庫 (library) 也不是框架 (framework)，我只是一個擁有新概念的架構 (architecture)，也可以說是一種用來建立 React Framework 的 pattern。我是 Facebook 內部搭配 React 使用的架構，我提供單向資料流的概念 (Unidirectional Data Flow)。
而為甚麼它們會需要我呢？這是因為 React 專注在 MVC 的 view 層級，沒什麼現存的架構或樣式可以執行類似 Model 或 Controller 在做的事情，而且資料都包在元件裡，也就是在 view 之中。
這會有一個問題就是，在開發時應用程式領域 (app domain) 的狀態 - 簡稱為 app state，我們必須透過很複雜的程序，必須要透過 setState 來修改 state 的值，這樣就有點和脫褲子放屁一樣，明明就可以直接放，卻硬要脫褲子（透過 setState）(這個舉例顯得有點奇妙哈哈)。同樣的，在 React 樹狀結構中，child component 只能接收從 parent component 傳過來的 props 屬性值並呈現在 DOM 上，child component 本身沒有更改屬性值的權限。如此一來，元件間的溝通程序會變得很複雜，尤其是在開發相當規模的應用程式時，樹狀結構可不是幾層那樣簡單，很有可能像星巴巴千層蛋糕那樣，而且可能會需要與不同樹溝通，這時候如何降低元件間的溝通成本，這就是我們該解決的議題，所以這就是我誕生的目的（好感人一出生就為某個目標而活）。
這個問題的解決方式是要將整個應用程式的變動資料整合在一起，然後獨立出這個應用程式的 Model(模型)。同時也要獨立資料的更動方式，也就是上面提到的「應用程式領域的狀態」。不過為了區分元件中的狀態(state)，這個作為應用程式領域的持久性資料集合，會被稱為 store(儲存)。
用單一組件來說明好了，這一連串的步驟會匯整為一個資料流(Data Flow)，Flux用 單向(unidirectional) 資料流來設計整個資料流的運作，也就是說整個資料的 流動方向 都是一致的：
用 to-do list 做為範例，來探討這個流程。
Controller Views，也就是 React 的 Component，它在 Flux 架構中有兩個任務，一是它會觸發 Action，二是監聽 Store。假設我們今天新增一個 to-do 事項，這就是一個 action。當這個項目被儲存並更新之後，它會從 Store 接收到這個 event，接著更新自己。如果我們有一個 Component 撰寫篩選的邏輯，它會觸發一個篩選的動作 (Action)，接著 Store 會回傳符合篩選結果的內容。
Dispatcher 基本上就是 pub/sub（優秀的教學影片跟大家分享～絕不是葉配ＸＤ），是一種溝通事件的機制。
Action 會把動作送到 Dispatcher，Dispatcher 這個單字的中文解釋是「簽派員」，你可以想成它就是負責簽派從 Action 接過來的 to-do action，它會考慮要指派這些任務到哪個 Store。這麼說好了，假設 Dispatcher 是派報員，我們可以想成 Store 是訂閱者，那麼每次有新的報紙 (Action) 的時候，派報員就會把報紙送到有訂閱的讀者手上。每一個 Store 都可以訂閱報紙，而當它拿到報紙的時候，它才有辦法閱讀，也就是每一個模組都可以訂閱事件，當事件被觸發的時候，有訂閱該事件的模組才會開始運作。
接下來的三篇，會透過 to-do app 跑一遍 Flux 架構流程，好讓自己更深入了解整個運作原理。
參考資料：
iThome鐵人賽
看影片追技術