這篇文章要求你熟悉React，甚至一定程度上了解了Redux的基本用法

　　這篇文章主要幫你解決Redux的概念問題

　　編程界有一句名言：

　　如果你無法理解一個東西(某種技術方案)，那說明你暫時還不需要它。——魯迅說不是他說的

　　我接下來會嘗試從這個角度來試著把它講清楚。

　　redux機制構成的這種邏輯關系，在現(xiàn)實中，很難有恰當?shù)膶?/p>

　　所以，目前為止，我們很難從非計算機的角度來解釋

　　如果將來找到了合適的例子，再來補充說明。

　　現(xiàn)在幾乎所有的軟件都帶點社交功能，那我們就以聊天來舉例吧

　　想象一下，你現(xiàn)在做了一個應用，其中帶有聊天功能。

　　那么你必然會在全局封裝一個socket鏈接，確保實時通信。

　　看起來就像下面這樣：

　　當有新的消息達到時，socket要負責通知導航組件改變狀態(tài)

　　也就是出現(xiàn)小紅點，做消息提示。

　　一開始你可能覺得這沒什么

　　但隨著細節(jié)功能的完善，邏輯開始慢慢變得復雜了起來

　　你增加了消息彈出提醒功能，如下圖：

　　當你點擊了已讀按鈕，剛剛被通知有新消息的導航組件

　　又被通知消息已讀，要再次改變狀態(tài)，去掉小紅點。

　　邏輯開始有點復雜了，但這才剛剛開始

　　接下來，我們點擊底部導航，進入聊天頁面

　　此時，如果有新的消息到來

　　socket除了通知底部導航，還得通知聯(lián)系人列表組件

　　當然這還不夠，我們繼續(xù)完善細節(jié)功能

　　點擊聯(lián)系人，進入與該聯(lián)系人的對話頁面，如下圖

　　在上圖當中，你要給人發(fā)送消息，除了通過socket把消息發(fā)送出去

　　還需要再次通知聊天列表組件，新增了一條對話

　　這時如果又來了一條新的消息，將會變成下面這樣：

　　我相信不用往下再舉例了，你應該已經(jīng)發(fā)現(xiàn)了，邏輯關系有點復雜對么?

　　造成這種復雜的局面，主要原因，就是職責分配太不明確了。

　　各個模塊之間的通信比較混亂。

　　首先，socket管的事兒是不是有點太多了? 本來，只負責收發(fā)消息，現(xiàn)在還得負責把消息傳遞給特定的組件。 這就是我們通常講的，耦合性太強了。

　　另外，組件和組件之間也要通信， 而且通信的組件是互相獨立的，沒有關系，也找不到共同的父組件。這個時候，你應該特別希望出現(xiàn)一個全局的協(xié)調中心，來負責各個組件的通信問題。

　　于是我們嘗試這樣改造一下：

　　那么誰來做這個全局的智能數(shù)據(jù)倉庫呢?

　　根組件? storage? 顯然都不好

　　這個時候，即便拿大腿想一下，也應該知道，就是redux啦

　　如果你能看出來這個是一個典型的觀察者模式，那就再好不過了

　　不知道也沒關系，總之呢，我們現(xiàn)在解決了各個組件之間混亂的通信模式

　　全部改為跟store進行打交道。

　　好了，解決了這個大問題之后，再來簡單說一說， reducer和 action

　　先看一眼下面的圖

　　action是我們向store發(fā)出的指令，reducer是我們修改state數(shù)據(jù)的方法。根據(jù)發(fā)出的指令，調用相應的reducer方法修改state，僅此而已。

　　Action本質是就是個對象， 包含你要執(zhí)行的動作名稱，以及要提交的數(shù)據(jù)等

　　我們把action發(fā)送給store，例如你發(fā)送了這樣一個Action對象

　　{

　　"type": "有新消息",

　　"data": {

　　"message":"啥時候還錢呢?"

　　}

　　}

　　然后編寫reducer函數(shù)，它最終交給Store進行管理。也就是我們只負責發(fā)送action指令，reducer自動被觸發(fā)。

　　編寫代碼就像下面這樣：

　　function myreducer1(state, action) {

　　switch(action.type){

　　case "有新消息": {

　　//........

　　return {...state} //這里沒有直接修改state，而是返回了新的對象

　　}

　　case "消息已讀": {

　　//........

　　return {...state} //這里沒有直接修改state，而是返回了新的對象

　　}

　　default : return state;//如果action類型不能識別，不做操作，直接返回

　　}

　　}

　　當你發(fā)送一個action給store的時候， 理論上所有的reducer將會被觸發(fā)， reducer將會執(zhí)行它的動作，操作修改state，然后要組裝一個新的state對象并返回(為什么要返回新的?這是官方要求，否則將無法通知其他組件更新)

　　然后redux去通知所有訂閱了的關聯(lián)組件進行更新。

　　關于為什么reducer叫做reducer? 這可能是最讓人難以理解的地方。

　　因為這完全是一種設計上的概念，你的代碼并不一定要這樣設計：

　　根據(jù)上圖所示， combineReducers作為一個總的reducer，調用其他reducer，并交由store管理。 也就是說，Action發(fā)過來的時候，Store會觸發(fā)這個combineReducers。

　　然后，你的每個子reducer只負責處理一部分數(shù)據(jù)，總的reducer來負責調用它們，每個子reducer處理的部分數(shù)據(jù)最終合并起來，返回完整的state。

　　reduce譯為 降低、合并的含義，reduce通常也叫作聚合或歸并操作。

　　簡單的說，當你把一個東西分而治之，但最終要把分別處理的結果，合并到一起作為整體呈現(xiàn)。那每一部分的處理器，就可以叫做一個reducer。

　　代碼部分不再貼了，官方給的例子挺清楚的。

　　至此，你應該大概理解了redux的概念