Redux是一個可預測的狀態容器，提供可預測的狀態管理。 什麼是狀態？狀態其實也就是數據，管理狀態也就是對數據的管理。那麼什麼是可預測的狀態管理呢？能夠監聽數據的變化，獲取變化的來源，在發生變化時可以觸發某些動作，即為狀態管理（個人理解）。 如上所示，就是一個最簡單的狀態管理，實現了數據基本的管理， ...
Redux是一個可預測的狀態容器，提供可預測的狀態管理。
什麼是狀態？狀態其實也就是數據，管理狀態也就是對數據的管理。那麼什麼是可預測的狀態管理呢？能夠監聽數據的變化，獲取變化的來源，在發生變化時可以觸發某些動作，即為狀態管理（個人理解）。
如上所示，就是一個最簡單的狀態管理，實現了數據基本的管理，但是，並未實現監聽數據的變化。因此，此處採用訂閱者模式，實現數據變化的監聽：
代碼很簡單，訂閱事件&觸發事件，實現了監聽data狀態的變化。以上其實就是Redux的核心內容。項目放在github上，歡迎star
問題1
通過changeState方法可以隨意更改state，不受控制。
Redux是“可預測的狀態管理器”，因此能夠引起狀態變化的，必須是在我們可預測的範圍內。也就是說，如果引起狀態的變化不在我們定義好的變化之內，則拒絕處理該變化，Redux是如何做到這一點的呢？talk is cheap, show me the code:
原來如此！通過敢敢單單的switch case語句即可實現。（至於這個方法為什麼叫reducer，後面再解釋）
原本的createStore里的changeState方法也需要配合改動(方法名字改成dispatch，意為“派發”動作，更符合其功能)：
觸發動作時，則需要用以下這種形式：
動作發起者： 洞么洞么，我是type為“CHANGE_NAME”的動作
處理動作者：收到，已處理完畢，並返回給你變化後的狀態，over
動作發起者： 洞堯洞堯，我是type為“cxk”的動作
處理動作者： 非法類型的動作，拒絕處理，返回初始狀態，over
問題2
當store里的數據比較多時，用同一個reducer處理，必然會導致函數很臃腫：
最簡單的解決方法，就是按照功能模塊對reducer進行拆分：
那麼接下來要做的就是，如何把多個reducer組合起來，並最終返回變化後的state。首先將多個reducer按照模塊的形式組合在一起：
然後編寫一個combineReducer方法，當每次dispatch了action，會依次觸發所有reducer，並最終返回變化後的state：
這裡可以解釋為什麼叫reducer了，從上述代碼中可以看出，每個reducer其實是（prev， action） => newState這樣的一個結構，類似於Array.prototype.reduce的結構，因此稱之為reducer。
問題3
想必也能猜到問題3是什麼了，上文將reducer按照模塊拆分了，但是state本身還沒有拆分，如果state過於龐雜，也是不好滴。話不多說，拆：
同時，在createStore里新增一句代碼，用於初始化整個state：
因為type不為任何值，因此所有的reducer都會按照default返回初始值，這樣就完成了state的初始化,並且在createStore時，也不用再傳入initalState了。
middleware（中間件）
國際慣例，什麼是middleware？
它提供的是位於action被髮起之後，到達reducer之前的擴展點。你可以利用Redux middleware來進行日誌記錄、創建崩潰報告、調用非同步介面或者路由等等。
（網上找的）
說白了，middleware就是對dispatch的擴展，可以利用它實現定製化功能。
舉個慄子，我們要實現dispatch時，添加一個日誌記錄的功能，記錄一下action觸發前後的狀態以及是哪個action觸發的，那麼可以重寫dispatch方法：
假如說我們這時候又想添加一個創建崩潰報告的功能，那麼可以這樣重寫dispatch方法：
那麼問題來了，如果我們想要同時具有這兩個功能呢？機智的我一下子就想到了，把這倆寫到一起不就ok了？
真的是簡單到爆了。等等...好像有哪裡不對？如果以後想加入更多的功能呢？難道也要把他們都塞進這個新的dispatch方法裡面？很明顯，不行，那樣只會導致dispatch方法越來越臃腫，難以維護。根據我們多年的經驗，必然是又要進行拆分了。
從上面的loggerMiddleware和exceptionMiddleware的合作上，可以看出，多個中間件之間的調用順序應該是類似於
A = (action) => { B(action) }
這樣的一種鏈式結構。為了使middleware更為通用，應該將B作為參數傳遞進去，因此，可以寫出這種結構：
A = (B) => (action) => { B(action) }
這時候會發現，在任意一個中間件里，都有可能用到store，因此，將store作為頂級參數傳遞進去：
A = (store) => (B) => (action) => { B(action) }
代碼如下：
抽離公共方法
每次使用中間件時，都要寫一些重覆的代碼。因此Redux內部有一個方法，可以實現這種鏈式調用：
（簡單的示例，實際的方法比這個更為複雜）
方法實現的比較巧妙，每次將經過上一個中間件處理過的dispatch作為參數傳遞給下一個中間件，這樣就形成了鏈式調用：
store.dispatch = applyMiddleware(store, loggerMiddleware, exceptionMiddleware)
非同步action
在實際項目中，非同步是不可避免的。之前的代碼中，當我們每次dispatch一個action時，action只能是一個plain object(普通對象，這裡指的是直接繼承於Object的對象)，否則reducer無法成功解析(按照官方文檔的意思，action必須是“可序列化的”,這部分暫時不是很理解)。
和 state 一樣，可序列化的 action 使得若幹 Redux 的經典特性變得可能，比如時間旅行調試器、錄製和重放 action。若使用 Symbol 等去定義 type 值，或者用 instanceof 對 action 做自檢查都會破壞這些特性。字元串是可序列化的、自解釋型，所以是更好的選擇。
因為性能原因，我們無法強制序列化 action，所以 Redux 只會校驗 action 是否是普通對象，以及 type 是否定義。
然鵝在實際開發中，存在大量的非同步場景，例如最常見的請求調用。我們可以利用中間件，讓dispatch可以直接接收一個Function類型的action。Redux就提供了這樣一個中間件redux-thunk：
代碼其實也很簡單，判斷了一下action是否是函數，是的話則執行這個action。用這個中間件去增強dispatch的功能，就可以按照下麵這種形式寫非同步的action了：
調用時：
dispatch(getCardInfoAction())
tips：無論嵌套執行了多少個middleware，最終被dispatch的那個action，仍然必須是一個plain object，將處理流程變回同步方式。
當 middleware 鏈中的最後一個 middleware 開始 dispatch action 時，這個 action 必須是一個普通對象。這是 同步式的 Redux 數據流 開始的地方（譯註：這裡應該是指，你可以使用任意多非同步的 middleware 去做你想做的事情，但是需要使用普通對象作為最後一個被 dispatch 的 action ，來將處理流程帶回同步方式）。
小結
到這裡，redux的大部分功能其實已經基本實現了，剩餘的還有一些細節部分，例如將f1 => f2 => f3(action)這種鏈式調用變為f1(f2(f3(action)))這種調用形式的compose方法（用在applyMiddleware方法內部）；createStore方法添加有中間件/無中間件的處理；store.subscribe訂閱後的退訂以及各種判斷的處理等。
Redux的源碼短小精悍，使用純JavaScript實現，不依賴任何第三方庫，因此也適用於各種框架。其完整的流程圖：
參考：
