上一篇文章我們分析了Redux-Thunk的源碼，可以看到他的代碼非常簡單，只是讓dispatch可以處理函數類型的action，其作者也承認對於復雜場景，Redux-Thunk並不適用，還推薦了Redux-Saga來處理復雜副作用。本文要講的就是Redux-Saga，這個也是我在實際工作中使用最多的Redux異步解決方案。Redux-Saga比Redux-Thunk復雜得多，而且他整個異步流程都使用Generator來處理，Generator也是我們這篇文章的前置知識，如果你對Generator還不熟悉，可以看看這篇文章。
本文仍然是老套路，先來一個Redux-Saga的簡單例子，然后我們自己寫一個Redux-Saga來替代他，也就是源碼分析。
本文可運行的代碼已經上傳到GitHub，可以拿下來玩玩：https://github.com/dennis-jiang/Front-End-Knowledges/tree/master/Examples/React/redux-saga
簡單例子
網絡請求是我們經常需要處理的異步操作，假設我們現在的一個簡單需求就是點擊一個按鈕去請求用戶的信息，大概長這樣：
這個需求使用Redux實現起來也很簡單，點擊按鈕的時候dispatch出一個action。這個action會觸發一個請求，請求返回的數據拿來顯示在頁面上就行：
import React from 'react';
import { connect } from 'react-redux';
function App(props) {
const { dispatch, userInfo } = props;
const getUserInfo = () => {
dispatch({ type: 'FETCH_USER_INFO' })
}
return (
<div className="App">
<button onClick={getUserInfo}>Get User Info</button>
<br></br>
{userInfo && JSON.stringify(userInfo)}
</div>
);
}
const matStateToProps = (state) => ({
userInfo: state.userInfo
})
export default connect(matStateToProps)(App);
上面這種寫法都是我們之前講Redux就介紹過的，Redux-Saga介入的地方是dispatch({ type: 'FETCH_USER_INFO' })之后。按照Redux一般的流程，FETCH_USER_INFO被發出后應該進入reducer處理，但是reducer都是同步代碼，並不適合發起網絡請求，所以我們可以使用Redux-Saga來捕獲FETCH_USER_INFO並處理。
Redux-Saga是一個Redux中間件，所以我們在createStore的時候將它引入就行：
// store.js
import { createStore, applyMiddleware } from 'redux';
import createSagaMiddleware from 'redux-saga';
import reducer from './reducer';
import rootSaga from './saga';
const sagaMiddleware = createSagaMiddleware()
let store = createStore(reducer, applyMiddleware(sagaMiddleware));
// 注意這里，sagaMiddleware作為中間件放入Redux后
// 還需要手動啟動他來運行rootSaga
sagaMiddleware.run(rootSaga);
export default store;
注意上面代碼里的這一行：
sagaMiddleware.run(rootSaga);
sagaMiddleware.run是用來手動啟動rootSaga的，我們來看看rootSaga是怎么寫的：
import { call, put, takeLatest } from 'redux-saga/effects';
import { fetchUserInfoAPI } from './api';
function* fetchUserInfo() {
try {
const user = yield call(fetchUserInfoAPI);
yield put({ type: "FETCH_USER_SUCCEEDED", payload: user });
} catch (e) {
yield put({ type: "FETCH_USER_FAILED", payload: e.message });
}
}
function* rootSaga() {
yield takeEvery("FETCH_USER_INFO", fetchUserInfo);
}
export default rootSaga;
上面的代碼我們從export開始看吧，export的東西是rootSaga這個Generator函數，這里面就一行:
yield takeEvery("FETCH_USER_INFO", fetchUserInfo);
這一行代碼用到了Redux-Saga的一個effect，也就是takeEvery，他的作用是監聽每個FETCH_USER_INFO,當FETCH_USER_INFO出現的時候，就調用fetchUserInfo函數，注意這里是每個FETCH_USER_INFO。也就是說如果同時發出多個FETCH_USER_INFO，我們每個都會響應並發起請求。類似的還有takeLatest，takeLatest從名字都可以看出來，是響應最后一個請求，具體使用哪一個，要看具體的需求。
然后看看fetchUserInfo函數，這個函數也不復雜，就是調用一個API函數fetchUserInfoAPI去獲取數據，注意我們這里函數調用並不是直接的fetchUserInfoAPI()，而是使用了Redux-Saga的call這個effect，這樣做可以讓我們寫單元測試變得更簡單，為什么會這樣，我們后面講源碼的時候再來仔細看看。獲取數據后，我們調用了put去發出FETCH_USER_SUCCEEDED這個action，這里的put類似於Redux里面的dispatch，也是用來發出action的。這樣我們的reducer就可以拿到FETCH_USER_SUCCEEDED進行處理了，跟以前的reducer並沒有太大區別。
// reducer.js
const initState = {
userInfo: null,
error: ''
};
function reducer(state = initState, action) {
switch (action.type) {
case 'FETCH_USER_SUCCEEDED':
return { ...state, userInfo: action.payload };
case 'FETCH_USER_FAILED':
return { ...state, error: action.payload };
default:
return state;
}
}
export default reducer;
通過這個例子的代碼結構我們可以看出：
action被分為了兩種，一種是觸發異步處理的，一種是普通的同步action。異步
action使用Redux-Saga來監聽，監聽的時候可以使用takeLatest或者takeEvery來處理並發的請求。具體的
saga實現可以使用Redux-Saga提供的方法，比如call，put之類的，可以讓單元測試更好寫。一個
action可以被Redux-Saga和Reducer同時響應，比如上面的FETCH_USER_INFO發出后我還想讓頁面轉個圈，可以直接在reducer里面加一個就行:... case 'FETCH_USER_INFO': return { ...state, isLoading: true }; ...
手寫源碼
通過上面這個例子，我們可以看出，Redux-Saga的運行是通過這一行代碼來實現的：
sagaMiddleware.run(rootSaga);
整個Redux-Saga的運行和原本的Redux並不沖突，Redux甚至都不知道他的存在，他們之間耦合很小，只在需要的時候通過put發出action來進行通訊。所以我猜測，他應該是自己實現了一套完全獨立的異步任務處理機制，下面我們從能感知到的API入手，一步一步來探尋下他源碼的奧秘吧。本文全部代碼參照官方源碼寫成，函數名字和變量名字盡量保持一致，寫到具體的方法的時候我也會貼出對應的代碼地址，主要代碼都在這里:https://github.com/redux-saga/redux-saga/tree/master/packages/core/src
先來看看我們用到了哪些API，這些API就是我們今天手寫的目標:
- createSagaMiddleware：這個方法會返回一個中間件實例
sagaMiddleware- sagaMiddleware.run: 這個方法是真正運行我們寫的
saga的入口- takeEvery：這個方法是用來控制並發流程的
- call：用來調用其他方法
- put：發出
action，用來和Redux通訊
從中間件入手
之前我們講Redux源碼的時候詳細分析了Redux中間件的原理和范式，一個中間件大概就長這個樣子:
function logger(store) {
return function(next) {
return function(action) {
console.group(action.type);
console.info('dispatching', action);
let result = next(action);
console.log('next state', store.getState());
console.groupEnd();
return result
}
}
}
這其實就相當於一個Redux中間件的范式了：
- 一個中間件接收
store作為參數，會返回一個函數- 返回的這個函數接收老的
dispatch函數作為參數(也就是上面的next)，會返回一個新的函數- 返回的新函數就是新的
dispatch函數，這個函數里面可以拿到外面兩層傳進來的store和老dispatch函數
依照這個范式以及前面對createSagaMiddleware的使用，我們可以先寫出這個函數的骨架：
// sagaMiddlewareFactory其實就是我們外面使用的createSagaMiddleware
function sagaMiddlewareFactory() {
// 返回的是一個Redux中間件
// 需要符合他的范式
const sagaMiddleware = function (store) {
return function (next) {
return function (action) {
// 內容先寫個空的
let result = next(action);
return result;
}
}
}
// sagaMiddleware上還有個run方法
// 是用來啟動saga的
// 我們先留空吧
sagaMiddleware.run = () => { }
return sagaMiddleware;
}
export default sagaMiddlewareFactory;
梳理架構
現在我們有了一個空的骨架，接下來該干啥呢?前面我們說過了，Redux-Saga很可能是自己實現了一套完全獨立的異步事件處理機制。這種異步事件處理機制需要一個處理中心來存儲事件和處理函數，還需要一個方法來觸發隊列中的事件的執行，再回看前面的使用的API，我們發現了兩個類似功能的API：
- takeEvery(action, callback)：他接收的參數就是
action和callback，而且我們在根saga里面可能會多次調用它來注冊不同action的處理函數，這其實就相當於往處理中心里面塞入事件了。- put(action)：
put的參數是action，他唯一的作用就是觸發對應事件的回調運行。
可以看到Redux-Saga這種機制也是用takeEvery先注冊回調，然后使用put發出消息來觸發回調執行，這其實跟我們其他文章多次提到的發布訂閱模式很像。
手寫channel
channel是Redux-Saga保存回調和觸發回調的地方，類似於發布訂閱模式，我們先來寫個：
export function multicastChannel() {
const currentTakers = []; // 一個變量存儲我們所有注冊的事件和回調
// 保存事件和回調的函數
// Redux-Saga里面take接收回調cb和匹配方法matcher兩個參數
// 事實上take到的事件名稱也被封裝到了matcher里面
function take(cb, matcher) {
cb['MATCH'] = matcher;
currentTakers.push(cb);
}
function put(input) {
const takers = currentTakers;
for (let i = 0, len = takers.length; i < len; i++) {
const taker = takers[i]
// 這里的'MATCH'是上面take塞進來的匹配方法
// 如果匹配上了就將回調拿出來執行
if (taker['MATCH'](input)) {
taker(input);
}
}
}
return {
take,
put
}
}
上述代碼中有一個奇怪的點，就是將matcher作為屬性放到了回調函數上，這么做的原因我想是為了讓外部可以自定義匹配方法，而不是簡單的事件名稱匹配，事實上Redux-Saga本身就支持好幾種匹配模式，包括字符串，Symbol,數組等等。
內置支持的匹配方法可以看這里：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/matcher.js。
channel對應的源碼可以看這里：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/channel.js#L153
有了channel之后，我們的中間件里面其實只要再干一件事情就行了，就是調用channel.put將接收的action再發給channel去執行回調就行，所以我們加一行代碼:
// ... 省略前面代碼
const result = next(action);
channel.put(action); // 將收到的action也發給Redux-Saga
return result;
// ... 省略后面代碼
sagaMiddleware.run
前面的put是發出事件，執行回調，可是我們的回調還沒注冊呢，那注冊回調應該在什么地方呢？看起來只有一個地方了，那就是sagaMiddleware.run。簡單來說，sagaMiddleware.run接收一個Generator作為參數，然后執行這個Generator，當遇到take的時候就將它注冊到channel上面去。這里我們先實現take，takeEvery是在這個基礎上實現的。Redux-Saga中這塊代碼是單獨抽取了一個文件，我們仿照這種做法吧。
首先需要在中間件里面將Redux的getState和dispatch等參數傳遞進去，Redux-Saga使用的是bind函數，所以中間件方法改造如下:
function sagaMiddleware({ getState, dispatch }) {
// 將getState, dispatch通過bind傳給runSaga
boundRunSaga = runSaga.bind(null, {
channel,
dispatch,
getState,
})
return function (next) {
return function (action) {
const result = next(action);
channel.put(action);
return result;
}
}
}
然后sagaMiddleware.run就直接將boundRunSaga拿來運行就行了：
sagaMiddleware.run = (...args) => {
boundRunSaga(...args)
}
注意這里的...args，這個其實就是我們傳進去的rootSaga。到這里其實中間件部分就已經完成了，后面的代碼就是具體的執行過程了。
中間件對應的源碼可以看這里：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/middleware.js
runSaga
runSaga其實才是真正的sagaMiddleware.run，通過前面的分析，我們已經知道他的作用是接收Generator並執行，如果遇到take就將它注冊到channel上去，如果遇到put就將對應的回調拿出來執行，但是Redux-Saga又將這個過程分為了好幾層，我們一層一層來看吧。runSaga的參數先是通過bind傳入了一些上下文相關的變量，比如getState, dispatch，然后又在運行的時候傳入了rootSaga，所以他應該是長這個樣子的：
import proc from './proc';
export function runSaga(
{ channel, dispatch, getState },
saga,
...args
) {
// saga是一個Generator，運行后得到一個迭代器
const iterator = saga(...args);
const env = {
channel,
dispatch,
getState,
};
proc(env, iterator);
}
可以看到runSaga僅僅是將Generator運行下，得到迭代器對象后又調用了proc來處理。
runSaga對應的源碼看這里：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/runSaga.js
proc
proc就是具體執行這個迭代器的過程，Generator的執行方式我們之前在另一篇文章詳細講過，簡單來說就是可以另外寫一個方法next來執行Generator，next里面檢測到如果Generator沒有執行完，就繼續執行next，然后外層調用一下next啟動這個流程就行。
export default function proc(env, iterator) {
// 調用next啟動迭代器執行
next();
// next函數也不復雜
// 就是執行iterator
function next(arg, isErr) {
let result;
if (isErr) {
result = iterator.throw(arg);
} else {
result = iterator.next(arg);
}
// 如果他沒結束，就繼續next
// digestEffect是處理當前步驟返回值的函數
// 繼續執行的next也由他來調用
if (!result.done) {
digestEffect(result.value, next)
}
}
}
digestEffect
上面如果迭代器沒有執行完，我們會將它的值傳給digestEffect處理，那么這里的result.value的值是什么的呢？回想下我們前面rootSaga里面的用法
yield takeEvery("FETCH_USER_INFO", fetchUserInfo);
result.value的值應該是yield后面的值，也就是takeEvery("FETCH_USER_INFO", fetchUserInfo)的返回值，takeEvery是再次包裝過的effect，他包裝了take，fork這些簡單的effect。其實對於像take這種簡單的effect來說，比如:
take("FETCH_USER_INFO", fetchUserInfo);
這行代碼的返回值直接就是一個對象，類似於這樣：
{
IO: true,
type: 'TAKE',
payload: {},
}
所以我們這里digestEffect拿到的result.value也是這樣的一個對象，這個對象就代表了我們的一個effect，所以我們的digestEffect就長這樣：
function digestEffect(effect, cb) { // 這個cb其實就是前面傳進來的next
// 這個變量是用來解決競爭問題的
let effectSettled;
function currCb(res, isErr) {
// 如果已經運行過了，直接return
if (effectSettled) {
return
}
effectSettled = true;
cb(res, isErr);
}
runEffect(effect, currCb);
}
runEffect
可以看到digestEffect又調用了一個函數runEffect，這個函數會處理具體的effect:
// runEffect就只是獲取對應type的處理函數，然后拿來處理當前effect
function runEffect(effect, currCb) {
if (effect && effect.IO) {
const effectRunner = effectRunnerMap[effect.type]
effectRunner(env, effect.payload, currCb);
} else {
currCb();
}
}
這點代碼可以看出，runEffect也只是對effect進行了檢測，通過他的類型獲取對應的處理函數，然后進行處理，我這里代碼簡化了，只支持IO這種effect，官方源碼中還支持promise和iterator，具體的可以看看他的源碼：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/proc.js
effectRunner
effectRunner是通過effect.type匹配出來的具體的effect的處理函數，我們先來看兩個：take和fork。
runTakeEffect
take的處理其實很簡單，就是將它注冊到我們的channel里面就行，所以我們建一個effectRunnerMap.js文件，在里面添加take的處理函數runTakeEffect:
// effectRunnerMap.js
function runTakeEffect(env, { channel = env.channel, pattern }, cb) {
const matcher = input => input.type === pattern;
// 注意channel.take的第二個參數是matcher
// 我們直接寫一個簡單的matcher，就是輸入類型必須跟pattern一樣才行
// 這里的pattern就是我們經常用的action名字，比如FETCH_USER_INFO
// Redux-Saga不僅僅支持這種字符串，還支持多種形式，也可以自定義matcher來解析
channel.take(cb, matcher);
}
const effectRunnerMap = {
'TAKE': runTakeEffect,
};
export default effectRunnerMap;
注意上面代碼channel.take(cb, matcher);里面的cb，這個cb其實就是我們迭代器的next，也就是說take的回調是迭代器繼續執行，也就是繼續執行下面的代碼。也就是說，當你這樣寫時：
yield take("SOME_ACTION");
yield fork(saga);
當運行到yield take("SOME_ACTION");這行代碼時，整個迭代器都阻塞了，不會再往下運行。除非你觸發了SOME_ACTION，這時候會把SOME_ACTION的回調拿出來執行，這個回調就是迭代器的next，所以就可以繼續執行下面這行代碼了yield fork(saga)。
runForkEffect
我們前面的示例代碼其實沒有直接用到fork這個API，但是用到了takeEvery，takeEvery其實是組合take和fork來實現的，所以我們先來看看fork。fork的使用跟call很像，也是可以直接調用傳進來的方法，只是call會等待結果回來才進行下一步，fork不會阻塞這個過程，而是當前結果沒回來也會直接運行下一步：
fork(fn, ...args);
所以當我們拿到fork的時候，處理起來也很簡單，直接調用proc處理fn就行了，fn應該是一個Generator函數。
function runForkEffect(env, { fn }, cb) {
const taskIterator = fn(); // 運行fn得到一個迭代器
proc(env, taskIterator); // 直接將taskIterator給proc處理
cb(); // 直接調用cb，不需要等待proc的結果
}
runPutEffect
我們前面的例子還用到了put這個effect，他就更簡單了，只是發出一個action，事實上他也是調用的Redux的dispatch來發出action：
function runPutEffect(env, { action }, cb) {
const result = env.dispatch(action); // 直接dispatch(action)
cb(result);
}
注意我們這里的代碼只需要dispatch(action)就行了，不需要再手動調channel.put了，因為我們前面的中間件里面已經改造了dispatch方法了，每次dispatch的時候都會自動調用channel.put。
runCallEffect
前面我們發起API請求還用到了call，一般我們使用axios這種庫返回的都是一個promise，所以我們這里寫一種支持promise的情況，當然普通同步函數肯定也是支持的：
function runCallEffect(env, { fn, args }, cb) {
const result = fn.apply(null, args);
if (isPromise(result)) {
return result
.then(data => cb(data))
.catch(error => cb(error, true));
}
cb(result);
}
這些effect具體處理的方法對應的源碼都在這個文件里面：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/effectRunnerMap.js
effects
上面我們講了幾個effect具體處理的方法，但是這些都不是對外暴露的effect API。真正對外暴露的effect API還需要單獨寫，他們其實都很簡單，都是返回一個帶有type的簡單對象就行：
const makeEffect = (type, payload) => ({
IO: true,
type,
payload
})
export function take(pattern) {
return makeEffect('TAKE', { pattern })
}
export function fork(fn) {
return makeEffect('FORK', { fn })
}
export function call(fn, ...args) {
return makeEffect('CALL', { fn, args })
}
export function put(action) {
return makeEffect('PUT', { action })
}
可以看到當我們使用effect時，他的返回值就僅僅是一個描述當前任務的對象，這就讓我們的單元測試好寫很多。因為我們的代碼在不同的環境下運行可能會產生不同的結果，特別是這些異步請求，我們寫單元測試時來造這些數據也會很麻煩。但是如果你使用Redux-Saga的effect，每次你代碼運行的時候得到的都是一個任務描述對象，這個對象是穩定的，不受運行結果影響，也就不需要針對這個造測試數據了，大大減少了工作量。
effects對應的源碼文件看這里：https://github.com/redux-saga/redux-saga/blob/master/packages/core/src/internal/io.js
takeEvery
我們前面還用到了takeEvery來處理同時發起的多個請求，這個API是一個高級API，是封裝前面的take和fork來實現的，官方源碼又構造了一個新的迭代器來組合他們，不是很直觀。官方文檔中的這種寫法反而很好理解，我這里采用文檔中的這種寫法:
export function takeEvery(pattern, saga) {
function* takeEveryHelper() {
while (true) {
yield take(pattern);
yield fork(saga);
}
}
return fork(takeEveryHelper);
}
上面這段代碼就很好理解了，我們一個死循環不停的監聽pattern，即目標事件，當目標事件過來的時候，就執行對應的saga，然后又進入下一次循環繼續監聽pattern。
總結
到這里我們例子中用到的API已經全部自己實現了，我們可以用自己的這個Redux-Saga來替換官方的了，只是我們只實現了他的一部分功能，還有很多功能沒有實現，不過這已經不妨礙我們理解他的基本原理了。再來回顧下他的主要要點：
Redux-Saga其實也是一個發布訂閱模式，管理事件的地方是channel，兩個重點API：take和put。take是注冊一個事件到channel上，當事件過來時觸發回調，需要注意的是，這里的回調僅僅是迭代器的next，並不是具體響應事件的函數。也就是說take的意思就是：我在等某某事件，這個事件來之前不許往下走，來了后就可以往下走了。put是發出事件，他是使用Redux dispatch發出事件的，也就是說put的事件會被Redux和Redux-Saga同時響應。Redux-Saga增強了Redux的dispatch函數，在dispatch的同時會觸發channel.put，也就是讓Redux-Saga也響應回調。- 我們調用的
effects和真正實現功能的函數是分開的，表層調用的effects只會返回一個簡單的對象，這個對象描述了當前任務，他是穩定的，所以基於effects的單元測試很好寫。 - 當拿到
effects返回的對象后，我們再根據他的type去找對應的處理函數來進行處理。 - 整個
Redux-Saga都是基於Generator的，每往下走一步都需要手動調用next，這樣當他執行到中途的時候我們可以根據情況不再繼續調用next，這其實就相當於將當前任務cancel了。
本文可運行的代碼已經上傳到GitHub，可以拿下來玩玩：https://github.com/dennis-jiang/Front-End-Knowledges/tree/master/Examples/React/redux-saga
參考資料
Redux-Saga官方文檔：https://redux-saga.js.org/
Redux-Saga源碼地址： https://github.com/redux-saga/redux-saga/tree/master/packages/core/src
文章的最后，感謝你花費寶貴的時間閱讀本文，如果本文給了你一點點幫助或者啟發，請不要吝嗇你的贊和GitHub小星星，你的支持是作者持續創作的動力。
歡迎關注我的公眾號進擊的大前端第一時間獲取高質量原創~
“前端進階知識”系列文章：https://juejin.im/post/5e3ffc85518825494e2772fd
“前端進階知識”系列文章源碼GitHub地址： https://github.com/dennis-jiang/Front-End-Knowledges
