-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
深入浅出 Koa2 原理 #9
Comments
。。。。编译之后执行,听起来都蛋疼,还不如用1.2.。。 |
@nunnly 嗯,目前2.0还比较超前,等过一段日子随着node支持的语法越来越高,到时候就不需要编译了。 |
什么时候node会支持这种ES7的写法呢? 现在已经nodev6了。 |
@tosone 现在node的稳定版是4.x。。。 |
function getBody(str) {
return new Promise(function (resolve, reject) {
resolve(str);
});
}
app.use(function (ctx, next) {
console.log(1);
next().then(data=>console.log(2));
});
app.use(co.wrap(function \* (ctx, next) {
ctx.body = yield getBody('Hello1');
console.log(3, ctx.body);
yield next();
console.log(4, ctx.body);
}));
app.use(co.wrap(function \* (ctx, next) {
let tmp = yield getBody('Hello2');
ctx.body = ctx.body + '\n' + 'Hello2';
console.log(5, ctx.body);
yield next();
console.log(6, ctx.body);
}));
app.listen(3000, ()=>console.log('koa start at 3000...')) 我发现2.0里面普通函数和generator函数混用,中间件加载是有问题的,上面是测试样例 |
@hyj1991 你的普通函数沒有 return |
@aaawhz 额,,好的,以后我写文章的时候注意一下这个问题~~ |
写的好! |
不会啊 写的很好 楼上是因为没有看第一篇文章才觉得牵强吧 |
好文,多谢博主!但感觉这种深入的技术文配上一些比较魔性的图之后,比如那个哈哈哈,容易打乱读者节奏诶。感觉一下脑子会短路,可能因人而异吧。 |
@camiler 嗯嗯嗯,已经把这些不太合适的比较有魔性的表情图删除了,好几个人反馈这个问题了。哈哈哈 |
请问koa里面如何关闭server呢? |
listen(port?: number, hostname?: string, backlog?: number, listeningListener?: () => void): Server; 根据index.d.ts定义 let server = app.listen(3000)
server.close() |
深入浅出 Koa2
说在前面的话:本文针对对koa1非常了解并学习过源码或者阅读过我上篇koa文章的同学阅读~
吸取之前的经验,本章用幽默的风格来分析又臭又硬的原理,我尽量用最通俗易懂的语言来描述复杂的逻辑。
前几天koa发布了2.0版本。这几天找了个不忙的时间,赶紧阅读了2.0的文档和源码
这次改动主要是中间件的部分。其他部分对于使用者来说没什么改动。
阅读过我的上一篇文章的同学应该知道。koa内部主要有两个知识点,context(上下文)和middleware(中间件)两个部分
所以总体来看,改动不算太大,我先把改动分个类
使用上的改动
先说使用方面,这次改动让中间件部分可以使用ES2015-2016的语法~
比如async await,在比如箭头函数
正因为中间件支持了async 和await,所以内部的中间件逻辑就不得不做一些改动。
但是koa的作者还是做了兼容的。同时支持3种不同种类的中间件,
普通函数
,async 函数
,Generator函数
。(这个屌)普通函数的用法
async函数的用法
Generator函数的用法
当然,用v1的语法也可以,像下面这样
不过官方并不建议这样写,因为他们打算在v3中取消对这种写法的兼容。
噢,对了,还有一种写法。
让我们自己把自己的中间件做一下兼容(v2内部就是这样做的兼容),然后就可以衣食无忧了。。(Are you sure?)
因为v2用的是ES2015-2016的语法,其中包括class,所以node目前是无法支持的,即便是目前比较先进的的v5.10.x也不行(臣妾做不到啊~)
那么,,,你懂得,需要babel编译之后才可以用
koa当然不会替我们编译,这并不符合koa的思想和原则,所以需要我们自己去编译。(koa的思想和原则是什么??)
使用方面的就说到这,下面说说源码上的改动。
源码上的改动
语法
看了koa的源码之后,发现主文件
application.js
对Emitter
的继承,使用了ES2015的语法,大概是这样的我们回顾下v1
中间件
中间件这块改动比较大,咱们从头开始。。
先从注册中间件开始,也就是
app.use
这个方法开始,先贴一段源码(为了方便观察,我把不重要的代码删了)我们对比下v1是什么样的
我们看到
v2
多了一个判断,如果是Generator函数,那就用convert
把函数包起来,然后在push到this.middleware
这就是针对v1的写法做的兼容。(官方说v3发布的时候就不兼容v1的写法,应该就是把这个判断删了,,我邪恶的猜测着)没关系,官方给咱们支了一招,他们不帮咱们做兼容咱们可以来(自己动手风衣主食啊),自己把自己的中间件用
convert
包起来在use。。那
convert
是干啥用的?我们看下源码其实核心就一句(为了方便理解,做一个小改动)
大概就是,把一个普通函数push到中间件里,执行这个中间件,返回promise,,不要问我为啥返回promise,快去上一篇文章好好学习。![](https://camo.githubusercontent.com/39f300e3415b23068f2d876f4fc521b4bea60c31ac0dac87d59c5b60f7a49110/687474703a2f2f70342e7168696d672e636f6d2f642f696e6e2f65393435373166312f46454433303434422d443437362d344439382d384134302d3142383933333446323443372e706e67)
接下来我们在看看中间件是怎样运行的,下面这个熟悉的函数,不要问我它是干啥的,哔哔哔![](https://camo.githubusercontent.com/39f300e3415b23068f2d876f4fc521b4bea60c31ac0dac87d59c5b60f7a49110/687474703a2f2f70342e7168696d672e636f6d2f642f696e6e2f65393435373166312f46454433303434422d443437362d344439382d384134302d3142383933333446323443372e706e67)
这块我分两部分讲
就是上面代码中return前和return后,return前是启动server阶段,return后是接受请求阶段(虽然启动server阶段就一行代码)
启动server
看第一行代码
童鞋们知道
this.middleware
里面现在是一些什么东西嘛?不要告诉我中间件,,,,,,![](https://camo.githubusercontent.com/084979a01618c641b831b44d04dca071894f8f8809ac9155f1b78cf016df2cba/687474703a2f2f70372e7168696d672e636f6d2f642f696e6e2f34626465636164652f41313633373339422d383132352d344232382d413831302d3932303634364234384132372e706e67)
现在
this.middleware
中存了一些函数,不管他是什么函数,反正只要执行它,它就返回promise。这个函数有可能是async 函数
有可能是被convert
包装后的Generator函数,或者是被co.wrap
包装后的Generator函数,也有可能是普通函数的中间件(哈哈哈哈,不要忘了v2支持普通函数的中间件哦~),反正这些函数都有一个特性,那就是执行它们,会返回promise。现在这群函数被传到
compose
中进行处理,处理之后变成啥样了???我先说另一个事,这里先暂停,我们先知道中间件被
compose
处理成怪物了,我们先看看这些怪我的作用接收请求
我们看接收请求时要执行的代码(fn就是那个怪物):
我们对比下v1
一模一样,没有任何区别。。。。(语法除外)
额,既然一模一样,我就不多说了。不懂的童鞋去读上一篇文章,,那里有非常详细的介绍(我是不是太会偷懒了。。)
好了,那么现在最重要的地方来了,compose 是怎么把中间件变成怪物的,又是怎么把三个种类的中间件变成可以实现中间件逻辑的函数呢,这一次的回逆是怎样实现的?
先留个悬念,不然不知道这里是重点。
上篇文章说过
compose
这个模块,有意思的是,这个模块也升级了。koa v1
对应着compose v2
,koa v2
对应着compose v3
,我们看看compose v3
中的代码代码看起来有点吓人,我们主要看return 后面的那个函数里的逻辑,因为每次server接收到请求的时候都会执行这个函数,,不要问我为什么,去看上一篇文章~
这个函数里有一个重要的函数,
dispatch
(就这么一个函数能不重要嘛)前方高能预警!!
首先在执行到匿名函数的时候(就是return返回的那个函数),会执行
dispatch
,并传一个参数0
,其次就是在dispatch
执行的过程中会自己调用自己,递归调用。我们再来看两个变量
index
和i
index
一开始默认是 -1i
一开始默认是 0(因为第一次传递的参数是 0)在
dispatch
的第一行有一个判断,如果i <= index
抛出错误。判断的下面是一个赋值,
index = i
然后下面是一个递归调用,参数是
i + 1
也就是说,如果没有意外,
index
是永远小于i
的,那什么情况下index
会大于或等于i
?在同一个中间件中多次调用
next()
(执行next就是执行dispatch)的时候,index
会大于i
,从代码上看,每个中间件都有一个自己的作用域,也就是说同一个中间件,i
是不变的,在i
不变的情况下,多次调用next
的情况下,第一次调用,index
小于i
,第二次调用,index
就 等于i
了。。。额,,啰嗦了,上面那个理解了最好,没理解也没关系,就是先给大家热热身,从现在开始,把我们的大脑要高速运转。
其实..... 我们只需要知道
dispatch
每次执行都会有一个变量i
,这个i
是干啥的?i
其实是用来在this.middleware
中获取中间件的下标,dispatch
函数第一次执行i
是0
,第二次是1
,以此类推。。。。看这行代码,就行用来获取中间件用的
好啦,现在我们取到中间件了,但是怎么使用呢??
先来一段代码
执行中间件,并传递两个参数,
context
和next
函数,context
是koa中的上下文没什么可说的,说说next
函数,next
也蛮简单的,就是return一个dispatch
的执行结果,注意那个参数i+1
,这个参数很有学问,传递一个i+1
,就相当于一旦执行next
函数,就等同于执行下一个中间件。PS:一个中间件只能执行一次next,否则逻辑上会出现问题,为了避免这个问题,在
dispatch
中一开始就做了判断,就是一开始咱们说的index
和i
的问题。这个地方其实就跟koa1有点不同了。koa1是可以在一个中间件中多次调用next的,并且不会出现问题,因为一个yield只能执行一次,即便调用再多的next在generator函数中被执行过的代码也不会重复执行,所以多次调用时不会报错,不会出现问题的,只是执行了跟没执行一样,没效果。所以即便是koa1也是不建议多次调用next,因为每调用一次,就会创建个promise,然后在里面执行一次getn.next然后发现返回值是{value: undefined, done: true},然后在resolve()跳回来。这样有点浪费性能。
在中间件中,我们通常会这样使用
async 的语法是,await后面会跟一个promise,await会等待promise,等promise执行完了,在往下执行
而我们的这些中间件,都有一个特点,执行完会返回promise,所以正好被await监听。
我们中间件本身返回的就是promise,为什么会被Promise.resolve包起来?这里是一个兼容写法,如果只支持async函数当然没问题,但我们的中间件除了支持async函数外,还支持普通函数呦~~~
所以,如果中间件使用async函数写的,流程大概是这样的
dispatch(0)
),这个中间件会返回promise,koa会监听这个promise,一旦成功或者失败,都会做出不同的处理,并结束这次响应await next();
,在这里手动触发第二个中间件执行,第二个中间件和第一个中间件一样,也会返回promise(废话,一奶同胞的兄弟能不一样么)await会监听这个promise,什么时候执行完了,什么时候继续执行第一个中间件后续的代码。(中间件的回逆就是这样实现的)await next();
这样一段代码来触发第三个中间件并等待第三个中间件执行完了在执行后续代码,否则就一直等,以此类推所以就造成了这样一个现象,第一个中间件代码执行一半停在这了,触发了第二个中间件的执行,第二个中间件执行了一半停在这了,触发了第三个中间件的执行,然后,,,,,,第一个中间件等第二个中间件,第二个中间件等第三个中间件,,,,,,第三个中间件全部执行完毕,第二个中间件继续执行后续代码,第二个中间件代码全部执行完毕,执行第一个中间件后续代码,然后结束(不得不说,,TJ大神真想法)
其实koa1也是这个逻辑,koa2对于koa1思想上是没有变化的,变的只是语法、
中间件的实现逻辑 - 普通函数
有的同学说了,如果我用普通函数写中间件,是怎样实现与async函数同样逻辑的呢?
其实并不难,async函数有几个特点能帮助它完成中间件的逻辑
首先我们看下普通函数的用法
先说第一个条件,「执行后返回promise」
上面我们说过,我们的中间件在
dispatch
中会被Promise.resolve
包住并返回,所以第一个条件满足我们在说第二个条件,「中间件内部可以监听promise并等待promise接收后执行后续代码」
很明显,第二个条件也满足,因为普通函数的写法是异步的,后续代码在then里面。(async也不过是看起来同步而已,其实是同样的逻辑,普通函数的写法更露骨)
中间件的实现逻辑 - Generator函数
先看看用法
首先第一个条件「执行后返回promise」
可以看到中间件是用
co.warp
包起来的,co.warp
会返回promise,上一章我详细的讲解过,第一个条件满足我们在说第二个条件,「中间件内部可以监听promise并等待promise接收后执行后续代码」
co
与async一样,yield后面可以跟一个promise,co会监听这个promise,什么时候这个promise执行完了。什么时候执行后续的代码,这点跟async是一模一样的,只是写法略有不同,第二个条件满足关于 co 的内部原理,上一篇文章中有详细的分析与介绍~
转载请注明出处![](https://camo.githubusercontent.com/b0146d68697c44edbbdf81dc9ab2d3e52051a5876a159725c3445660992faeef/687474703a2f2f70382e7168696d672e636f6d2f743031623835323230623036373831356138632e676966)
The text was updated successfully, but these errors were encountered: