深刻淺出React和Redux學習筆記（三）

從Flux到Redux

Redux管理應用狀態的框架：

1. 單向數據流的始祖Flux;
2. Flux理念的一個更強實現Redux;
3. 結合React和Redux;

1.Flux

Redux是Flux思想的另外一種實現方式；

Flux(含Redux)貫徹的重要觀點——單向數據流；

Flux推翻了MVC框架，用了新的思惟來管理數據流轉；

1.1MVC框架的缺點

MVC框架把應用分爲三部分：

1. Model(模型)：負責管理數據，大部分業務邏輯在Model之中；
2. View(視圖)：負責渲染用戶界面，應避免在View中涉及業務邏輯；
3. Controller(控制器)：負責接收用戶的輸入，根據用戶輸入的Model部分邏輯，把產生的數據交給View部分，讓View渲染必要的輸出；

MVC框架的缺點：

對於很是巨大的代碼庫和龐大的組織，MVC框架很快變得很複雜。每新增一個功能時，對代碼的修改很容易引入新的Bug,不一樣模塊之間的依賴關係讓系統變得「脆弱且不可預測」。

Flux的特色：

更嚴格的數據流控制；

Flux應用分爲四個部分：

1. Dispatcher:處理動做分發，維持Store之間的依賴關係；
2. Store：負責存儲數據和處理數據相關邏輯；
3. Action：負責驅動Dispatcher的JavaScrip對象；
4. View：視圖部分，負責顯示用戶界面；

   

Flux和MVC結構上的區別：

1. Flux的Dispatcher至關於MVC的Controller；
2. Flux的Store至關於MVC的Model;
3. Flux的View至關於MVC的View;
4. Flux的Action能夠理解爲MVC框架的用戶請求；

1.2Flux應用

一個EventEmitter實例對象支持的函數：

1. emit函數：能夠廣播一個特定事件，第一個參數是字符串類型的事件名稱；
2. on函數:能夠增長一個掛在此EventEmitter對象特定事件的處理函數，第一個參數是字符串類型的事件名稱，第二個參數是處理函數；
3. removeListener函數：和on函數作的事情相反，刪除一個掛在此EventEmitter對象特定事件的處理函數，和on函數同樣的是，第一個參數是字符串類型的事件名稱，第二個參數是處理函數。注意：若是要調用removeListener函數，就必定要保留對處理函數的引用；

如何使Dispatcher調用回調函數的順序是咱們預期的呢？

Dispatcher的waitFor函數。

Dispatcher的waitFor函數能夠接受一個數組做爲參數，數組中的每個元素都是Dispatcherregister函數的返回結果，即dispatchToken。這個waitFor函數告訴Dispatcher，當前的處理必須暫停，直到dispatchToken表明的那些已註冊回調函數執行結束才能繼續。

存在於Flux框架中的React組件須要實現的功能：

1. 建立時讀取Store的狀態來初始化組件的狀態；
2. 當Store上狀態發生變化時，組件要馬上更新內部狀態保存一致；
3. View若是要改變Store狀態，必須並且只能派發Action;

1.3Flux的優點

Flux的架構下，應用的狀態被放在Store中，React組件只扮演View的做用，被動根據Store的狀態來渲染。

Flux的優點主要表如今「單向數據流」的管理方式。

在Flux的理念中，改變界面就必須改變Store的狀態，改變Store的狀態就必須派發一個對象。

MVC最大的缺點就是沒法禁絕View和Model之間的直接對話。

在Flux的體系下，驅動界面的改變始於一個動做的派發，別無他法。

1.4Flux的不足

1. Store之間的依賴關係；
2. 難以進行服務端渲染；
3. Store混雜了邏輯和狀態；

2.Redux

若是把Flux看作一個框架理念的話，Redux就是Flux的一種實現，除Redux以外，實現Flux的框架有Reflux、Fluxible等。

2.1Redux的基本原則

Redux的三個基本原則：

1. 惟一數據源（Single Source of Truth):應用的狀態只存儲在惟一的一個Store上；
2. 保持狀態只讀(State is only-read):不能直接去修改狀態，要修改Store的狀態，必須派發一個Action對象完成。

   驅動用戶界面渲染，就要改變應用的狀態，但不是去修改狀態的值，而是建立一個新的狀態對象給Redux，由Redux完成新的狀態的組裝。

3. 數據改變只能經過純函數改變(Changes are made with pure functions);

2.2Redux實例

無

2.3容器組件和傻瓜組件

在Redux的框架下，一個React組件基本要完成兩個功能：

1. 和Redux Store打交道，讀取Store的狀態，用於初始化組件狀態，同時還要監聽Store的狀態改變；當Store狀態發生改變時，須要更新組件狀態，從而驅動組件從新渲染；當須要更新Store狀態時，就要派發Action對象；
2. 根據當前props和state,渲染出用戶界面；

讓一個組件專一一件事，若是發現一個組件作的事情太多，就能夠把這個組件拆分紅多個組件，讓每一個組件依然只作一件事情。

容器組件(Container Component):承擔第一個任務的組件，即負責和Redux Store打交道的組件，處於外層；另外一種說法叫作聰明組件(Smart Component)。容器組件作的事情涉及一些狀態轉換。

展現組件(Dumb Component):承擔第二個任務的組件，即只專心負責渲染界面的組件，處於內層；另外一種說法叫作傻瓜組件(Dumb Component)。傻瓜組件其實就是一個純函數，根據props產生結果。

2.4組件Context

組件Context:就是所謂的「上下文環境」，讓一個樹狀組件上的全部組件都可以訪問的對象，爲了完成這個任務，須要上級組件和下級組件配合。

首先，上級組件要宣稱本身支持Context，而且提供一個函數來返回表明Context的對象。

其次，此上級組件之下全部的子孫組件，只要宣稱本身須要這個Context，就能夠經過this.context訪問到這個共同的環境對象。

1. 上級組件提供Context；
2. 下級組件使用Context;

Redux對Store的封裝好,沒有提供直接修改狀態的功能。雖然組件可以訪問全局惟一的Store，可是不能直接Store中的狀態，克服Store做爲全局對象的缺點。

2.5React-Redux

改進React應用的兩個方法：

1. 組件拆分爲容器組件和傻瓜組件；
2. 提供組件直接訪問的Context；

Redux兩個最主要的功能：

1. connect:鏈接容器組件和傻瓜組件；
2. Provider:提供包含Store的Context;

1.connect

容器組件的工做：

1. 把Store的狀態轉化爲內層傻瓜組件的prop；
2. 把傻瓜組件的用戶動做轉化爲派發給Store的動做；

簡言之，一是對內層傻瓜組件的輸入，二是內層傻瓜組件的輸出。

2.Provider

React-Redux要求Store所包含的三個函數的Object:

1. subscribe
2. dispatch
3. getState

擁有以上三個函數的對象，才能稱之爲Redux的Store。

React-Redux定義了Provider的componentWillReceiveProps函數，在React的生命週期中，componentWillReceiveProps函數每次渲染時都會被調用。

每一個Redux應用只能有一個Redux Store ,在整個Redux的生命週期中都應該保持Store的惟一性。