摘要：應(yīng)用這說(shuō)明并不是單指設(shè)計(jì)給用的，它是獨(dú)立的一個(gè)函數(shù)庫(kù)，可通用于各種應(yīng)用。在數(shù)據(jù)流的最后，要觸發(fā)最上層組件的，然后進(jìn)行整體的重新渲染工作。單純?cè)诘膶?duì)象上是沒(méi)有辦法使用，要靠額外的函數(shù)庫(kù)才能這樣作，這是一定要使用類似像這種函數(shù)庫(kù)的主要原因。

Redux的官網(wǎng)中用一句話來(lái)說(shuō)明Redux是什么:

Redux是針對(duì)JavaScript應(yīng)用的可預(yù)測(cè)狀態(tài)容器

這句話雖然簡(jiǎn)短，其實(shí)是有幾個(gè)涵義的:

可預(yù)測(cè)的(predictable): 因?yàn)镽edux用了reducer與純函數(shù)(pure function)的概念，每個(gè)新的state都會(huì)由舊的state建來(lái)一個(gè)全新的state，這樣可以作所謂的時(shí)光旅行調(diào)試。因此，所有的狀態(tài)修改都是"可預(yù)測(cè)的"。

狀態(tài)容器(state container): state是集中在單一個(gè)對(duì)象樹(shù)狀結(jié)構(gòu)下的單一store，store即是應(yīng)用程序領(lǐng)域(app domain)的狀態(tài)集合。

JavaScript應(yīng)用: 這說(shuō)明Redux并不是單指設(shè)計(jì)給React用的，它是獨(dú)立的一個(gè)函數(shù)庫(kù)，可通用于各種JavaScript應(yīng)用。

有些人可能會(huì)認(rèn)為Redux一開(kāi)始就是Facebook所創(chuàng)建的項(xiàng)目，其實(shí)不然，它主要是由Dan Abramov所開(kāi)始的一個(gè)項(xiàng)目，Dan Abramov進(jìn)入Facebook的React核心小組工作是最近的事情。在此之前，他還有創(chuàng)建另外還有其他相關(guān)項(xiàng)目，像React Hot Loader、React DnD，可能比當(dāng)時(shí)的Redux項(xiàng)目還更廣為人知，在Facebook發(fā)表Flux架構(gòu)不久之后，許多Flux架構(gòu)的類似函數(shù)庫(kù)/框架，不論是加強(qiáng)版、進(jìn)化版、大改版等等非常的多。Redux一開(kāi)始的對(duì)外演示的大型活動(dòng)，是在2015年的React-Europe研討會(huì)，視頻Live React: Hot Reloading with Time Travel。在視頻中就有一個(gè)簡(jiǎn)單的說(shuō)明，Redux用了"Flux + Elm"的概念。

Redux = Flux + Elm

當(dāng)然除了Flux與Elm之外，還有其他的主要像RxJS中的概念與設(shè)計(jì)方式，Redux融合了各家的技術(shù)于一身，除了更理想的使用在Flux要解決的問(wèn)題上之外，更延伸了一些不同的設(shè)計(jì)方式。但是對(duì)初學(xué)者來(lái)說(shuō)，它也不容易學(xué)習(xí)，網(wǎng)絡(luò)上常常見(jiàn)到初學(xué)者報(bào)怨Redux實(shí)在有夠難學(xué)，這也并不是完全是Redux的問(wèn)題，基本上來(lái)說(shuō)Flux的架構(gòu)原本就不是很容易理解，Redux還簡(jiǎn)化了Flux的流程與開(kāi)發(fā)方式。

所以我們要理解Redux是什么，我們開(kāi)始可以從這Flux與Elm兩大基礎(chǔ)來(lái)理解，以下分別說(shuō)明一些基本的概念。

不論是Flux或其他以Flux架構(gòu)為基礎(chǔ)延伸發(fā)展的函數(shù)庫(kù)(Alt、Reflux、Redux...)都是為了要解決同一個(gè)問(wèn)題，這個(gè)問(wèn)題在React應(yīng)用規(guī)模化時(shí)會(huì)非常明顯，簡(jiǎn)單以一句話來(lái)說(shuō)就是:

