摘要：正如我們前面的教程所提到的，在組件之間流通數據更確切的說，這被叫做單向數據流數據沿著一個方向從父組件流到子組件。這就是如何使數據流變得更簡單的原因。它是一種傾向單向數據流比如的設計模式。這是因為總是接受和返回狀態用來更新。

近期接觸React項目，學到許多新知識點，網上教程甚多，但大多都把知識點分開來講，初學者容易陷入學習的誤區，摸不著頭腦，本人在學習中也遇到許多坑。此篇文章是筆者看過的寫得比較詳細的具體的，同時能把所有的知識點統一串聯起來，非常適合初學者學習。由于文檔是英文版，考慮到大伙英語水平各不相同，故做此次翻譯，一來深化自己對Redux的體系認知，二來方便大家理解閱讀。

由于文中出現大量技術名詞，應適當結合原文進行閱讀，原文連接:
《Leveling Up with React: Redux》 By Brad Westfall On March 28, 2016

此篇教程是原文作者一系列教程的最后一篇，這里只對該篇進行翻譯，剩余的幾篇有時間會繼續進行翻譯，對于文中出現的翻譯錯誤，歡迎大家積極指正。

本教程是 Brad Westfall 三部分系列教程的最后一篇。我們將學習如何有效地管理狀態，使其跨越整個應用程序，并且可以在沒有嚴重復雜度的情況下進行衡量。在React的學習道路上我們已經走了這么遠，現在是時候來跨過終點，獲得這個物超所值的全部成長歷程。

第一部分：React Router

第二部分：Container Components

第三部分：Redux（你在這里）

Redux 是一個用來管理JavaScript應用中 data-state(數據狀態)和UI-state(UI狀態)的工具，對于那些隨著時間推移狀態管理變得越來越復雜的單頁面應用（SPAs）它是比較理想的，同時，它又是和框架無關的，因此，盡管它是提供給React使用的，但它也可以結合Angular 或者 jQuery來使用。

另外，它的設想來自一個叫做“時間旅行”的實驗，這是真實的，我們后面會講到。

正如我們前面的教程所提到的，React 在組件之間流通數據.更確切的說，這被叫做“單向數據流”——數據沿著一個方向從父組件流到子組件。由于這個特性，對于沒有父子關系的兩個組件之間的數據交流就變得不是那么顯而易見。

React 不推薦組件對組件直接交流的這種方式，盡管它確實有一些特征可以支持這個方法，但在許多組件之間進行直接的組件對組件的交流被認為是不好的做法，因為這樣會容易出錯，并且導致spaghetti code —— 過時的代碼, 很難維護。

React 提供了一個建議，但是他們希望你能自己來實現它。這里是React官方文檔里的一段話：

想讓兩個沒有父子關系的組件進行交流，你可以通過設置你自己的全局事件機制…… Flux 模式就是其中一個可行的方案

這里 Redux 就排上用場了。Redux提供了一個解決方案，通過將應用程序所有的狀態都存儲在一個地方，叫做“store”。然后組件就可以“dispatch”狀態的改變給這個store，而不是直接跟另外的組件交流。所有的組件都應該意識到狀態的改變可以“subscribe”給store。

可以把store想象成是應用程序中所有狀態改變的中介。隨著Redux的介入，所有的組件不再相互直接交流，而是所有的狀態改變必須通過store這個單一的真實來源。

這和那些應用程序中不同的部分直接交流的策略有很大的不同。有時，那些策略被認為是容易出錯和混亂的原因：

有了Redux，所有的組件都從store中來獲取他們的狀態，變得非常清晰。同樣，組件狀態的改變都發送給了store，也很清晰。組件初始化狀態的改變只需要關心如何派發給store，而不用去關心一系列其它的組件是否需要狀態的改變。這就是Redux如何使數據流變得更簡單的原因。

使用store來協調應用之間狀態改變的概念就是Flux模式。它是一種傾向單向數據流（比如 React）的設計模式。Redux像Flux，但是他們又有多少關系呢？

