聊聊 Redux 和 Koa 的中间件

何为中间件

我理解的中间件是一种可以将数据进行管道化处理的编程技术，每一个中间件负责处理一部分数据，最终组合成一条具备数据处理能力的管道。这种编程技术最先可能来自于函数式编程领域，在前端技术领域中最知名的应用案例当属于 Redux 和 Koa 这两个库，网上有不少分析两个库关于中间件的源码实现，但鲜有文章分析二者设计上的区别，因而就有了这篇聊聊

中间件管道的设计

Redux

若是你探究过二者的源码，应该不难发现一样是中间件，可是二者在构建中间件管道上采用了两种不一样的编程技术，Redux 使用的是源于 reduce 函数，经过特定的中间件函数签名，将中间件函数不断合并最终变成一个阶梯式的嵌套函数，这个嵌套函数就是被包装过的 dispatch ，有意思的是，若是中间内部调用了 dispatch 则整个嵌套函数会被从新执行，这个特性保证了全部中间件的有序执行，但若是你的中间件中有异步代码，那就会变得有点不如预期，甚至有点糟糕了，由此咱们能够获得一个设计上的结论，Redux 的中间件管道是同步处理全部的数据，同时它也支持重置整个处理流程，实现上经过函数嵌套而非递归，执行顺序上有颇有意思，第一个中间件的next函数的以前的代码最早执行，next函数以后的代码则最后执行，整个中间件管道实际上是基于next函数链的一个环形管道，能够获得以下这张图。

Koa

相比 Redux 中间件的复杂机制，Koa 实现上就简单多了，很是直接的递归实现，而后就是对中间件函数的一些限制，好比不能调用两次的 next, 否则就给你一个大大的 Error ：-{ ，同时为了解决异步中间件的问题， Koa 引入了 async/await，从执行机制上抹平了同步异步代码的差别， 固然前提是你按照规范书写你的代码，不一样于 Redux 的中间经过传递处理后的 action 的击鼓传花，Koa 经过向全部中间件注入 ctx 对象完成数据的处理。

让咱们总结下

从 Redux 的角度，中间件的机制是为了扩展 action 装载数据的能力，毕竟在 FLUX 架构中，action 很是简单却又极其重要，正由于 action 被设计的很简单，当咱们须要完成复杂的功能，就须要一种强大的扩展 action 能力，可以让 action 装载不一样类型的数据，甚至是函数，从而将整个应用的数据流可以管理起来，而不至于由于 action 没法装载某种数据，致使数据流的泄露。这种设计理念也一样适用于对 Redux 中间件的设计， 当咱们考虑将某些通用的功能或者业务放在 Redux 中间件中去实现和处理的时候，不该该将中间件定义为某种业务功能，而应该从 action 的角度去设计中间件，从处理全部的 action 和 处理某种具备明确语义的 action 这两点来设计咱们的中间件，即中间件自己存在两种大的类型

• 全局 action 处理，例如 logger
• 具备明确语义的 action 处理，可分为两类
  • 业务型， 例如 埋点的处理
  • 功能型， 例如 thunk， promise

不一样于 Redux 只传递一个 action，Koa 要处理的是一对 Req/Res 数据模型，它的类型是不可变的，即咱们不能设计说有一种全局的 Req/Res，有一种业务的，咱们会说 Koa 的中间件有全局的，业务的，由于设计的重点在于中间件而不是中间件处理的数据，因此 Req/Res 就能够做为 ctx 的一部分红为中间件管道的上下文， 而咱们设计 Koa 中间件的时候，就会把关注点放在中间件自己，而不是像 Redux 那样先考虑 action 的类型， 再定义中间件，因此 Redux 和 Koa 中间件的最大区别，我想用一句话就足以归纳了。

In Reudx is ActionMiddleware，In Koa is Middleware

打个小广告：挖财 无线 & 前端团队求贤若渴，若是你喜欢各类新奇的 Cool 的技术，喜欢捣鼓各类工具， 喜欢研究架构，本团队提供各类环境和机会，欢迎简从来投，流程超快，当天出签，急速入职！！！