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

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

　　編程界有一句名言：

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

　　我接下來會(huì)嘗試從這個(gè)角度來試著把它講清楚。

　　redux機(jī)制構(gòu)成的這種邏輯關(guān)系，在現(xiàn)實(shí)中，很難有恰當(dāng)?shù)膶?duì)應(yīng)

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

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

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

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

　　那么你必然會(huì)在全局封裝一個(gè)socket鏈接，確保實(shí)時(shí)通信。

　　看起來就像下面這樣：

　　當(dāng)有新的消息達(dá)到時(shí)，socket要負(fù)責(zé)通知導(dǎo)航組件改變狀態(tài)

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

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

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

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

　　當(dāng)你點(diǎn)擊了已讀按鈕，剛剛被通知有新消息的導(dǎo)航組件

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

　　邏輯開始有點(diǎn)復(fù)雜了，但這才剛剛開始

　　接下來，我們點(diǎn)擊底部導(dǎo)航，進(jìn)入聊天頁面

　　此時(shí)，如果有新的消息到來

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

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

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

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

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

　　這時(shí)如果又來了一條新的消息，將會(huì)變成下面這樣：

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

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

　　各個(gè)模塊之間的通信比較混亂。

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

　　另外，組件和組件之間也要通信， 而且通信的組件是互相獨(dú)立的，沒有關(guān)系，也找不到共同的父組件。這個(gè)時(shí)候，你應(yīng)該特別希望出現(xiàn)一個(gè)全局的協(xié)調(diào)中心，來負(fù)責(zé)各個(gè)組件的通信問題。

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

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

　　根組件? storage? 顯然都不好

　　這個(gè)時(shí)候，即便拿大腿想一下，也應(yīng)該知道，就是redux啦

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

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

　　全部改為跟store進(jìn)行打交道。

　　好了，解決了這個(gè)大問題之后，再來簡(jiǎn)單說一說， reducer和 action

　　先看一眼下面的圖

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

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

　　我們把a(bǔ)ction發(fā)送給store，例如你發(fā)送了這樣一個(gè)Action對(duì)象

　　{

　　"type": "有新消息",

　　"data": {

　　"message":"啥時(shí)候還錢呢?"

　　}

　　}

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

　　編寫代碼就像下面這樣：

　　function myreducer1(state, action) {

　　switch(action.type){

　　case "有新消息": {

　　//........

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

　　}

　　case "消息已讀": {

　　//........

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

　　}

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

　　}

　　}

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

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

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

　　因?yàn)檫@完全是一種設(shè)計(jì)上的概念，你的代碼并不一定要這樣設(shè)計(jì)：

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

　　然后，你的每個(gè)子reducer只負(fù)責(zé)處理一部分?jǐn)?shù)據(jù)，總的reducer來負(fù)責(zé)調(diào)用它們，每個(gè)子reducer處理的部分?jǐn)?shù)據(jù)最終合并起來，返回完整的state。

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

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

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

　　至此，你應(yīng)該大概理解了redux的概念