摘要：應用這說明并不是單指設計給用的，它是獨立的一個函數庫，可通用于各種應用。在數據流的最后，要觸發最上層組件的，然后進行整體的重新渲染工作。單純在的對象上是沒有辦法使用，要靠額外的函數庫才能這樣作，這是一定要使用類似像這種函數庫的主要原因。

Redux的官網中用一句話來說明Redux是什么:

Redux是針對JavaScript應用的可預測狀態容器

這句話雖然簡短，其實是有幾個涵義的:

可預測的(predictable): 因為Redux用了reducer與純函數(pure function)的概念，每個新的state都會由舊的state建來一個全新的state，這樣可以作所謂的時光旅行調試。因此，所有的狀態修改都是"可預測的"。

狀態容器(state container): state是集中在單一個對象樹狀結構下的單一store，store即是應用程序領域(app domain)的狀態集合。

JavaScript應用: 這說明Redux并不是單指設計給React用的，它是獨立的一個函數庫，可通用于各種JavaScript應用。

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

Redux = Flux + Elm

當然除了Flux與Elm之外，還有其他的主要像RxJS中的概念與設計方式，Redux融合了各家的技術于一身，除了更理想的使用在Flux要解決的問題上之外，更延伸了一些不同的設計方式。但是對初學者來說，它也不容易學習，網絡上常常見到初學者報怨Redux實在有夠難學，這也并不是完全是Redux的問題，基本上來說Flux的架構原本就不是很容易理解，Redux還簡化了Flux的流程與開發方式。

所以我們要理解Redux是什么，我們開始可以從這Flux與Elm兩大基礎來理解，以下分別說明一些基本的概念。

不論是Flux或其他以Flux架構為基礎延伸發展的函數庫(Alt、Reflux、Redux...)都是為了要解決同一個問題，這個問題在React應用規模化時會非常明顯，簡單以一句話來說就是:

應用程序領域(app domain)的狀態 - 簡稱為App state

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

React應用為什么會出現這個問題？原因主要是來自React組件的本身設計造成的。React被設計為一個相似于MVC架構中的View(視圖)的函數庫，當然實際上它可以作的事情比MVC中的View(視圖)還要更多，但本質上的確React不是一個完整的應用程序開發框架，里面沒有額外的架構可以作類似Model(模型)或Controller(控制器)的事情。對小型的組件或應用而言，應用的數據都包含在里面，也就是在View(視圖)之中。

有學過React的一些基礎的開發者應該會知道，在React中的組件是無法直接更動state(狀態)的包含值，要透過setState方法來進行更動，這有很大的原因是為了Virtual DOM(虛擬DOM)的所設計，這是其中一點。另外在組件的樹狀階層結構，父組件(擁有者)與子組件(被擁有者)的關系上，子組件是只能由父組件以props(屬性)來傳遞屬性值，子組件自己本身無法更改自己的props，這也是為什么一開始在學習React時，都會看到大部份的例子只有在最上層的組件有state，而且都是由它來負責進行當數據改變時的重新渲染工作，子組件通常只有負責呈現數據。

當然，有一個很技巧性的方式，是把父組件中的方法聲明由props傳遞給子組件，然后在子組件觸發事件時，調用這個父組件的方法，以此來達到子組件對父組件的溝通，間接來更動父組件中的state。不過這個作法并不直覺，需要事先規范好兩邊的方法。在簡單的應用程序中，這溝通方式還可行，但如果是在有復雜的組件嵌套階層結構時，例如層級很多或是不同樹狀結構中的子組件要互相溝通時，這個作法是派不上用場的。

在復雜的組件樹狀結構時，唯一能作的方式，就是要將整個應用程序的數據整合在一起，然后獨立出來，也就是整個應用程序領域的數據部份。另外還需要對于數據的所有更動方式，也要獨立出來。這兩者組合在一起，就是稱之為"應用程序領域的狀態"，為了區分組件中的狀態(state)，這個作為應用程序領域的持久性數據集合，會被稱為store(存儲)。

