原文地址在我的博客, 轉(zhuǎn)載請注明出處，謝謝！

概述

本文介紹了我對 Redux 狀態(tài)管理的思想、原理、架構(gòu)方法的認識和思考以及配合redux-saga處理異步操作的實踐

前言

You know, React 只是屬于MV*架構(gòu)模式的 view 層，是一種狀態(tài)機，只使用 React 難以控制大型、復雜的應用，它需要一些框架來幫助管理狀態(tài)，因此如何有效、簡單、易于測試地管理這個狀態(tài)機是各種架構(gòu)框架感興趣的。Facebook 早就意識到這個問題并提出了 Flux 架構(gòu)，比較復雜; 后來出現(xiàn)了 Redux、Mobx 等。MobX 可以處理簡單數(shù)據(jù)流的場景，可以實現(xiàn)精確更新; Redux 是從 Flux 和其他框架借鑒了一些思想， 它比 Flux 簡單、易于理解、用于處理復雜數(shù)據(jù)流，并具有很強的擴展性，社區(qū)誕生了像redux-thunk、redux-promise、redux-saga等中間件用于方便地處理異步操作。最近也在項目中使用了 Redux 及其中間件 redux-saga 來管理狀態(tài)和處理異步操作，這篇文章就來談談我對它們的思考和實踐。

正文

Redux 思想

先來談談背景（需求）

我覺得理解Redux的思想，談談MV*架構(gòu)模式的思路也許會有幫助。

MV*架構(gòu)模式，它們的核心都是職責分離、解耦，不同的層次做不同的事，能讓一個復雜、混亂的應用變得思路清晰，代碼可以復用，并且易于測試，有利于分工合作，構(gòu)建更大、更復雜的應用。

一個應用要包括哪些功能？表現(xiàn)（view）、處理數(shù)據(jù)的邏輯（model）以及數(shù)據(jù)映射到表現(xiàn)層的邏輯（presenter or controller），數(shù)據(jù)在這三層之間流通（MVVM模式通過數(shù)據(jù)雙向綁定實現(xiàn)view和model同步）。

React 根據(jù)state來render，它只是個狀態(tài)機，并沒有解決管理狀態(tài)的問題。我們在單純的使用React來寫組件的時候，經(jīng)常會遇到組件間通信和管理組件state的問題，前者常用的解決辦法就是把數(shù)據(jù)提到父組件共享；后者管理state簡單的情況還行，一復雜就很麻煩且容易出錯，再遇到一些需要異步處理的操作，想想就頭皮發(fā)麻。

當你開發(fā)中遇到一些反人類的操作時，試著去想如何改變一下思路讓它變得更簡單，別耐著性子安慰自己開發(fā)就是這樣 :)

解決方案

Redux 正是用來解決大型React應用所面臨的狀態(tài)管理、數(shù)據(jù)流通、異步處理、測試、團隊合作等問題：

Redux 用單一的object tree來表示整個應用的state，這個表示state的對象樹被放在唯一的store 中，state相當于store的快照；所有組件都會通過API拿到這個state，各取所需；

Redux 把頁面上用戶的操作或者瀏覽器的行為（如路由的變化）定義為一個要更新state的action，這個action是一個普通對象，它包含了要執(zhí)行動作的類別和傳遞到state的數(shù)據(jù)（如果有的話），它只表明要更改state的意圖，相當于一個信號，并不能直接修改state，Redux會集中處理這些信號，這個action由你來決定何時發(fā)起；

定義好信號，你還需要根據(jù)不同的信號定義不同的邏輯函數(shù)（reducers）來更新state。

通過這張圖來整理一下：

“redux 原理圖”

咳咳...比如用戶點擊的一個按鈕，你在按鈕上綁定的回調(diào)函數(shù)調(diào)用了一個（多個）action creator，action creator就返回了一個更新state局部數(shù)據(jù)的action，store會根據(jù)這個（多個）action找到對應的reducers（reducer需要做拆分），按照action發(fā)起的順序依次執(zhí)行來更新state，每個reducer只負責更新自己關心那部分，根 reducer 把多個子 reducer 輸出合并成一個單一的 state 樹，生成一個新的state保存在store中，store中的state可以通過相應API傳遞到子組件。

這就是整個數(shù)據(jù)流。

那Redux如何處理異步操作？

Redux借鑒了中間件思想，利用可擴展的中間件來改造dispatch函數(shù)。比如redux-thunk讓dispatch不僅僅可以接收action，還可以接受函數(shù)作為參數(shù)，你可以在這個函數(shù)里完成異步操作。再如redux-saga更強大、也更復雜，在后面會講到。

Redux 架構(gòu)方法

對于React技術(shù)棧，Redux實現(xiàn)了react-redux庫來讓Redux管理React應用（其他框架也有相應的庫），里面集成了一些有用的函數(shù)來把一些明確的流程自動化，如createStore用于創(chuàng)建唯一store，可以把根reducer傳進createStore使store自動調(diào)用對應reducer，可以擴展中間件；提供<Provider store>組件和connect高階組件用來包裹render component并傳遞state，connect還能自動dispatch，讓你只要調(diào)用action creator就能dispatch；提供combineReducers來組合分割的reducers等。

知道這些特性，就可以配合react-router構(gòu)建大型應用了：

