id: middleware title: Middleware 中间件 description: ‘原理 > Middleware 中间件：如何使用中间件来扩展 Redux store 的能力’

hide_title: false

Middleware 中间件

在 “Redux 深入浅出” 教程中 你已经学习过中间件的实践案例。如果你使用过服务端框架像 Express 或 Koa，你或许已经熟悉 middleware 的概念。在这些框架中，中间件可以让你在接收请求和生成响应之间放置的一些代码。例如，Express 或 Koa 中间件可能会添加 CORS 标头、记录日志、压缩等。中间件的最大特点是它可以组合成一个链。您可以在一个项目中使用多个不同的中间件。

Redux 中间件解决的问题与 Express 或 Koa 中间件不同，但在概念上是相似的。它在 dispatch action 和到达 reducer 的那一刻之间提供了逻辑插入点。可以使用 Redux 中间件进行日志记录、异常监控、与异步 API 对话、路由等。

本文分成几部分来让你深入了解它的概念，以及几个实际例子在最后展示中间件的威力。这些例子可能需要来回看，这样你会在无聊和灵感间切换。

理解 Middleware

虽然中间件可用于多种用途，包括异步 API 调用，但了解它的来源的原因非常重要。我们将通过“日志记录”和“异常监控”作为示例，来一步步引导你知道中间件产生背后的过程。

问题：日志

Redux 的好处之一是它使状态的变更变得可预测且透明。每次 dispatch action 时，都会计算并保存新状态。状态不能自行改变，它只能作为特定 action 的结果而改变。

如果我们记录应用程序中发生的每个 action 调用前后的状态，不是很好吗？当出现问题时，我们可以回溯日志，并找出哪个 action 导致了问题。

Middleware 中间件 - 图1

我们如何用 Redux 解决这个问题？

尝试 #1：手动打日志

最简单的解决方案是每次调用 store.dispatch(action) 时手动记录 action 和下一个状态。这并不是真正的解决方案，而只是了解问题的第一步。

注意

使用 react-redux 或类似的绑定，可能无法直接访问组件中的 store 实例。在接下来的几段中，假设您明确地传递了 store。

比如说，这样来创建 todo：

  1. store.dispatch(addTodo('Use Redux'))

要记录 action 和状态，您可以将代码改成这样：

  1. const action = addTodo('Use Redux')
  3. console.log('dispatching', action)
  4. store.dispatch(action)
  5. console.log('next state', store.getState())

这会产生所需的效果，但您不想每次都这样做。

尝试 #2: 包裹 dispatch

您可以写个函数来记录日志：

  1. function dispatchAndLog(store, action) {
  2.   console.log('dispatching', action)
  3.   store.dispatch(action)
  4.   console.log('next state', store.getState())
  5. }

然后你可以在任何地方使用它而不是store.dispatch()：

  1. dispatchAndLog(store, addTodo('Use Redux'))

我们可以到此结束，但是每次都导入一个特殊函数不是很方便。

尝试 #3: 给 dispatch 做猴子补丁（Monkeypatch）

如果我们直接重写 store 实例上的 dispatch 函数怎么样？store 本身是带有 一些方法 的普通对象，因为是 JavaScript，所以我们可以直接对 dispatch 函数进行猴子补丁：

  1. const next = store.dispatch
  2. store.dispatch = function dispatchAndLog(action) {
  3.   console.log('dispatching', action)
  4.   let result = next(action)
  5.   console.log('next state', store.getState())
  6.   return result
  7. }

这已经非常接近我们想要的了！无论我们在何处 dispatch action，它都保证被记录。Monkeypatching 从来都不是正确的，但我们现在可以忍受它。

问题: 异常监控

如果需要对 dispatch 做多个这样的转换怎么办？

我想到的另一个有用的转换场景是记录生产环境中的 JavaScript 错误。全局 window.onerror 事件不可靠，因为它在一些旧浏览器中不提供堆栈信息，这对于理解错误发生的原因至关重要。

想一下这样会更好，每当 dispatch action 抛出错误时，我们都将错误发送给异常监控服务器，例如 Sentry 和堆栈，这不是很有用吗？记录导致错误的 action 以及当前状态？这样，在开发环境中重现错误要容易得多。

但是，将日志记录和异常监控分开是很重要的。理想情况下，我们希望它们属于不同的模块，可能在不同的包中。否则，我们就无法在不同的应用中复用。（提示：我们正在慢慢了解什么是中间件！）

如果日志记录和异常监控是分开的工具函数，它们可能长这样：

  1. function patchStoreToAddLogging(store) {
  2.   const next = store.dispatch
  3.   store.dispatch = function dispatchAndLog(action) {
  4.     console.log('dispatching', action)
  5.     let result = next(action)
  6.     console.log('next state', store.getState())
  7.     return result
  8.   }
  9. }
  11. function patchStoreToAddCrashReporting(store) {
  12.   const next = store.dispatch
  13.   store.dispatch = function dispatchAndReportErrors(action) {
  14.     try {
  15.       return next(action)
  16.     } catch (err) {
  17.       console.error('Caught an exception!', err)
  18.       Raven.captureException(err, {
  19.         extra: {
  20.           action,
  21.           state: store.getState()
  22.         }
  23.       })
  24.       throw err
  25.     }
  26.   }
  27. }

如果这些函数作为单独的模块发布，我们稍后可以使用它们来装饰我们的 store：

  1. patchStoreToAddLogging(store)
  2. patchStoreToAddCrashReporting(store)

尽管如此，这并不好。

尝试 #4: 隐藏猴子补丁

打猴子补丁是一种 Hack（不推荐）的方式。“替换任何你喜欢的方法”，那是一种什么样的API？让我们找出它的本质。以前，我们的函数替换了store.dispatch。如果他们 返回 新的 dispatch 函数怎么样？

  1. function logger(store) {
  2.   const next = store.dispatch
  4.   // Previously:
  5.   // store.dispatch = function dispatchAndLog(action) {
  7.   return function dispatchAndLog(action) {
  8.     console.log('dispatching', action)
  9.     let result = next(action)
  10.     console.log('next state', store.getState())
  11.     return result
  12.   }
  13. }

我们可以在 Redux 中提供一个 helper 来帮助我们做猴子补丁：

  1. function applyMiddlewareByMonkeypatching(store, middlewares) {
  2.   middlewares = middlewares.slice()
  3.   middlewares.reverse()
  5.   // 依次调用每个 middleware 来增强 dispatch
  6.   middlewares.forEach(middleware => (store.dispatch = middleware(store)))
  7. }

我们可以使用它来调用多个中间件，如下所示：

  1. applyMiddlewareByMonkeypatching(store, [logger, crashReporter])

然而，它仍然是猴子补丁。 我们将它隐藏在库中的事实并没有改变这一事实。

尝试 #5: 移除猴子补丁

为什么每次都需要覆盖 dispatch 呢？很简单，为了以后能够调用它，但还有另外一个原因：这样每个中间件都可以访问（和调用）之前包裹的 store.dispatch：

  1. function logger(store) {
  2.   // Must point to the function returned by the previous middleware:
  3.   const next = store.dispatch
  5.   return function dispatchAndLog(action) {
  6.     console.log('dispatching', action)
  7.     let result = next(action)
  8.     console.log('next state', store.getState())
  9.     return result
  10.   }
  11. }

必须要链式调用中间件！

如果 applyMiddlewareByMonkeypatching 在处理第一个中间件后没有立即覆盖掉原来的 store.dispatch，store.dispatch 将继续指向原始的 dispatch 函数。那么第二个中间件也会绑定到原来的 dispatch 函数上。

但是还有一种不同的方式来做链式调用。中间件来接受 next() 调度函数作为参数，而不是从 store 实例中读取它。

  1. function logger(store) {
  2.   return function wrapDispatchToAddLogging(next) {
  3.     return function dispatchAndLog(action) {
  4.       console.log('dispatching', action)
  5.       let result = next(action)
  6.       console.log('next state', store.getState())
  7.       return result
  8.     }
  9.   }
  10. }

这是一个 “我们需要更深入” 的时刻，所以这可能需要一段时间来理解。函数级联感觉很吓人。ES6 箭头函数使这个 轲里化 更易读：

  1. const logger = store => next => action => {
  2.   console.log('dispatching', action)
  3.   let result = next(action)
  4.   console.log('next state', store.getState())
  5.   return result
  6. }
  8. const crashReporter = store => next => action => {
  9.   try {
  10.     return next(action)
  11.   } catch (err) {
  12.     console.error('Caught an exception!', err)
  13.     Raven.captureException(err, {
  14.       extra: {
  15.         action,
  16.         state: store.getState()
  17.       }
  18.     })
  19.     throw err
  20.   }
  21. }