Flux 是一種模式，不像Redux那樣是可以下載的工具，Redux 是受Flux模式，此外，它比較像Elm。這里有許多有關于Redux和Flux之間比較的指南。它們中的大多數都會得出Redux就是Flux，或者Redux和Flux比較類似的結論，這取決于給Flux定義的規則到底有多嚴格。然而說到底，這些都無關緊要。Facebook 非常喜歡并且支持Redux，這從它們雇傭了Redux的主要開發者 Dan Abramov 就可以看出。

這篇文章假設你一點都不熟悉Flux的設計模式。不過如果你熟悉，你會注意到許多微小的不同，尤其考慮到Redux的三大指導原則：

Redux只使用一個store來處理應用的狀態。因為所有的狀態都駐留在同一個地方，Redux稱這個為單一真實源。

store中數據的結構完全取決于你，但通常都是針對應用的一個深層嵌套的對象。

Redux的單一store方法是區分Flux多個store方法的最主要區別。

Redux的文檔指出，唯一改變狀態的方法就是發出一個action，一個用來描述發生了什么的對象。

這意味著應用不能直接改變狀態，相反，“actions” 被派發給store，用來描述一個改變狀態的意圖。

store對象自己有幾個小型的API，對應4個方法：

store.dispatch(action)

store.subscribe(listener)

store.getState()

replaceReducer(nextReducer)

所以你可以看到，這里沒有設置狀態的方法。因此，派發一個action是處理應用狀態更改的唯一辦法。

var action = {
  type: "ADD_USER",
  user: {name: "Dan"}
};

// Assuming a store object has been created already
store.dispatch(action);

dispatch() 方法發送了一個對象給Redux，這個對象就被叫做action。這個action可以被描述成一個攜帶了一個 type 屬性以及其它可以被用來更新狀態的數據（在這個例子里就是user）的有效負載。記住，在 type 屬性之后，這個action對象的設計完全取決于你。

就像剛才所描述的，Redux不允許應用直接改變狀態，而是用被分派的action來“描述”狀態改變或者改變狀態的意圖。而一個個Reducer就是你自己寫的函數，用來處理分派的action，事實上是它真正改變了狀態。

一個reducer接受當前的狀態（state）作為參數，而且必須返回一個新的狀態才能改變之前的狀態。

// Reducer Function
var someReducer = function(state, action) {
  ...
  return state;
}

reducer 必須使用 “純”函數 ， 一個可以用以下這些特征來描述的術語：

沒有任何的網絡或數據庫請求操作

返回的值僅依賴于參數

參數必須是“不可改變的”，以為著它們將不能被更改。

調用具有相同參數集的純函數將始終返回相同的值

它們被稱為“純”函數是因為它們什么都不做僅僅返回一個基于參數的值。它們在系統的任何其他部分都沒有副作用。

開始之前，需要先用 Redux.createStore() 創建一個store，然后將所有的reducer作為參數傳遞進去，讓我們看一下這個只傳遞了一個reducer的小例子：

// Note that using .push() in this way isn"t the
// best approach. It"s just the easiest to show
// for this example. We"ll explain why in the next section.

// The Reducer Function
var userReducer = function(state, action) {
  if (state === undefined) {
    state = [];
  }
  if (action.type === "ADD_USER") {
    state.push(action.user);
  }
  return state;
}

// Create a store by passing in the reducer
var store = Redux.createStore(userReducer);

// Dispatch our first action to express an intent to change the state
store.dispatch({
  type: "ADD_USER",
  user: {name: "Dan"}
});

上面的程序干了些什么呢：

這個store只由一個reducer創建。

這個reducer 初始化狀態的時候使用了一個空數組 。*

在被分派的這個action里面使用了新的user對象。

這個reducer將這個新的user對象附加到state上，并將它返回，用來更新store。

*在這個例子里reducer實際上被調用了兩次 —— 一次是在創建store的時候，一次是在分派action之后。

當store被創建之后，Redux立即調用了所有的reducer，并且將它們的返回值作為初始狀態。第一次調用reducer傳遞了一個 undefined 給state。經過reducer內部的代碼處理之后返回了一個空數組給這個store的state作為開始。