應(yīng)用程序領(lǐng)域(app domain)的狀態(tài) - 簡(jiǎn)稱為App state

應(yīng)用程序都需要有App state(應(yīng)用程序狀態(tài))，不論是在一個(gè)需要用戶登錄的應(yīng)用，要有全局的記錄著用戶登錄的狀態(tài)，或是在應(yīng)用程序中不同操作介面(組件)或各種功能上的數(shù)據(jù)溝通，都需要用到它。如果你已經(jīng)有一些程序語(yǔ)言或應(yīng)用的開(kāi)發(fā)經(jīng)驗(yàn)，你應(yīng)該知道這會(huì)像是MVC設(shè)計(jì)模式中的Model(模型)部份該作的事情。

React應(yīng)用為什么會(huì)出現(xiàn)這個(gè)問(wèn)題？原因主要是來(lái)自React組件的本身設(shè)計(jì)造成的。React被設(shè)計(jì)為一個(gè)相似于MVC架構(gòu)中的View(視圖)的函數(shù)庫(kù)，當(dāng)然實(shí)際上它可以作的事情比MVC中的View(視圖)還要更多，但本質(zhì)上的確React不是一個(gè)完整的應(yīng)用程序開(kāi)發(fā)框架，里面沒(méi)有額外的架構(gòu)可以作類似Model(模型)或Controller(控制器)的事情。對(duì)小型的組件或應(yīng)用而言，應(yīng)用的數(shù)據(jù)都包含在里面，也就是在View(視圖)之中。

有學(xué)過(guò)React的一些基礎(chǔ)的開(kāi)發(fā)者應(yīng)該會(huì)知道，在React中的組件是無(wú)法直接更動(dòng)state(狀態(tài))的包含值，要透過(guò)setState方法來(lái)進(jìn)行更動(dòng)，這有很大的原因是為了Virtual DOM(虛擬DOM)的所設(shè)計(jì)，這是其中一點(diǎn)。另外在組件的樹(shù)狀階層結(jié)構(gòu)，父組件(擁有者)與子組件(被擁有者)的關(guān)系上，子組件是只能由父組件以props(屬性)來(lái)傳遞屬性值，子組件自己本身無(wú)法更改自己的props，這也是為什么一開(kāi)始在學(xué)習(xí)React時(shí)，都會(huì)看到大部份的例子只有在最上層的組件有state，而且都是由它來(lái)負(fù)責(zé)進(jìn)行當(dāng)數(shù)據(jù)改變時(shí)的重新渲染工作，子組件通常只有負(fù)責(zé)呈現(xiàn)數(shù)據(jù)。

當(dāng)然，有一個(gè)很技巧性的方式，是把父組件中的方法聲明由props傳遞給子組件，然后在子組件觸發(fā)事件時(shí)，調(diào)用這個(gè)父組件的方法，以此來(lái)達(dá)到子組件對(duì)父組件的溝通，間接來(lái)更動(dòng)父組件中的state。不過(guò)這個(gè)作法并不直覺(jué)，需要事先規(guī)范好兩邊的方法。在簡(jiǎn)單的應(yīng)用程序中，這溝通方式還可行，但如果是在有復(fù)雜的組件嵌套階層結(jié)構(gòu)時(shí)，例如層級(jí)很多或是不同樹(shù)狀結(jié)構(gòu)中的子組件要互相溝通時(shí)，這個(gè)作法是派不上用場(chǎng)的。