總的思路就是：利用react-router 把應用分割為各個頁面，reducer、action creator也跟隨頁面分割而分割。每個路由對應的頁面下都有components和containers，分別存放functional components 和class components，前者用來渲染，后者當做containers被connect包裹，containers包裹components；containers從connect得到state并映射需要的數(shù)據(jù)到子組件的props，子組件再向下傳遞。

具體如何構(gòu)建React + Redux + react-router，我在另一篇博客里講了。

使用這種架構(gòu)，開發(fā)大型應用變得得心應手。

Redux 存在的問題

但是當我深入項目開發(fā)的時候，也逐漸發(fā)現(xiàn)了一些問題：

• 這種架構(gòu)項目結(jié)構(gòu)不夠扁平化，文件嵌套比較深，思路比較復雜，搭建、寫起來比較麻煩，上手有難度；
• 由于所有action creator都定義在頁面層次上，讓子組件調(diào)用必須一層一層的傳遞，很麻煩且非常容易出錯，也很難調(diào)試；
• state難以做到局部更新（這個可以用reselect）
• Redux只是傳遞了一種思路，定義了幾個簡單的API，很靈活，架構(gòu)方式不固定，設計方式不固定（如：如何設計state樹）但這也是它的缺點，新人往往看完一遍還是不知道怎么做，對新人不友好

總之，redux可以勝任復雜數(shù)據(jù)流的應用，但是也比較難，前期架構(gòu)比較麻煩，適合有經(jīng)驗的人。

使用redux-saga處理異步操作

Redux 倡導action 和reducer盡可能"純凈"，沒有什么“副作用”。可是像一些異步操作比如獲取數(shù)據(jù)是必須的，在哪處理這些副作用呢？redux 把這些"不純凈的"任務交給了中間件，通過 向createStore里應用中間件，在交由store處理action之前就可以對其完成一些其他的操作：

“redux 中間件”

而redux-saga 是Redux一個強大但并不復雜的用于異步處理的中間件。

它的思路是什么？相比其他redux異步中間件如redux-thunk、redux-promise有什么不同？

先看名字來理解：saga，這個術(shù)語常用于CQRS架構(gòu)，代表查詢與責任分離。

沒錯，就是查詢（dispatch）與責任（sagas）分離。saga提供了action監(jiān)聽函數(shù)，只需在組件里dispatch 相應type的action，就可以自動調(diào)用你定義好的對應這個action的異步處理函數(shù)（sagas）來完成任務，保證了只在組件里dispatch action來發(fā)起異步操作而不是redux-thunk、redux-promise的調(diào)用action creators。

另外一大特色就是redux-saga做到了異步代碼以同步方式寫，非常直觀方便，怎么做到的呢？它是利用了ES6新魔法Generator迭代器，可以完美解決異步回調(diào)地獄，讓你以同步方式寫異步。saga正是利用Generator特性讓其處理異步變得非常方便又容易理解。這是一個常見的請求后臺數(shù)據(jù)的異步操作，感受一下：

function *fetchNodeDetailByNodeId({ payload: { nodeId } }, { call, put }) {
      try {
        const { data, status }= yield call(fetchNodeDetailByNodeId, nodeId)
        if (data && status.errmsg === 'success') {
          yield put({
            type: 'setStates',
            payload: {
              nodeDetailData: data,
            },
          });
        } else {
          message.info('開了個小差,再試一次吧..');
        }
      } catch (error) {
        console.log(error);
      }
    },

call 和 put 是saga的API，相當于dispatch，但是并不是真正執(zhí)行dispatch，只是發(fā)送你指定的指令，交由saga中間件來執(zhí)行這個指令。這樣看來，這個saga函數(shù)就是一些指令的集合，稱為effects，副作用，用來描述任務

為啥要描述指令而不直接調(diào)用呢？這樣是因為易于測試，如果直接調(diào)用，你還得模擬調(diào)用的函數(shù)，詳見redux-saga文檔。

我覺得redux-saga相比于其他中間件的優(yōu)點：

• 查詢與責任分離，保證了action的純潔性，符合redux設計思想
• 實現(xiàn)以同步方式寫異步操作，容易理解，邏輯清晰
• 通過發(fā)送指令而不是直接調(diào)用讓異步操作變得容易測試
• 監(jiān)聽、執(zhí)行自動化
• 提供了豐富強大的指令來完成復雜的操作，比如無阻塞調(diào)用，同時執(zhí)行多個任務等

講道理，任何redux異步操作都可以讓saga這個中間件來完成，非常復雜的同樣可以勝任，并且很容易理解（異步操作以同步方式寫）和測試。再配合dva，可以減輕redux的復雜度同時完成更強大的功能。

這樣以來，redux配合saga，就可以讓它們各司其職，整個思路也變得清晰起來：

redux 倡導action和reducer要純潔，那就讓所有異步操作這些不純潔的任務交給saga，reducer不用變，還是純函數(shù)；定義好對應action的sagas專門用來處理異步操作，我只要在組件需要的地方里dispatch 純action就行了，符合redux設計思想。

總結(jié)

使用redux來管理應用狀態(tài)適用于復雜的應用，而復雜的應用會有復雜的異步處理，異步處理不要用redux的action creator，它不是用來做這個的，也違背了redux設計思想，redux把這些任務交給了異步中間件，應該由它們來完成。使用redux saga是一個推薦的選擇，它懂redux，也懂你需要什么。另外，既然你用到了saga，不妨試試dva架構(gòu)，5分鐘上手，值得一試。