所有的reducer在每次action被分派之后都會被調用。因為reducer返回的狀態將會成為新的狀態存儲在store中，所以 Redux總是希望所有的reducer都要返回一個狀態。

在這個例子中，reducer第二次的調用發生在分派之后。記住，一個被分派的action描述了一個改變狀態的意圖，而且通常攜帶有數據用來更新狀態。這一次，Redux將當前的狀態（仍舊是空數組）和action對象一起傳遞給了reducer。這個action對象，現在有了一個值為‘ADD_USER’的type屬性, 讓reducer知道怎樣改變狀態。

我們很容易就能將reducers和漏斗聯想起來，允許狀態通過他們。這是因為reducers總是接受和返回狀態用來更新store。

基于這個例子，我們的store將會變成一個只有一個user對象的數組：

store.getState();   // => [{name: "Dan"}]

在我們上面的例子中這個reducer從技術上來講是可行的，但是它改變了狀態，這是一種不好的做法。盡管reducers 負責改變狀態，但是不應該直接改變“現有的狀態”。所以我們不應該在reducer的state這個參數上使用.push()這個變異的方法。

傳遞給reducer的參數應該被視為不可改變的。換句話說，他們不應該被直接改變。我們可以使用不變異的方法比如.concat()來拷貝這個數組，然后我們將拷貝的數組返回。

var userReducer = function(state = [], action) {
  if (action.type === "ADD_USER") {
    var newState = state.concat([action.user]);
    return newState;
  }
  return state;
}

在這個新的reducer中，我們添加了一個新的user對象作為state參數的副本被改變和返回。當沒有添加新的用戶的時候，注意返回的是原始的state而不是它的拷貝。

有一大節關于不可變數據結構的最佳嘗試，我們應該更多的去了解

你也許已經注意到初始化參數使用了ES2015的默認參數方法。到目前為止，在這一些列的文章中，我們一直避免使用ES2015來使你更專心于主題內容。然而，Redux和ES2015結合使用會變得非常完美。因此，我們最終開始在這篇文章中使用ES2015。然而不用擔心，每次采用新的ES2015的特性，我們都會指出來并且解釋

上一個例子是一個很好的入門，但是大多數的應用都需要更復雜的state來滿足整個應用。因為Redux僅使用一個store，所以我們需要使用嵌套的對象來組織不同模塊的state。假設我們的想要我們的store類似于這種樣子：

{
  userState: { ... },
  widgetState: { ... }
}

整個應用對應的還是 “一個store = 一個對象”，但是它嵌套了 userState 和 widgetState 對象，可以包含各種數據。這似乎過于簡單了，但是實際上和一個真實的Redux store沒多少差別。

為了創建具有嵌套對象的store，我們需要定義每一塊的reducer：

import { createStore, combineReducers } from "redux";

// The User Reducer
const userReducer = function(state = {}, action) {
  return state;
}

// The Widget Reducer
const widgetReducer = function(state = {}, action) {
  return state;
}

// Combine Reducers
const reducers = combineReducers({
  userState: userReducer,
  widgetState: widgetReducer
});

const store = createStore(reducers);

ES2015 提示! 在這個例子中四個主要的變量都不會被改變, 所以我們將它們定義成常量. 同時我們也使用了ES2015 modules and destructuring

combineReducers()允許我們用不同的邏輯塊來描述store，將reducer分配給每一個塊。現在，每一個reducer返回的初始狀態會進入到它們store中各自對應的userState或者widgState塊。

有些非常重要的點需要注意，現在每一個reducer中所傳遞的只是全部狀態中各自的部分，不再像之前只有一個reducer時傳遞的是整個store的狀態。然后每個reducer返回的狀態應用于它們各自的部分。

當我們考慮每次action被分派的時候，把上面全部的reducer想想成一個個漏斗會變得更加明了，所有的reducer都會被調用，都將有機會來更新各自的狀態：

我很小心地說“它們的”狀態是因為reducer的“當前狀態”參數和它的返回“更新”狀態僅僅影響到store中reducer里面的部分。記住，像前面所說的，每一個reducer只獲得它們各自的狀態，而不是整個狀態。

