React學習之認識Flux架構模式

Flux是Facebook用戶創建客戶端Web應用的前端架構，它經過利用一個單向的數據流補充了React的組合視圖組件，這更是一種模式而非正式框架，你可以無需許多新代碼狀況下當即開始使用Flux。

• Flux應用有三個主要部分：Dispatcher調度 、存儲Store和視圖View(React 組件)，這些不該該和MVC:Model-View-Controll(模型-視圖-控制器)混淆，控制器在Flux應用中是存在的，可是他們是controller-view(控制器-視圖)，視圖一般在一個結構頂部，而這種結構是用來從存儲stroe得到數據，而後將數據傳遞到本身的子結構們，此外，Action建立者-Dispatcher的幫助類的方法 -用於支持一個語義API，這個API是描述應用程序中全部變化的可能，一般可將它們當作是Flux更新循環的第四部分。
• Flux是以單向數據流方式支持MVC，當一個用戶和React視圖交互時，視圖會將這個動做傳播到一箇中央Dispatcher，一直到各類存儲，在那裏保存着應用的數據和業務邏輯，這個使用React的聲明式風格的過程是很是棒的，可以容許存儲發送更新信息，而無需指定在狀態之間如何切換視圖。(傳統方式更新狀態後，會推出一個新的視圖頁面。)
• Flux最初是用於正確導出數據，好比若是咱們要顯示一系列消息的未讀數字，而另一個視圖顯示的是全部消息，其中未讀的消息會高亮顯示。這種狀況使用MVC很難處理，將一個消息變爲已讀狀態須要更新消息模型，而後再須要更新未讀的計數模型(將未讀模型數字減1，由於剛發生一個已讀改變)，這種依賴和級聯更新常常發生在大型MVC應用，致使一個混亂的數據流編織和不可預知的結果。
• 控制器被存儲反轉控制：存儲接受更新，適當地調節這些更新，而不是一致地依賴外部更新其數據，存儲以外根本不知道它是如何管理領域數據的，這有助於實現一種清晰的分離關注。存儲並無直接的相似setAsRead()之類的方法，而是隻有一個單一方式獲取數據到其自成一體的世界中，這個方式就是回調，註冊在dispatcher中的callback。

結構和數據流

• 一個單向數據流是Flux模式的核心。dispatcher 存儲和視圖是有着不一樣輸入輸出的獨立節點，Action動做是一個簡單對象，只是包含新的數據和一個標識符類型的屬性。
• 視圖也許引發新的動做Action，這個動做做爲用戶交互的響應將在整個系統傳播：

全部經過dispatcher的數據流將做爲一個集中式Hub，動做Action在一個action creator方法中被提供給dispatcher，這個動做一般來自於視圖中用戶的交互，dispatcher而後調用存儲已經註冊其中的回調函數，分發Action動做到全部的存儲，在它們註冊的回調函數中，存儲會響應每一個和它保存的狀態有關的每一個動做Action，存儲而後發射一個 change改變的事件去提醒controller-view控制器-視圖，更新到剛剛改變的新數據。controller-view監聽這些事件，而後在一個事件處理器中從存儲中獲取數據，controller-view調用它們本身的"setState()"方法，這會觸發視圖的從新渲染，包括DOM組件樹中全部更新。

• 這個結構容許咱們可以以比較理性的方式編程，這有點相似functional reactive programming, or 或 data-flow programming 數據流編程或 flow-based programming。
• 經過應用的數據流是一個方向，沒有兩邊綁定(two-way bingding：Angular.js有此方式)，應用狀態在存儲中維護，容許應用不一樣部分保持解耦，在存儲之間發生依賴的地方，它們可以保持嚴格的層次關係（設計原則：儘可能鬆耦合，沒法迴避的就變成樹形層次結構），同步管理由dispatcher負責。而two-way綁定會致使級聯更新，當一個對象改變致使另外對象改變，接着會觸發更多的更新，當應用規模增加時，這些級聯更新會使得預期響應用戶交互的結果變得困難，當更新只會在一個輪迴中發生改變數據時，整個系統就變得可預期。