摘要:[ReactJS]React學習筆記(4) - Flux簡介
Flux是Facebook隨著React.js推出的一個架構，或是該說是一種Convention，因為這是一種概念，並沒有固定的實作方式。Facebook推出Flux的目的，是要解決傳統MVC模式中，當專案變大時，View與Model間的關係變複雜的問題。
Flux的概念
所以Flux採取的方式，就是使用單向資料流的概念，避免雙向邏輯的產生，以降低耦合度。底下這張圖就是Flux的概念，可以直接地看出物件之間的邏輯是單向的。
實作上，程式運作的流程如下：使用者在View上面操作後，View會依據使用者不同的行為，建立起不同的Action送給Dispatcher。因為Stores中 已經針對不同的Action建立起不同的處理function並Register到Dispatcher，所以Dispatcher會依據這些 Action執行Stores給予的邏輯。Stores處理完內部的狀態後，就會觸發Change事件。Controller View會Listen這些事件，知道Stores內部狀態修改後，透過Stores API取得變動後的資料，並將這些資料透過this.state傳給Controller View下層的React Component。
在沒有看到Code之前，上面的描述看起來很複雜。如果簡化一點這個概念，其實可以看做Store與View之間進行低耦合的操作。要達到低耦合，這裡是使用publish-subscribe pattern來達成。
底下再分別依據不同的角色進行說明。
Store
Store主要是在管理React Component運作的狀態資料，不同的Action發生時，進行狀態資料的更新處理及邏輯運算。例如一個計算機Component，他的Store要處理的事情，就是當Clean的Action發生時，就要進行資料值的歸零。除此之外，當狀態資料有異動時，也要產生一個事件，以通知相關的View。
由下圖可以看出，Store其實是這整個模式的中心，他透過Dispatcher的Register()將處理不同Action的邏輯注入到Dispatcher中。當不同的Action發生，Store會被通知，並且執行相對應的邏輯。這樣子的資料流是由Action流到Dispatcher再到Store。
當Store的邏輯進行時，會引發Change事件，而監聽(Listen)這個Change事件的角色，就會是Controller View。關注此Store的View，如果需要處理該Store的變動，則會建立一個事件處理的function到此Store的異動事件上。這樣子的資料流是由Store到View。並且讓View自行決定如何處理Store的異動事件，如果View需要知道狀態資料的內容，則再呼叫Store給的API以取得回傳值。
Dispatcher
Dispatcher：處理View到Action再到Store間的資料流。Dispatcher是Singleton，統一處理Action的派送。Dispatcher的機制是讓Stroes登錄(Register) callback function。該function中會處理該Store有興趣處理的Action。所以在之後由View觸發的Action中，會傳入Payload(資料) 到Dispatcher中，Dispatcher自行去叫用對應的Store callback function。這種設計的好處是把Store與Action的相依性分開，Action不用去管是哪個Store要來處理它。當一個Action被定義出來後，要增加或減少Stores的處理都沒關係。而Store對於Action的關係也是單向的，Store並不會反向去影響到Action。
Controller
Controller View：Controller View的目的是作為其子元件的State管理中心，統一管理整個子孫代的View的資料，以及統一處理Store傳來的Change事件。當資料異動時，會接收到Store的發出的事件通知，Controller View再自行決定該如何處理此資料異動，並透過props傳遞給子元件。Controller View通常不會產生Action，主要是接受Store傳來的資料流，並傳到底下的子View。而Action主要是那些子孫View透過UI的互動產生，然後產生另一個由Action到Store到Controller View的循環。