實際上有大量的關于創建和管理action及其類型的策略。雖然它們都很棒，但是它們不像本文中的其他一些信息那樣重要。為了減少文章的篇幅，我們整理了這些基本的action策略，你可以在 GitHub repo上獲得這一系列的策略。

state的樣式由你自己決定: 它可以是原始值，數組，對象，或者一個Immutable.js的數據結構。 唯一重要的部分就是你不能改變state對象，而且需要返回一個更改后的新對象 -- Redux 文檔

上面的陳訴說了很多，我們已經在本教程中提到了這一點。如果我們開始討論什么是可變的什么是不可變的的來龍去脈和利弊，我們可以在 《blog article"s worth of information》找到更有價值的信息。所以事實上，我只是想突出一些要點。

開始前:

JavaScript的原始數據類型(Number, String, Boolean, Undefined, and Null) 已經是不可變得了。

對象、數組、函數是可變的。

有人說數據結構的可變性容易產生問題。因為我們的store是有state對象和數組所組成，我們需要實施一種策略來保持狀態不可變。

讓我們假設需要改變一個state對象的屬性，這里有三種方式：

// Example One
state.foo = "123";

// Example Two
Object.assign(state, { foo: 123 });

// Example Three
var newState = Object.assign({}, state, { foo: 123 });

第一個和第二個例子都改變了state對象。第二個例子是因為Object.assign()把所有的參數都合并到了第一個參數里。但這也就是為什么第三個例子沒有改變state對象的原因。

第三個例子將state的內容和{foo: 123}合并到了一個新的空對象中。這是一種常見的技巧，允許我們創建一個state對象的副本，在副本上進行修改，本質上不會影響原始的state。

對象的“擴展運算符”是保持state不可變的另一種方式:

const newState = { ...state, foo: 123 };

有關于上述代碼究竟發生了什么，為什么它對Redux是友好的詳細解釋，可以參考這個主題的文檔

Object.assign() 和擴展運算符都是ES2015的特性。

總結來說，有許多方法可以明確地保持對象和數組不可變。許多開發者使用第三方庫比如 seamless-immutable、Mori 甚至Facebook自己的Immutable.js 來達到這個目的。

我非常小心的選擇了一些相關的博客和教程。如果你不是非常明白不變性，可以看一下上面給出的這些鏈接。這在Redux的學習中是一個非常重要的概念。

如果你讀過文檔，你也許會注意到createStore()這個方法里的第二個參數是用來“初始化狀態”的，這也許是對reducer創建初始化狀態方式的一種替代。然而，這個初始化的狀態只會被用來“state hydration”。

想象一下一個用戶刷新了你的單頁面應用，store中的狀態被重置為reducer中的初始狀態，這樣可能是不理想的。

相反，想象一個你可以使用一種策略來保持store，然后在刷新的時候重新將它化合到Redux中。這就是傳送一個初始化狀態到createStore()中的原因。

這帶來了一個有趣的概念，如果重新化合老的狀態變得這么容易，我們可以將app中的狀態想象成是時間旅行。這可以被用來進行調試或者撤銷/重做某些特性。所以將所有的狀態存儲在一個store中變得很有意義。這就是為什么不可變的狀態能夠幫助我們的其中一個原因。

在一次面談中，Dan Abramov 被問到“為什么你要開發Redux？”

我并不是有意要創建Flux框架。當React第一次被宣布的時候，我提議來談一談‘熱加載和時間旅行’，但是老實說，我自己也不知道該怎么實施時間旅行

就像我們已經討論過的，Redux與框架無關。在我們開始考慮Redux跟React怎么結合之前，明白Redux的核心概念是非常重要的。但是現在我們已經準備好從上一篇文章中拿一個容器組件，然后將Redux應用在它上面了。

首先，這是沒有使用Redux的原始組件代碼：

import React from "react";
import axios from "axios";
import UserList from "../views/list-user";

const UserListContainer = React.createClass({
  getInitialState: function() {
    return {
      users: []
    };
  },

  componentDidMount: function() {
    axios.get("/path/to/user-api").then(response => {
      this.setState({users: response.data});
    });
  },

  render: function() {
    return ;
  }
});

export default UserListContainer;