在復(fù)雜的組件樹(shù)狀結(jié)構(gòu)時(shí)，唯一能作的方式，就是要將整個(gè)應(yīng)用程序的數(shù)據(jù)整合在一起，然后獨(dú)立出來(lái)，也就是整個(gè)應(yīng)用程序領(lǐng)域的數(shù)據(jù)部份。另外還需要對(duì)于數(shù)據(jù)的所有更動(dòng)方式，也要獨(dú)立出來(lái)。這兩者組合在一起，就是稱之為"應(yīng)用程序領(lǐng)域的狀態(tài)"，為了區(qū)分組件中的狀態(tài)(state)，這個(gè)作為應(yīng)用程序領(lǐng)域的持久性數(shù)據(jù)集合，會(huì)被稱為store(存儲(chǔ))。

store(存儲(chǔ))并不是只有應(yīng)用程序單純的數(shù)據(jù)集合而已，它還包含了所有對(duì)數(shù)據(jù)的更動(dòng)方法

store(存儲(chǔ))的角色并非只是組件中的state(狀態(tài))而已，它也不會(huì)只有單純的記錄數(shù)據(jù)，可能在現(xiàn)今的每種不同的Flux延伸的函數(shù)庫(kù)，對(duì)于store的定義與設(shè)計(jì)都有所不同。在Flux的架構(gòu)中的store中，它包含了對(duì)數(shù)據(jù)更動(dòng)的函數(shù)/方法，F(xiàn)lux稱這些函數(shù)/方法為"存儲(chǔ)查詢(Store Queries)"，也把它的角色定位為類似傳統(tǒng)MVC的Model(模型)，但與傳統(tǒng)的Model(模型)最大明顯不同之處的是，store只能透過(guò)Action(動(dòng)作)以"間接"的方式來(lái)自我刷新。

store的設(shè)計(jì)可以解決應(yīng)用程序的狀態(tài)存放與更動(dòng)的問(wèn)題，但它還不能完整的解決整個(gè)問(wèn)題，只是一個(gè)開(kāi)端。最困難的地方在于，要如何在觸發(fā)動(dòng)作時(shí)，進(jìn)行store(存儲(chǔ))的更動(dòng)查詢，以及進(jìn)行呈現(xiàn)數(shù)據(jù)的更動(dòng)與最后作整個(gè)應(yīng)用程序的渲染。這一連串的步驟，整合為一個(gè)數(shù)據(jù)流(Data Flow)，F(xiàn)lux的名稱來(lái)由其實(shí)就是拉丁文中的Flow，F(xiàn)lux用單向(unidirectional)數(shù)據(jù)流來(lái)設(shè)計(jì)整個(gè)數(shù)據(jù)流的運(yùn)作，也就是說(shuō)整個(gè)數(shù)據(jù)的流動(dòng)方向都是一致的，從在網(wǎng)頁(yè)上呈現(xiàn)的操作介面組件，被觸發(fā)事件后，傳送動(dòng)作到發(fā)送器，再到store，最后進(jìn)行整個(gè)應(yīng)用的重新渲染，都是往單一個(gè)方向運(yùn)行。

單向數(shù)據(jù)流是Flux架構(gòu)的核心設(shè)計(jì)

下面是個(gè)簡(jiǎn)單的流程示意圖，上面有標(biāo)出主要的參與成員，來(lái)自Flux官網(wǎng):

這個(gè)數(shù)據(jù)流的位于最中心的設(shè)計(jì)是一個(gè)AppDispatcher(應(yīng)用發(fā)送器)，你可以把它想成是個(gè)發(fā)送中心，不論來(lái)自組件何處的動(dòng)作都需要經(jīng)過(guò)它來(lái)發(fā)送。每個(gè)store會(huì)在AppDispatcher上注冊(cè)它自己，提供一個(gè)callback(回調(diào))，當(dāng)有動(dòng)作(action)發(fā)生時(shí)，AppDispatcher(應(yīng)用發(fā)送器)會(huì)用這個(gè)回調(diào)函數(shù)通知store。

由于每個(gè)Action(動(dòng)作)只是一個(gè)單純的對(duì)象，包含actionType(動(dòng)作類型)與數(shù)據(jù)(通常稱為payload)，我們會(huì)另外需要Action Creator(動(dòng)作創(chuàng)建器)，它們是一些輔助函數(shù)，除了創(chuàng)建動(dòng)作外也會(huì)把動(dòng)作傳給Dispatcher(發(fā)送器)，也就是調(diào)用Dispatcher(發(fā)送器)中的dispatch方法。

