Redux 中间件机制探底

状态管理方案之前仅仅接触过 Vuex, 使用 React 开发时，难免要调研一下 React 技术栈下的状态管理方案，发现有 Redux 和 Mobx 相关流派。以下内容仅针对 Redux 展开讨论。

在使用 Redux 的过程中发现，有这么几个知识点还是比较容易接受：

1. 对状态的修改必须 dispatch 一个 action, 保证状态的修改可控易管理
2. reducer 必须是一个纯函数，不能对 state 直接进行修改，而是每次返回一个全新的 state。纯函数的实现可以提高运行效率，固定的输入产生固定的输出
3. redux 本身有一个「订阅」的概念，状态更改后， Redux 会将依次执行订阅者，在订阅者的事件回调函数中可以通过 store.getState() 拿到最新的状态

此时有这样一个疑问： 上面仅仅讨论了一个同步的情况，对于一些异步以及存在其他副作用的 action 产生过程如何处理，带着这个疑问，看了官方文档以及一些 Demo 实现。这个过程出现了 redux-thunk、redux-promise、 redux-saga 等处理方案。这些又是做什么的，分别都解决了什么问题？

这就要讨论一下 Redux 的中间件机制，在 Redux 中有这样一个 API, applyMiddleware, 主要用于注册 Redux 中的中间件。

阅读文档的过程中，主要搞清楚了一个最基本的世界观问题： Redux 的中间件是用来做什么的？它提供的是位于 action 被发起之后，到达 reducer 之前的扩展点。 也就是以上讨论的 redux-thunk、redux-promise、redux-saga 等都是一个个的 Redux 的中间件，使用时需要在 Redux createStore 时注册，他们分别增强了 Redux dispatch 的能力。同样可以理解为：在应用这些中间件后，使用的 dispatch 已经不是 Redux 原本的 dispatch，都是经这些中间件改写后的 dispatch。这样我们就能再真正产生 action 之前做一些副作用的封装。

以 redux-thunk 为例，我们可以清晰的的看清楚这个过程。

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => (next) => (action) => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

以上就是 redux-thunk 这个库的源码部分，「短小精悍」这个词来形容这个库一点都不过分了。究其实现，可以发现，redux-thunk 这个中间件主要是提供了 dispatch 一个 function 的能力。正常来说 Redux 的 dispatch 仅仅能 dispatch 一个纯js对象，也就是 action。 使用 redux-thunk 后，我们可以接收一个 function， 这个 function 会被得到调用，并被传入 dispatch 这个参数，真正的 dispatch 发生在这个 function 内部。

至于 Redux 的中间件机制是如何实现的，在看了其源码实现后，更是巧妙。

首先我们要明确一下 「中间件」 这个概念。个人粗俗理解：中间件就是一个「管道」，只要你过了这个「管道」，都会被这个「管道」接管，「管道」不会拦住不放，而是将你「蹂躏」一番再放了你，当然也有可能不「蹂躏」你，顶多查一下户口(传说中的日志中间件)。凡是经「蹂躏」过的不管是从精神上、还是肉体上都不再是原来的你我，可能是一蹶不振，也可能是奋发图强。

有了以上的理解，当我们在看这个事情的时候就好理解了。可能会有多个中间件，只要进了这个「屋」，就要依次经历这些中间件。

const reduxMiddleware = ({dispatch, getState}) => (next) => (action) => {
  // 做一些查户口以及蹂躏相关的事情 
  
  // 放行
  return next(action);
}

这是一个 redux middleware 的通用实现。当我们在 applyMiddleware 时发生了什么？

const chain = middlewares.map(middleware => middleware({
  getState: store.getState,
  dispatch: (action, ...args) => dispatch(action, ...args),
}));

const dispatch = compose(chain)(store.dispatch);
return {
  ...store,
  dispatch
}

大致意思就是将所有的 middleware 传入，并通过 compose 这个函数将所有的中间件组合并返回一个 dispatch 函数， 此时的 dispatch 不是 redux 原本的 dispatch 实现，而是一个经中间件增强了的 dispatch，这里面有一个控制权的反转，即将原本的 dispatch 功能作为参数传入，在函数内部完成 dispatch 的逻辑。此时的 dispatch 可能是这样的：

const dispatch = (dispatch) => {
  // do things
  // 这里经过了所有注册过的中间件的处理
  // do things
  return action => dispatch(action);
}

Redux 中间件实现的关键是 compose 函数，compose 函数利用 Array.prototype.reduce() API，完成所有中间件函数的依次调用，并返回如上所示的一个函数。

function compose(funcs) {
  return function (dispatch) {
    if (funcs.length === 1) {
      return funcs[0];
    }
    return funcs.reduce((a,b) => (...args) => a((b(...args))));
  }
}

如上便是整个中间件机制的实现过程。因为中间涉及到一些函数柯里化的内容，有些函数嵌套较深才能返回，如果感觉到晦涩，可以看这个简洁版的代码：

// 这是一个中间件
const a = (next) => (action) => {
  console.log('经过了 a 中间件的蹂躏');
  return next(action);
};

// 这是一个中间件
const b = (next) => (action) => {
  console.log('经过了 b 中间件的蹂躏');
  return next(action);
};

// 这是一个中间件
const c = (next) => (action) => {
  console.log('经过了 c 中间件的蹂躏');;
  return next(action);
};

// 原版的 dispatch
var rawDispatch = (action) => {
  console.log('终于轮到原生的dispatch action了，派发了： ', action);
  return action;
}

/** 以下是 applyMiddlware 的实现原理， 开始注册中间件 */
var arr = [a, b, c];

var res = arr.reduce((a, b) => (...args) => a(b(...args)));

var enhanceDispatch = res(rawDispatch);


// 调用一个增强的dispatch，会发现中间件逻辑会一次处理
enhanceDispatch('add');

// 经过了 a 中间件的蹂躏
// 经过了 b 中间件的蹂躏
// 经过了 c 中间件的蹂躏
// 终于轮到原生的 dispatch action了，派发了：  add
// "add"

参考链接：

1. https://www.redux.org.cn/docs/advanced/Middleware.html