原文地址

 http://www.alloyteam.com/2015/09/react-redux/

繼 Facebook 提出 Flux 架構來管理 React 資料流後，相關架構開始百花齊放，本文簡單分析 React 中管理資料流的方式，以及對 Redux 進行較為仔細的介紹。

React

" A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES "

在 React 中，UI 以元件的形式來搭建，元件之間可以巢狀組合。另，React 中元件間通訊的資料流是單向的，頂層元件可以通過 props 屬性向下層元件傳遞資料，而下層元件不能向上層元件傳遞資料，兄弟元件之間同樣不能。這樣簡單的單向資料流支撐起了 React 中的資料可控性。

那麼，更全面的元件間通訊形式該怎麼實現呢？

1. 巢狀元件間，上層元件向下層元件傳遞迴調函式，下層元件觸發回撥來更新上層元件的資料。

2. 以事件的形式，使用釋出訂閱的方式來通知資料更新。

3. Flux —- Fackbook 提出的管理 React 資料流的架構。Flux 不像一個框架，更是一種組織程式碼的推薦思想。就像 “引導資料流流向的導流管”。

4. 其他的 “導流管”。ReFlux，Redux 等。

前兩種形式其實也足夠在小應用中跑起來。但當專案越來越大的時候，管理資料的事件或回撥函式將越來越多，也將越來越不好管理了。 對於後兩種形式，個人經過對比後，可以看出 Redux 對 Flux 架構的一些簡化。如 Redux 限定一個應用中只能有單一的 store，這樣的限定能夠讓應用中資料結果集中化，提高可控性。當然，不僅如此。

Redux

Redux 主要分為三個部分 Action、Reducer、及 Store

Action

在 Redux 中，action 主要用來傳遞操作 State 的資訊，以 Javascript Plain Object 的形式存在，如

在上面的 Plain Object 中，type 屬性是必要的，除了 type 欄位外，action 物件的結構完全取決於你，建議儘可能簡單。type 一般用來表達處理 state 資料的方式。如上面的 'ADD_FILM' 表達要增加一個電影。而 name 表達了增加這個電影的電影名為 'Mission: Impossible'。那麼，當我們需要表達增加另一部電影時，就需要另外一個action，如

上面寫法沒有任何問題，但細想，當我們增加的電影越來越多的時候，那這種直接宣告的 Plain Object 將越來越多，不好組織。實際上，我們可以通過建立函式來生產 action，這類函式統稱為 Action Creator，如

這樣，通過呼叫 addFilm(name) 就可以得到對應的 Action，非常直接。

Reducer

有了 Action 來傳達需要操作的資訊，那麼就需要有根據這個資訊來做對應操作的方法，這就是 Reducer。 Reducer 一般為簡單的處理函式，通過傳入舊的 state 和指示操作的 action 來更新 state，如

上面程式碼展示了 Reducer 根據傳入的 action.type 來匹配 case 進行不同的 state 更新。

顯然，當專案中存在越來越多的 action.type 時，上面的 films 函式（ Reducer ）將變得越來越大，越來越多的 case 將導致程式碼不夠清晰。所以在程式碼組織上，通常會將 Reducer 拆分成一個個小的 reducer，每個 reducer 分別處理 state 中的一部分資料，最終將處理後的資料合併成為整個 state。

在上面的程式碼中，我們可以把 'ADD_FILM' 和 'DELETE_FILM' 歸為操作 state.films 的類，而 'SHOW_ALL_FILM' 為過濾顯示類，所以可以把大的 film Reducer 拆分成 filmReducer 和 filterReducer，如

1 filmReducer