注: Payload用在計(jì)算機(jī)科學(xué)的意思，是指在數(shù)據(jù)傳輸時(shí)的"有效數(shù)據(jù)"部份，也就是不包含傳輸時(shí)的頭部信息或metadata等等用于傳輸其他數(shù)據(jù)。它的英文原本是指是飛彈或火箭的搭載的真正有效的負(fù)載部份，例如炸藥或核子彈頭，另外的不屬于payload的部份當(dāng)然就是火箭傳送時(shí)用的燃料或控制零件。

Dispatcher(發(fā)送器)的用途就是把接收到的actionType與數(shù)據(jù)(payload)，廣播給所有注冊(cè)的callbacks。它這個(gè)設(shè)計(jì)并非是獨(dú)創(chuàng)的，這在設(shè)計(jì)模式中類似于pub-sub(發(fā)布-訂閱)系統(tǒng)，Dispatcher則是類似Eventbus的概念。Dispatcher類的設(shè)計(jì)很簡(jiǎn)單，其中有兩個(gè)核心的方法，這兩個(gè)是互為相關(guān)的函數(shù):

dispatch 發(fā)送payload(相當(dāng)于動(dòng)作)給所有注冊(cè)的callbacks。組件觸發(fā)事件時(shí)用這個(gè)方式來(lái)發(fā)送動(dòng)作。

register 注冊(cè)在所有payload(相當(dāng)于動(dòng)作)發(fā)送時(shí)要調(diào)用的callbacks(回調(diào))。這些callbacks(回調(diào))就是上面說(shuō)的會(huì)用來(lái)更動(dòng)store的Store Queries(存儲(chǔ)查詢)。

在數(shù)據(jù)流的最后，store要觸發(fā)最上層組件的setState，然后進(jìn)行整體React的重新渲染工作。Flux提出的方式是一種自訂事件的監(jiān)聽(tīng)方式，把store用EventEmitter.prototype對(duì)象進(jìn)行拓展，讓store具有監(jiān)聽(tīng)事件的能力，然后在最上層組件中的生命周期中，加入有更動(dòng)時(shí)的監(jiān)聽(tīng)事件。這是由于JavaScript中內(nèi)建的Event、CustomEvent等介面，以及addListener、dispatch等方法，只能實(shí)作在具有事件介面的網(wǎng)頁(yè)DOM元素上。單純?cè)贘avaScript的對(duì)象上是沒(méi)有辦法使用，要靠額外的函數(shù)庫(kù)才能這樣作，這是一定要使用類似像EventEmitter這種函數(shù)庫(kù)的主要原因。

不過(guò)，你可能會(huì)覺(jué)得為什么不干脆一點(diǎn)直接對(duì)store上面作更動(dòng)就好了，一定要拐這么大一個(gè)彎，透過(guò)Action(動(dòng)作)"間接"的方式來(lái)作自我刷新？

我想原因之一，是要標(biāo)準(zhǔn)化Action(動(dòng)作)的規(guī)格，也就是所有在應(yīng)用程序中的組件，都得要按照這些動(dòng)作來(lái)觸發(fā)事件，發(fā)送器中注冊(cè)的callbacks(回調(diào))也是要寫成處理同一種規(guī)格的動(dòng)作。Action(動(dòng)作)主要由type(類型)與payload(有效數(shù)據(jù))組成，F(xiàn)lux Standard Action(Flux標(biāo)準(zhǔn)動(dòng)作)就是提出來(lái)要標(biāo)準(zhǔn)化Action(動(dòng)作)的格式，有了統(tǒng)一格式的Action對(duì)象，在刷新數(shù)據(jù)時(shí)所有刷新方式會(huì)具統(tǒng)一性，這樣Flux才有辦法把整個(gè)數(shù)據(jù)流運(yùn)作完成一個(gè)循環(huán)再接著下一個(gè)。就像網(wǎng)絡(luò)的傳輸協(xié)定一樣，數(shù)據(jù)的格式與運(yùn)作的流程，都有標(biāo)準(zhǔn)的規(guī)范，不是隨隨便便就可以進(jìn)行傳輸。當(dāng)然還有一些其它的原因，例如要避免Event Chains(事件連鎖)的發(fā)生。