store(存儲)并不是只有應用程序單純的數據集合而已，它還包含了所有對數據的更動方法

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

store的設計可以解決應用程序的狀態存放與更動的問題，但它還不能完整的解決整個問題，只是一個開端。最困難的地方在于，要如何在觸發動作時，進行store(存儲)的更動查詢，以及進行呈現數據的更動與最后作整個應用程序的渲染。這一連串的步驟，整合為一個數據流(Data Flow)，Flux的名稱來由其實就是拉丁文中的Flow，Flux用單向(unidirectional)數據流來設計整個數據流的運作，也就是說整個數據的流動方向都是一致的，從在網頁上呈現的操作介面組件，被觸發事件后，傳送動作到發送器，再到store，最后進行整個應用的重新渲染，都是往單一個方向運行。

單向數據流是Flux架構的核心設計

下面是個簡單的流程示意圖，上面有標出主要的參與成員，來自Flux官網:

這個數據流的位于最中心的設計是一個AppDispatcher(應用發送器)，你可以把它想成是個發送中心，不論來自組件何處的動作都需要經過它來發送。每個store會在AppDispatcher上注冊它自己，提供一個callback(回調)，當有動作(action)發生時，AppDispatcher(應用發送器)會用這個回調函數通知store。

由于每個Action(動作)只是一個單純的對象，包含actionType(動作類型)與數據(通常稱為payload)，我們會另外需要Action Creator(動作創建器)，它們是一些輔助函數，除了創建動作外也會把動作傳給Dispatcher(發送器)，也就是調用Dispatcher(發送器)中的dispatch方法。

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

Dispatcher(發送器)的用途就是把接收到的actionType與數據(payload)，廣播給所有注冊的callbacks。它這個設計并非是獨創的，這在設計模式中類似于pub-sub(發布-訂閱)系統，Dispatcher則是類似Eventbus的概念。Dispatcher類的設計很簡單，其中有兩個核心的方法，這兩個是互為相關的函數:

dispatch 發送payload(相當于動作)給所有注冊的callbacks。組件觸發事件時用這個方式來發送動作。

register 注冊在所有payload(相當于動作)發送時要調用的callbacks(回調)。這些callbacks(回調)就是上面說的會用來更動store的Store Queries(存儲查詢)。

在數據流的最后，store要觸發最上層組件的setState，然后進行整體React的重新渲染工作。Flux提出的方式是一種自訂事件的監聽方式，把store用EventEmitter.prototype對象進行拓展，讓store具有監聽事件的能力，然后在最上層組件中的生命周期中，加入有更動時的監聽事件。這是由于JavaScript中內建的Event、CustomEvent等介面，以及addListener、dispatch等方法，只能實作在具有事件介面的網頁DOM元素上。單純在JavaScript的對象上是沒有辦法使用，要靠額外的函數庫才能這樣作，這是一定要使用類似像EventEmitter這種函數庫的主要原因。

不過，你可能會覺得為什么不干脆一點直接對store上面作更動就好了，一定要拐這么大一個彎，透過Action(動作)"間接"的方式來作自我刷新？

我想原因之一，是要標準化Action(動作)的規格，也就是所有在應用程序中的組件，都得要按照這些動作來觸發事件，發送器中注冊的callbacks(回調)也是要寫成處理同一種規格的動作。Action(動作)主要由type(類型)與payload(有效數據)組成，Flux Standard Action(Flux標準動作)就是提出來要標準化Action(動作)的格式，有了統一格式的Action對象，在刷新數據時所有刷新方式會具統一性，這樣Flux才有辦法把整個數據流運作完成一個循環再接著下一個。就像網絡的傳輸協定一樣，數據的格式與運作的流程，都有標準的規范，不是隨隨便便就可以進行傳輸。當然還有一些其它的原因，例如要避免Event Chains(事件連鎖)的發生。

整個的數據運作流程，大概是像下面這樣:

事件觸發 ->
由Action Creator調用Dispatcher.dispatch(action) ->
Dispatcher調用已注冊的回調(callback) ->
調用對應的存儲查詢(Store Queries) ->
觸發Store更動事件 ->
進行整個應用的重新渲染

下面是整個流程的示意圖，來自Flux官網:

總結來說，Flux使用了單向數據流的設計架構，是為了要解決React的應用程序領域狀態的問題。Flux的實作并不容易，有許多實作上的細節與開發步驟上都有分割不明確的問題，所以在此并不討論Flux的實作部份。在Flux發表之后(約為2014年中)，陸陸續續出現了許多函數庫與框架，都是基于Flux的基本設計概念，都是為了要改善、簡化或自動化其中的實作步驟為主，而Redux也是其中一套。在經過一段時間之后，目前較熱門的與較多人使用的，就屬Redux，它有很多的設計概念都來自于Flux，能多加理解Flux的基本設計概念，對于學習Redux是絕對有幫助的。

或許你有聽過函數式程序開發(functional programming, FP)的開發風格，FP是什么？用下面的一句話來說明，摘譯自這篇教程文檔:

函數式程序開發就是只使用"純粹函數"與"不可改變的值"來撰寫軟件應用的一種方式

FP是現今相當熱門的一種程序開發風格，在很早之前就已經有一些純函數式程序開發的語言例如Haskell與OCaml，Elm也是一個純函數式程序開發的語言，它是一個很年輕的語言，Elm是專門用來開發網站應用程序的程序語言，最終編譯為JavaScript在網頁上運行，它與JavaScript語言有多差異很大的設計，例如:

Elm是強(靜態)數據類型的，它的數據類型也滿多樣的

Elm是純FP的語言

Elm-Architecture是包含在Elm的應用框架，它是單向數據流的架構

React與Flux中有許多設計，都有應用到FP的設計，與Elm中一部份設計相當類似。而Redux又使用更多Elm中的設計，尤其是Elm-Architecture而來的，例如:

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

時光旅行調試(Time Traveling Debugger): 在Elm有這個設計，Redux學了過來

Redux作者使用了FP(函數式程序開發)與Elm的架構，改進或簡化原本的Flux架構

Redux是目前最熱門的、最多人使用的Flux架構類的函數庫，雖然Redux也可以用于其他的函數庫，但基本上它是專門為了React應用所打造的。如果你真的要學會React，并用它來開發一個稍有規模的應用，學習Redux說是一條必經之路，當然也有其他的Flux架構類函數庫可以選擇，不同的函數庫有可能使用的解決方式與樣式相差會非常大。目前來說Redux的開發社群是最龐大也是最活躍的，而且不見得其他的函數庫就會更容易學習與使用，畢竟用得人多，你會遇到的問題大概都有人遇過，也都能找得到解決方式，這是開源碼生態圈的紅利。

Redux會受歡迎不是沒有原因的，以下分析幾個Redux的優點:

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

Redux一開始就附了時光旅行調試工具與熱重新加載(hot reloading)的工具來提升開發體驗，這對開發者有很大的吸引力，這也代表在Redux應用上的數據變動，可以更容易的測試與調試，這是其他Flux架構類函數庫或框架中所沒有的見到的。

Redux一開始的版本只有99行代碼，這可能比一開始的Flux架構使用的API更要少，不過代碼少不見得概念就簡單，FP的撰寫風格多半追求的是更簡短的代碼，這需要高超的技巧、深度的概念與不少的基礎。Redux一開始就可以很容易的使用于服務器端渲染，而且也不限于使用于React應用上，這也吸引了更多的開發者使用意愿。

Redux作者一開始就撰寫非常多的文件與教程，讓許多開發者能更快捷地掌握Redux的應用技術，Redux作者也是技術討論區的常客，常常可以看到他在討論區上回覆相關的問題。Redux的項目也是相當活躍的，有非常多的參與者在討論與解決問題，對于重大效能/臭蟲問題也是很快捷地解決。