ES2015 說明！這個例子已經在原始代碼的基礎上做了部分轉換，使用了ES2015的模塊功能和箭頭函數。

它所做的就是發送一個Ajax請求，然后更新它的本地狀態。但是，如果該應用的其它區域也要根據這個新獲取到的用戶列表進行改變呢，這個策略是不夠的。

有了Redux策略，我們可以在Ajax請求的時候分派一個action而不是進行 this.setState()，然后這個組件和其它組件可以訂閱狀態的改變。但是事實上這帶給我們一個問題，我們應該怎么設置store.subscribe()來更新組件的狀態呢？

我想我可以提供幾個例子來手動的連接一些組件到Redux store。你也可以想象一下用你的方法會怎么做。但是最終，在這些例子的最后我會解釋有一個更好的辦法，然后忘掉這些手動的例子。然后我會介紹官方的連接React和Redux的模塊，叫做react-redux，所以還是直接跳到那一步吧。

為了說明白，react，redux和react-redux是npm上三個獨立的模塊。其中，react-redux模塊允許我們以更方便的方式“connect” React組件和Redux

下面給出例子：

import React from "react";
import { connect } from "react-redux";
import store from "../path/to/store";
import axios from "axios";
import UserList from "../views/list-user";

const UserListContainer = React.createClass({
  componentDidMount: function() {
    axios.get("/path/to/user-api").then(response => {
      store.dispatch({
        type: "USER_LIST_SUCCESS",
        users: response.data
      });
    });
  },

  render: function() {
    return ;
  }
});

const mapStateToProps = function(store) {
  return {
    users: store.userState.users
  };
}

export default connect(mapStateToProps)(UserListContainer);

這里面有許多的新東西:

1、我們從 react-redux 中引入了 connect 函數。
2、這段代碼可能從最底下的連接操作開始往上看會更容易理解。connect()方法實際上接收兩個參數，但是我們這里只顯示了一個 mapStateToProps()

connect()() 多了一個括號看起來好像很奇怪，實際上這是兩個函數的調用。首先，connect()返回了另外一個函數，我想我們可以把這個函數賦值給一個變量名，然后調用它，但是既然在后面多加一個括號就可以直接調用這個函數，我們為什么還要給它設置一個函數名呢？而且，在這個函數調用結束之后，我們根本不需要這個額外的函數名。這第二個函數需要你傳遞一個React組件。在這個例子中，傳遞的是我們的容器組件。我敢打賭你肯定正在思考“為什么要把它變得這么復雜？”，然而，這實際上是一種常見的“函數式編程”范式，所以，學習如何使用它是非常有好處的。

3、connect()第一個參數是需要返回一個對象的函數。這個對象的屬性會成為這個組件的“props”。你可以看到它們的狀態值。現在，我希望“mapStateToProps”變得更有意義。同時，我們也看到mapStateToProps()這個函數接收了一個參數，這個參數就是整個Redux的store。mapStateToProps()函數的主體思想就是將這個組件需要用到的部分狀態從全部狀態中隔離出來作為它的props屬性。

4、根據第3點中所說的，我們將不再需要getInitialState()的存在。同時，我們也看到，自從users這個數組變成了props屬性而不是本地組件狀態之后，我們參考使用this.props.users而不是this.state.users。

5、Ajax的返回現在變成了一個action的分派，而不是本地狀態的更新。為了更簡單明了的展示，我們沒有使用action構造器和action type常量

下面的代碼提供了一種在用戶自定義的reducer沒有出現的時候也可以工作的假設。注意store的userState屬性，但是這個名字是哪里來的呢？

const mapStateToProps = function(store) {
  return {
    users: store.userState.users
  };
}

這個名字來自我們合并所有的reducer的時候：

const reducers = combineReducers({
  userState: userReducer,
  widgetState: widgetReducer
});

userState的.users屬性又是什么？它又來自哪里？

在這個例子中，我們并沒有展示一個實際的reducer（因為它會出現在另一個文件中），reducer決定了它所負責狀態的子屬性。為了確保.users是userState的一個屬性，上述例子對應的reducer可能看起來是這樣的：

const initialUserState = {
  users: []
}