整個(gè)的數(shù)據(jù)運(yùn)作流程，大概是像下面這樣:

事件觸發(fā) ->
由Action Creator調(diào)用Dispatcher.dispatch(action) ->
Dispatcher調(diào)用已注冊(cè)的回調(diào)(callback) ->
調(diào)用對(duì)應(yīng)的存儲(chǔ)查詢(Store Queries) ->
觸發(fā)Store更動(dòng)事件 ->
進(jìn)行整個(gè)應(yīng)用的重新渲染

下面是整個(gè)流程的示意圖，來(lái)自Flux官網(wǎng):

總結(jié)來(lái)說(shuō)，F(xiàn)lux使用了單向數(shù)據(jù)流的設(shè)計(jì)架構(gòu)，是為了要解決React的應(yīng)用程序領(lǐng)域狀態(tài)的問(wèn)題。Flux的實(shí)作并不容易，有許多實(shí)作上的細(xì)節(jié)與開(kāi)發(fā)步驟上都有分割不明確的問(wèn)題，所以在此并不討論Flux的實(shí)作部份。在Flux發(fā)表之后(約為2014年中)，陸陸續(xù)續(xù)出現(xiàn)了許多函數(shù)庫(kù)與框架，都是基于Flux的基本設(shè)計(jì)概念，都是為了要改善、簡(jiǎn)化或自動(dòng)化其中的實(shí)作步驟為主，而Redux也是其中一套。在經(jīng)過(guò)一段時(shí)間之后，目前較熱門的與較多人使用的，就屬Redux，它有很多的設(shè)計(jì)概念都來(lái)自于Flux，能多加理解Flux的基本設(shè)計(jì)概念，對(duì)于學(xué)習(xí)Redux是絕對(duì)有幫助的。

或許你有聽(tīng)過(guò)函數(shù)式程序開(kāi)發(fā)(functional programming, FP)的開(kāi)發(fā)風(fēng)格，F(xiàn)P是什么？用下面的一句話來(lái)說(shuō)明，摘譯自這篇教程文檔:

函數(shù)式程序開(kāi)發(fā)就是只使用"純粹函數(shù)"與"不可改變的值"來(lái)撰寫軟件應(yīng)用的一種方式

FP是現(xiàn)今相當(dāng)熱門的一種程序開(kāi)發(fā)風(fēng)格，在很早之前就已經(jīng)有一些純函數(shù)式程序開(kāi)發(fā)的語(yǔ)言例如Haskell與OCaml，Elm也是一個(gè)純函數(shù)式程序開(kāi)發(fā)的語(yǔ)言，它是一個(gè)很年輕的語(yǔ)言，Elm是專門用來(lái)開(kāi)發(fā)網(wǎng)站應(yīng)用程序的程序語(yǔ)言，最終編譯為JavaScript在網(wǎng)頁(yè)上運(yùn)行，它與JavaScript語(yǔ)言有多差異很大的設(shè)計(jì)，例如:

Elm是強(qiáng)(靜態(tài))數(shù)據(jù)類型的，它的數(shù)據(jù)類型也滿多樣的

Elm是純FP的語(yǔ)言

Elm-Architecture是包含在Elm的應(yīng)用框架，它是單向數(shù)據(jù)流的架構(gòu)

React與Flux中有許多設(shè)計(jì)，都有應(yīng)用到FP的設(shè)計(jì)，與Elm中一部份設(shè)計(jì)相當(dāng)類似。而Redux又使用更多Elm中的設(shè)計(jì)，尤其是Elm-Architecture而來(lái)的，例如:

