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

　　這篇文章主要幫你解決Redux的概念問(wèn)題

　　編程界有一句名言：

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

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

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

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

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

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

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

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

　　看起來(lái)就像下面這樣：

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

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

　　一開(kāi)始你可能覺(jué)得這沒(méi)什么

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　那么誰(shuí)來(lái)做這個(gè)全局的智能數(shù)據(jù)倉(cāng)庫(kù)呢?

　　根組件? storage? 顯然都不好

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

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

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

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

　　好了，解決了這個(gè)大問(wèn)題之后，再來(lái)簡(jiǎn)單說(shuō)一說(shuō)， 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í)候還錢呢?"

　　}

　　}

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

　　編寫(xiě)代碼就像下面這樣：

　　function myreducer1(state, action) {

　　switch(action.type){

　　case "有新消息": {

　　//........

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

　　}

　　case "消息已讀": {

　　//........

　　return {...state} //這里沒(méi)有直接修改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ì)象并返回(為什么要返回新的?這是官方要求，否則將無(wú)法通知其他組件更新)

　　然后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管理。 也就是說(shuō)，Action發(fā)過(guò)來(lái)的時(shí)候，Store會(huì)觸發(fā)這個(gè)combineReducers。

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

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

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

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

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