这正是 Redux 中间件的样子。

现在中间件接受 next() dispatch 函数，并返回新的 dispatch 函数，该函数又充当左侧中间件的 next()，依此类推。仍然可以在需要的时候调用 store 方法（如 getState()），因此 store 作为顶级参数传入在这里仍然可用。

尝试 #6：简单粗暴的中间件调用方法

为了替代 applyMiddlewareByMonkeypatching()，我们可以编写 applyMiddleware()，它先计算出最终的、被所有 middleware 包裹后的 dispatch() 函数，并使用它返回 store 的副本：

  1. // 注意：这是简单粗暴的中间件调用方法
  2. // 并 *不是* Redux API 真实的实现方法。
  3. function applyMiddleware(store, middlewares) {
  4.   middlewares = middlewares.slice()
  5.   middlewares.reverse()
  6.   let dispatch = store.dispatch
  7.   middlewares.forEach(middleware => (dispatch = middleware(store)(dispatch)))
  8.   return Object.assign({}, store, { dispatch })
  9. }

Redux 内置的 applyMiddleware() 的实现是相似的，但在三个重要方面不同：

  • 它只向中间件公开 store API 的一个子集：dispatch(action) 和 getState()。

  • 确保如果您从中间件调用 store.dispatch(action) 而不是 next(action)，该 action 实际上将再次遍历整个中间件链，包括当前的中间件，这需要一些技巧。这对异步中间件很有用。在配置 Redux 期间调用 dispatch 时有一个警告，后面会讲。

  • 为确保您只能应用一次中间件，它在 createStore() 上运行，而不是在 store 本身上运行。它的函数签名不是(store, middlewares) => store，而是(...middlewares) => (createStore) => createStore。

因为在使用 createStore() 之前将函数应用到它是很麻烦的，createStore() 的最后一个参数作为可选的来指定这样的函数。

警告：在配置 Redux 期间调用 dispatch

当 applyMiddleware 执行并配置你的中间件时，store.dispatch 函数将指向 createStore 提供的最初版本。这个时候的 dispatch 还不会经过任何 middleware。如果您期望在配置期间与另一个中间件进行交互，您可能会感到失望。由于这种意外行为，在配置完成之前如果 dispatch 了 action，applyMiddleware 将抛出错误。解法是，你应该通过一个公共对象（例如做 API 请求的中间件，那就直接用 API 请求的对象）直接与其他中间件通信，或者放到中间件配置完后的回调函数中等待执行。

最后的实现

鉴于这个中间件，我们刚刚写道：

  1. const logger = store => next => action => {
  2.   console.log('dispatching', action)
  3.   let result = next(action)
  4.   console.log('next state', store.getState())
  5.   return result
  6. }
  8. const crashReporter = store => next => action => {
  9.   try {
  10.     return next(action)
  11.   } catch (err) {
  12.     console.error('Caught an exception!', err)
  13.     Raven.captureException(err, {
  14.       extra: {
  15.         action,
  16.         state: store.getState()
  17.       }
  18.     })
  19.     throw err
  20.   }
  21. }

以下是如何将其应用于 Redux store ：

  1. import { createStore, combineReducers, applyMiddleware } from 'redux'
  3. const todoApp = combineReducers(reducers)
  4. const store = createStore(
  5.   todoApp,
  6.   // applyMiddleware() tells createStore() how to handle middleware
  7.   applyMiddleware(logger, crashReporter)
  8. )

就是这样！现在，dispatch 到 store 的所有 action 都会调用 logger 和 crashReporter 这2个中间件：

  1. // Will flow through both logger and crashReporter middleware!
  2. store.dispatch(addTodo('Use Redux'))

Seven Examples

如果您在阅读上述部分时头脑发热，请想象一下编写它是什么感觉。本节旨在让您和我放松身心，并有助于让您的头脑开窍。