不可改變性(Immutability): 所有的值在Elm中都是不可改變的，Redux中的純函數(shù)(pure function)與Reducer的設(shè)計(jì)很類似，React的設(shè)計(jì)中也有這類的概念

時(shí)光旅行調(diào)試(Time Traveling Debugger): 在Elm有這個(gè)設(shè)計(jì)，Redux學(xué)了過(guò)來(lái)

Redux作者使用了FP(函數(shù)式程序開(kāi)發(fā))與Elm的架構(gòu)，改進(jìn)或簡(jiǎn)化原本的Flux架構(gòu)

Redux是目前最熱門的、最多人使用的Flux架構(gòu)類的函數(shù)庫(kù)，雖然Redux也可以用于其他的函數(shù)庫(kù)，但基本上它是專門為了React應(yīng)用所打造的。如果你真的要學(xué)會(huì)React，并用它來(lái)開(kāi)發(fā)一個(gè)稍有規(guī)模的應(yīng)用，學(xué)習(xí)Redux說(shuō)是一條必經(jīng)之路，當(dāng)然也有其他的Flux架構(gòu)類函數(shù)庫(kù)可以選擇，不同的函數(shù)庫(kù)有可能使用的解決方式與樣式相差會(huì)非常大。目前來(lái)說(shuō)Redux的開(kāi)發(fā)社群是最龐大也是最活躍的，而且不見(jiàn)得其他的函數(shù)庫(kù)就會(huì)更容易學(xué)習(xí)與使用，畢竟用得人多，你會(huì)遇到的問(wèn)題大概都有人遇過(guò)，也都能找得到解決方式，這是開(kāi)源碼生態(tài)圈的紅利。

Redux會(huì)受歡迎不是沒(méi)有原因的，以下分析幾個(gè)Redux的優(yōu)點(diǎn):

Redux不同于Flux架構(gòu)，它改采幾乎是純FP(函數(shù)式程序開(kāi)發(fā))的解決方式，目的是為了要簡(jiǎn)化Flux中數(shù)據(jù)流的處理實(shí)作，也的確可以與React中的組件渲染配合得很好，這證明了它是找到了一個(gè)較為理想的與React應(yīng)用能密切合作的解決方式。FP(函數(shù)式程序開(kāi)發(fā))也是目前JavaScript界的熱門主題，Redux也因此吸引到不少開(kāi)發(fā)者的目光。

Redux一開(kāi)始就附了時(shí)光旅行調(diào)試工具與熱重新加載(hot reloading)的工具來(lái)提升開(kāi)發(fā)體驗(yàn)，這對(duì)開(kāi)發(fā)者有很大的吸引力，這也代表在Redux應(yīng)用上的數(shù)據(jù)變動(dòng)，可以更容易的測(cè)試與調(diào)試，這是其他Flux架構(gòu)類函數(shù)庫(kù)或框架中所沒(méi)有的見(jiàn)到的。

Redux一開(kāi)始的版本只有99行代碼，這可能比一開(kāi)始的Flux架構(gòu)使用的API更要少，不過(guò)代碼少不見(jiàn)得概念就簡(jiǎn)單，F(xiàn)P的撰寫風(fēng)格多半追求的是更簡(jiǎn)短的代碼，這需要高超的技巧、深度的概念與不少的基礎(chǔ)。Redux一開(kāi)始就可以很容易的使用于服務(wù)器端渲染，而且也不限于使用于React應(yīng)用上，這也吸引了更多的開(kāi)發(fā)者使用意愿。

Redux作者一開(kāi)始就撰寫非常多的文件與教程，讓許多開(kāi)發(fā)者能更快捷地掌握Redux的應(yīng)用技術(shù)，Redux作者也是技術(shù)討論區(qū)的常客，常常可以看到他在討論區(qū)上回覆相關(guān)的問(wèn)題。Redux的項(xiàng)目也是相當(dāng)活躍的，有非常多的參與者在討論與解決問(wèn)題，對(duì)于重大效能/臭蟲(chóng)問(wèn)題也是很快捷地解決。