const userReducer = function(state = initialUserState, action) {
  switch(action.type) {
  case "USER_LIST_SUCCESS":
    return Object.assign({}, state, { users: action.users });
  }
  return state;
}

在我們Ajax的例子中，我們僅僅分派了一個action。它被特意叫做“USER_LIST_SUCCESS”，因為我們同時也希望在Ajax調用開始的時候分派一個“USER_LIST_REQUEST”的action，在Ajax調用失敗的時候分派一個“USER_LIST_FAILED”的action。請確保讀取異步操作的文檔

在之前的文章中，我們看到事件應該通過容器組件傳遞到表現組件。原來 react-redux同時也可以處理這個，一個事件只需要分派一個action:

...

const mapDispatchToProps = function(dispatch, ownProps) {
  return {
    toggleActive: function() {
      dispatch({ ... });
    }
  }
}

export default connect(
  mapStateToProps,
  mapDispatchToProps
)(UserListContainer);

在表現組件中，就像我們之前做過的，可以通過onClick={this.props.toggleActive}來調用事件，不需要再編寫事件本身。

有時，一個容器組件只需要訂閱store，不需要任何像componentDidMount()這樣的方法來開始Ajax 請求。它只需要一個render()方法傳遞給表現組件。在這個例子中，我們可以像這樣構造容器組件：

import React from "react";
import { connect } from "react-redux";
import UserList from "../views/list-user";

const mapStateToProps = function(store) {
  return {
    users: store.userState.users
  };
}

export default connect(mapStateToProps)(UserList);

是的，父老鄉親們，這就是新的容器組件的整個文件。但是等一下，容器組件在哪里？為什么我們在這里沒有用到任何的React.createClass()？

事實證明，connect()方法為我們構造了一個容器組件。注意到這一次我們直接傳遞的是一個表現組件，而不是我們自己創建的容器組件。如果你真的在想容器組件干了什么，記住，它們的存在是為了表現組件專心于視圖，而不是狀態。它們也傳遞狀態給子視圖作為props。而這就是connect()實際所做的，它傳遞了狀態（作為props）給我們的表現組件，然后返回一個React組件來包裹這個表現組件。從本質上來說，這個包裹，就是容器組件。

所以是不是意味著上面的例子中其實有兩個容器組件包裹著一個表現組件？當然，你可以這樣子認為。但這并沒有什么問題，只有當我們的容器組件需要除了render()方法之外的其它方法的時候它才是必須的。

想象這兩個容器組件是具有不同但是相關服務的角色：

嗯，也許這就是為什么React的logo看起來這么像原子的原因吧

為了保證任何react-redux的代碼能正常工作，你需要使用一個組件來讓你的應用知道怎樣使用react-redux。這個組件包裹了你的整個React應用。如果你正在使用 React Router，它看起來也許是這樣的：

import React from "react";
import ReactDOM from "react-dom";
import { Provider } from "react-redux";
import store from "./store";
import router from "./router";

ReactDOM.render(
  {router},
  document.getElementById("root")
);

通過react-redux真正“連接”React和Redux的東西是附加給Provider的store，這里有個例子，關于主要入口點大概是怎么樣

這個不做要求，但是有另一個npm項目叫做 react-router-redux ，因為從技術上來說，路由是UI-state的一部分，而且React Router不認識Redux，所以這個項目幫助我們連接這兩個東西。

你看到我做了什么嗎？我們走了一圈，又回到了第一篇文章！

遵照這一系列教程，最終你可以實現一個叫做“用戶控件”的單頁面應用。

與本系列其他文章一樣，每個都有相關指導文檔，在Github上也都有相關代碼指導你怎么做。

我真的希望你能喜歡我寫的這一系列文章，我意識到有許多關于React的主題我們都沒有覆蓋到，但我試圖在保持真實的前提下，給新用戶一種跨越React基礎知識的認知，以及制作一個單頁面應用所帶來的感受。

第一部分：React Router

第二部分：Container Components

第三部分：Redux（你在這里）

翻譯文獻：Leveling Up with React: Redux By Brad Westfall On March 28, 2016

翻譯作者：coocier