下面的每个函数都是一个有效的 Redux 中间件。它们并不同样有用，但都同样有趣。

  1. /**
  2.  * 日志打印每个 dispatch 的 action 和调用后的状态
  3.  */
  4. const logger = store => next => action => {
  5.   console.group(action.type)
  6.   console.info('dispatching', action)
  7.   let result = next(action)
  8.   console.log('next state', store.getState())
  9.   console.groupEnd()
  10.   return result
  11. }
  13. /**
  14.  * 报错的时候发送异常报告
  15.  */
  16. const crashReporter = store => next => action => {
  17.   try {
  18.     return next(action)
  19.   } catch (err) {
  20.     console.error('Caught an exception!', err)
  21.     Raven.captureException(err, {
  22.       extra: {
  23.         action,
  24.         state: store.getState()
  25.       }
  26.     })
  27.     throw err
  28.   }
  29. }
  31. /**
  32.  * 一个定时器，使用 { meta: { delay: N } } 安排 action 延迟 N 毫秒后调用。
  33.  * 让 `dispatch` 返回一个取消定时器的函数。
  34.  */
  35. const timeoutScheduler = store => next => action => {
  36.   if (!action.meta || !action.meta.delay) {
  37.     return next(action)
  38.   }
  40.   const timeoutId = setTimeout(() => next(action), action.meta.delay)
  42.   return function cancel() {
  43.     clearTimeout(timeoutId)
  44.   }
  45. }
  47. /**
  48.  * 另一个定时器，使用 { meta: { raf: true } } 让 action 在 rAF 循环内调用。
  49.  * 让 `dispatch` 返回一个删除 action 的函数
  50.  */
  51. const rafScheduler = store => next => {
  52.   const queuedActions = []
  53.   let frame = null
  55.   function loop() {
  56.     frame = null
  57.     try {
  58.       if (queuedActions.length) {
  59.         next(queuedActions.shift())
  60.       }
  61.     } finally {
  62.       maybeRaf()
  63.     }
  64.   }
  66.   function maybeRaf() {
  67.     if (queuedActions.length && !frame) {
  68.       frame = requestAnimationFrame(loop)
  69.     }
  70.   }
  72.   return action => {
  73.     if (!action.meta || !action.meta.raf) {
  74.       return next(action)
  75.     }
  77.     queuedActions.push(action)
  78.     maybeRaf()
  80.     return function cancel() {
  81.       queuedActions = queuedActions.filter(a => a !== action)
  82.     }
  83.   }
  84. }
  86. /**
  87.  * 让你可以直接 dispatch promise 作为 action。
  88.  * 如果 promise 执行成功，它的结果将作为一个 action 发送。
  89.  * `dispatch` 返回的也是 promise，这样如果出错也能处理。
  90.  */
  91. const vanillaPromise = store => next => action => {
  92.   if (typeof action.then !== 'function') {
  93.     return next(action)
  94.   }
  96.   return Promise.resolve(action).then(store.dispatch)
  97. }
  99. /**
  100.  * 允许您 dispatch 带有 { promise } 字段的特殊 action。
  101.  *
  102.  * 这个中间件会在一开始就把它们变成一个单一的 action ，
  103.  * 以及当 `promise` 成功时再 dispatch 一个成功（或失败）的 action 。
  104.  *
  105.  * 为方便起见，`dispatch` 将返回 promise 以便调用者可以继续 then。
  106.  */
  107. const readyStatePromise = store => next => action => {
  108.   if (!action.promise) {
  109.     return next(action)
  110.   }
  112.   function makeAction(ready, data) {
  113.     const newAction = Object.assign({}, action, { ready }, data)
  114.     delete newAction.promise
  115.     return newAction
  116.   }
  118.   next(makeAction(false))
  119.   return action.promise.then(
  120.     result => next(makeAction(true, { result })),
  121.     error => next(makeAction(true, { error }))
  122.   )
  123. }
  125. /**
  126.  * 让你 dispatch 函数而不是 action 对象。
  127.  * 此函数将接收 `dispatch` 和 `getState` 作为参数。
  128.  *
  129.  * 用于提前退出（使用 `getState()` 的条件判断），以及
  130.  * 用于异步控制流（它可以 `dispatch()` 别的东西）。
  131.  *
  132.  * `dispatch` 将返回被调度函数的返回值。
  133.  */
  134. const thunk = store => next => action =>
  135.   typeof action === 'function'
  136.     ? action(store.dispatch, store.getState)
  137.     : next(action)
  139. // 您可以使用以上所有中间件！（这并不意味着你应该。）
  140. const todoApp = combineReducers(reducers)
  141. const store = createStore(
  142.   todoApp,
  143.   applyMiddleware(
  144.     rafScheduler,
  145.     timeoutScheduler,
  146.     thunk,
  147.     vanillaPromise,
  148.     readyStatePromise,
  149.     logger,
  150.     crashReporter
  151.   )
  152. )