上一篇文章咱们剖析了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.jsimport { 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后// 还须要手动启动他来运行rootSagasagaMiddleware.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.jsconst 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;

通过这个例子的代码构造咱们能够看出：

  1. action被分为了两种，一种是触发异步解决的，一种是一般的同步action。
  2. 异步action应用Redux-Saga来监听，监听的时候能够应用takeLatest或者takeEvery来解决并发的申请。
  3. 具体的saga实现能够应用Redux-Saga提供的办法，比方call，put之类的，能够让单元测试更好写。

  4. 一个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就是咱们明天手写的指标:

  1. createSagaMiddleware：这个办法会返回一个中间件实例sagaMiddleware
  2. sagaMiddleware.run: 这个办法是真正运行咱们写的saga的入口
  3. takeEvery：这个办法是用来管制并发流程的
  4. call：用来调用其余办法
  5. 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中间件的范式了：

  1. 一个中间件接管store作为参数，会返回一个函数
  2. 返回的这个函数接管老的dispatch函数作为参数(也就是下面的next)，会返回一个新的函数
  3. 返回的新函数就是新的dispatch函数，这个函数外面能够拿到里面两层传进来的store和老dispatch函数

按照这个范式以及后面对createSagaMiddleware的应用，咱们能够先写出这个函数的骨架：

// sagaMiddlewareFactory其实就是咱们里面应用的createSagaMiddlewarefunction 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：

  1. takeEvery(action, callback)：他接管的参数就是action和callback，而且咱们在根saga外面可能会屡次调用它来注册不同action的处理函数，这其实就相当于往解决核心外面塞入事件了。
  2. 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-Sagareturn 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的处理函数，而后拿来解决以后effectfunction 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.jsfunction 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来替换官网的了，只是咱们只实现了他的一部分性能，还有很多性能没有实现，不过这曾经不障碍咱们了解他的基本原理了。再来回顾下他的次要要点：

  1. Redux-Saga其实也是一个公布订阅模式，治理事件的中央是channel，两个重点API：take和put。
  2. take是注册一个事件到channel上，当事件过去时触发回调，须要留神的是，这里的回调仅仅是迭代器的next，并不是具体响应事件的函数。也就是说take的意思就是：我在等某某事件，这个事件来之前不许往下走，来了后就能够往下走了。
  3. put是收回事件，他是应用Redux dispatch收回事件的，也就是说put的事件会被Redux和Redux-Saga同时响应。
  4. Redux-Saga加强了Redux的dispatch函数，在dispatch的同时会触发channel.put，也就是让Redux-Saga也响应回调。
  5. 咱们调用的effects和真正实现性能的函数是离开的，表层调用的effects只会返回一个简略的对象，这个对象形容了当前任务，他是稳固的，所以基于effects的单元测试很好写。
  6. 当拿到effects返回的对象后，咱们再依据他的type去找对应的处理函数来进行解决。
  7. 整个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小星星，你的反对是作者继续创作的能源。

作者博文GitHub我的项目地址： https://github.com/dennis-jiang/Front-End-Knowledges

我也搞了个公众号[进击的大前端]，不打广告，不写水文，只发高质量原创，欢送关注~