或许你在学习koa/redux时,经常会听到中间件这个词,大概也知道它们通过这种设计模式,使得自定义的中间件(函数)能正确在插入到上下文环境中执行。那它们究竟是怎么实现的呢?本文仅探讨koa/redux是如何设计中间件。中间件是一种实现「关注点分离」的设计模式,该模式有两个特点:
function m1(next) {
console.log("m1");
next();
console.log("v1");
}
function m2(next) {
console.log("m2");
next();
console.log("v2");
}
function m3() {
console.log("m3");
}
如上所示:中间件 m1->m2->m3执行,打印结果为 m1->m2->m3->v2->v1。这种模式有个形象的名字,洋葱模型。但现在我们暂时忘记这些名字,就想想如何实现中间件(函数)的联动吧。有两种思路,第一是递归;第二是链式调用。
设置一个数组按顺序存储函数,根据 index 值,按顺序一个个执行,如下:
const middles = [m1, m2, m3];
function compose(arr) {
function dispath(index) {
if (index === arr.length) return;
const route = arr[index];
const next = () => dispath(index + 1); // 递归执行数组中下一个函数
return route(next);
}
dispath(0);
}
compose(middles); // 打印m1 -> m2 -> m3 -> v2 -> v1
将函数当作成参数传给上一个中间件,这样前一个中间件执行完就可以执行下一个中间件。
m1(() => m2(() => m3())); // 打印m1 -> m2 -> m3 -> v2 -> v1
// m2的参数next是 () => m3(),
// m1的参数next是 () => m2(() => m3())
此种方法虽然可行,但是 m1,m2,m3 都是写死的,不是公共方法。
我们观察到在传递参数时,m3 和 m2 都变成函数再传入,那这个变成函数的过程是否能提取:如下,参数 middle 是中间件,参数 next 是接下来要执行的函数。转换后 next 变成 middle 的参数。
function createFn(middle, next) {
return function() {
middle(next);
};
}
// 需要先将后面的中间件变成我们需要的 next 函数:
const fn3 = createFn(m3, null);
const fn2 = createFn(m2, fn3);
const fn1 = createFn(m1, fn2);
fn1(); // 打印m1 -> m2 -> m3 -> v2 -> v1
这里 fn3/fn2/fn1 也是固定的,但我们看出这些中间状态变量,可以隐藏掉,统一用 next 代替:
let next = () => {};
next = createFn(m3, null);
next = createFn(m2, next);
next = createFn(m1, next);
next(); // 打印m1 -> m2 -> m3 -> v2 -> v1
优化如下:
let next = () => {};
// 倒序
for (let i = middles.length; i >= 0; i--) {
next = createFn(middles[i], next);
}
next(); // 打印m1 -> m2 -> m3 -> v2 -> v1
仔细观察上面这种倒序,且每次拿上次的值进行计算的方法,是不是很像 reduceRight。(好吧,或许我们看不出来,但是早期 redux 就是这么实现的,我们直接拿过来研究):
const middles = [m1, m2, m3];
function compose(arr) {
return arr.reduceRight(
(a, b) => {
// b是middle,a是next,
return () => b(a); // 每次返回的是一个函数,执行这个函数为middle(next),即b(a)
},
() => {} // 初始化的a值,空函数
);
}
const mid = compose(middles);
mid(); // 打印m1 -> m2 -> m3 -> v2 -> v1
const middles = [m1, m2, m3];
function compose(arr) {
return arr.reduce((a, b) => {
return (...arg) => a(() => b(...arg)); // a 是 next函数,b是middle函数
});
}
const mid = compose(middles);
mid(); // 打印m1 -> m2 -> m3 -> v2 -> v1
改成这种正序的方式,反而不好理解。尝试解释一下:a 是 next 函数,b 是 middle 函数。(...arg) => a(() => b(...arg)) 这简直就是我们最初这种写法 m1(() => m2(() => m3())) 的直接映射。摘抄一下这篇参考一作者的解释,感兴趣的同学可自行推导一下:
// 第 1 次 reduce 的返回值,下一次将作为 a
arg => fn1(() => fn2(arg));
// 第 2 次 reduce 的返回值,下一次将作为 a
arg => (arg => fn1(() => fn2(arg)))(() => fn3(arg));
// 等价于...
arg => fn1(() => fn2(() => fn3(arg)));
// 执行最后返回的函数连接中间件,返回值等价于...
fn1(() => fn2(() => fn3(() => {})));
明白reduceRight到reduce转换不是最关键的,关键的是明白上面几种写法让我们能链式调用函数。
设计一个中间件模式,怎么能少得了参数的传递。我们先想想如何组织我们中间件:很明显,我们通过 next 执行下个中间件,那么传值给下个中间件就是给 next 添加参数:
function m1(next) {
console.log("m1");
next("v2"); // 将'v2'传给下个中间件m2
}
那么 m2 该怎么获取这个值呢?因为 next 代表 m2 执行后的值,next 传递参数就是说 m2 需要返回函数,该函数的参数就是传递的值,如下:
function m2(next) {
return function(action) {
// 这个action就是上一个函数传来的'v2'
next(action);
};
}
这种写法等价于:
const m2 = next => action => {
next(action);
};
所以按照上面这种方式组织我们的中间件,我们就既能链式执行又能传递参数。如下:
const m1 = next => action => {
console.log("m1", action);
next(action);
};
const m2 = next => action => {
console.log("m2", action);
next(action);
};
const m3 = next => action => {
console.log("m3", action);
};
那我们如何实现呢?
m1(arg => m2(() => m3()(arg))(arg))("666");
// 打印:m1,m2,m3都打印666
createFn返回的函数添加了参数action,代表了中间件之间的参数。
// 我们给返回的函数加上参数action并执行
function createFn(middle, next) {
return function (action) {
middle(next)(action);
}
}
const middles = [m1, m2, m3];
let next = () => {};
for (let i = middles.length - 1; i >= 0; i--) {
next = createFn(middles[i], next);
}
next("666"); // 打印:m1,m2,m3都打印666
返回的结果直接执行,因为我们加了一层返回函数
const middles = [m1, m2, m3];
function compose(arr) {
return arr.reduceRight(
(a, b) => b(a), // 注意这里,上个版本返回的是函数() => b(a);这个版本变成b(a),直接执行了,原因是我们中间件返回函数,所以这里需要将其执行
() => {}
);
}
const mid = compose(middles);
mid("666"); // 打印:m1,m2,m3都打印666
现在我们完成了中间件的链式调用和参数传递,已完成一个简单的中间件。但是如果我们这里不是普通的中间价,而是 redux 的中间件。我们想要这些中间件都拥有一个初始化的 store,该如何处理呢?熟悉 redux 的朋友肯定知道中间件最后写成这样:
const m1 = store => next => action => {
console.log("store1", store);
next(action);
};
const m2 = store => next => action => {
console.log("store2", store);
next(action);
};
const m3 = store => next => action => {
console.log("store3", store);
};
我们还是按照上面几个步骤来实现一下,最后讲讲为什么能这么设计:
const store = { name: "redux" };
// 基本写法,我们将参数传给每个中间件
m1(arg => m2(() => m3()(arg))(arg))(store);
const store = { name: "redux" };
const middles = [m1, m2, m3];
const middlesWithStore = middles.map(middle => middle(store)); // 这里执行了第一遍,将store传进来
function createFn(middle, next) {
return action => middle(next)(action);
}
let next = () => () => {};
for (let i = middlesWithStore.length - 1; i >= 0; i--) {
next = createFn(middlesWithStore[i], next);
}
next(store); // 打印:store1,store2,store3 { name: 'redux' }
const store = { name: "redux" };
const middles = [m1, m2, m3];
const middlesWithStore = middles.map(middle => middle(store)); // 这里执行了第一遍,将store传进来
function compose(arr) {
return arr.reduce((a, b) => (...args) => a(b(...args)));
}
const mid = compose(middlesWithStore)();
mid(store); // 打印:store1,store2,store3 { name: 'redux' }
这里看起来简单,就是先执行一遍中间件,但为什么可以先执行一次函数将数据(store)传进去?而且这个数据在后来的调用中能被访问到?这背后涉及到的基础知识是函数柯里化和闭包:
柯里化是使用匿名单参数函数来实现多参数函数的方法。
const m1 = store => next => action => {
console.log("store1", store);
next(action);
};
上面这种写法,我们说是将中间件 m1 柯里化了,它的特点是每次只传一个参数,返回的是新的函数。返回新函数这个特点很重要,因为函数可以在其他地方再调用,所以本来一个连续的动作被打断了,变成了可以延迟执行,也可以称为参数前置。当我们执行:
const middlesWithStore = middles.map(middle => middle(store));
相当于给每个中间件都添加了 store 属性,而且返回的是函数,可以等到你需要用它的时候再去使用。这就是柯里化的好处。
闭包:函数与其自由变量组成的环境,自由变量指不存在函数内部的变量。当函数按照值传递的方式在其他地方被调用时,产生了闭包。
上面的 m1 可以写成下面这种格式,可以知道柯里化中间函数处于同一闭包,所以尽管我们是在其他地方调用了 next(action),但还是保存了最开始初始化的作用域,实现了真正的函数分开执行。
return function(next) {
return function(action) {
console.log("store1", store);
next(action);
};
};
}
可以说我们整个中间件的设计就是建构在返回函数形成闭包这种柯里化特性上。它让我们缓存参数,分开执行,链式传递参数调用。所以 redux 中能提前注入 store,能有效传递 action。可以说koa/redux的中间件机制是闭包/柯里化的经典的实例。
https://juejin.im/post/5bbdcf05e51d450e6c750693
https://zhuanlan.zhihu.com/p/35040744
https://zhuanlan.zhihu.com/p/20597452
https://github.com/brickspert/blog/issues/22
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8