从Generator开始学习Koa

Koa是最近比较火的一款基于Node的web开发框架。说他是一个框架，其实他更像是一个函数库，通过某种思想（或者说某种约定），将众多的中间件联系在一起，从而提供你所需要的web服务。

Koa做了两件很重要的事：

1. 封装node的request和response对象到Context上，还提供了一些开发web应用以及api常用的方法

2. 提供了一套流程控制方式，将众多中间件级联在一起

而我现在想讨论的就是Koa的这套流程控制的思想。

先看一段从官方文档上搬下来的代码：

var koa = require('koa'); 
var app = koa(); 

// x-response-time  

app.use(function *(next){   
  var start = new Date;
  yield next;
  var ms = new Date - start;
  this.set('X-Response-Time', ms + 'ms'); 
});  

// logger

app.use(function *(next){   
  var start = new Date;   
  yield next;   
  var ms = new Date - start;   
  console.log('%s %s - %s', this.method, this.url, ms); 
});  

// response  

app.use(function *(){   
  this.body = 'Hello World'; 
});  

app.listen(3000);

app是Koa的一个实例，通过调用app.use，向Koa内部维护的一个middlewares数组中，添加中间件。而我们所说的中间件，其实就是那个作为app.use参数的，使用奇怪方式声明的function。

在Koa中，我们约定所有的中间件都是以这种方式声明的，如果你了解ES6，那你一定见过这种声明方式。没错，这就是ES6中的generator function。Koa中，真正的中间件其实就是一个generator对象。

什么是Generator？

Generator是ES6新引进的一个概念，使用Generator可以将函数的控制权交给函数外部。也就是说，你可以控制函数的执行进程。

举个例子：

function *sayHello(){
  console.log("before say");
  yield console.log("hello!");
  console.log("end say");
}

var a = sayHello();
a.next(); // 输出before say 输出hello!
a.next(); // 输出end say

首先我们定义了一个叫做sayHello的generator function，它跟普通的function不同，执行sayHello()，并不会执行函数体内部的程序，但是会返回一个generator对象。因此a的值实际上长这样：

sayHello {[[GeneratorStatus]]: "suspended"}

对generator function来说，执行函数只是生成了一个generator对象，不会执行函数的内在逻辑，而使用者却可以通过这个generator对象来达到控制函数执行的目的。就比如说这个sayHello函数，我可以在需要的时候，执行a.next()方法，来执行函数的内部逻辑。第一次执行a.next()，函数开始执行，直到它遇到yield指令，它会执行yield之后的表达式，并返回一个值，然后中断函数的运行。因此，我们看到，第一次执行a.next()后，函数输出了"before say"和"hello!"。需要说明的是，每次执行完next函数之后，都会返回一个对象：

Object {value: undefined, done: false}

这个返回值有两个属性：value和done，generator对象通过这个返回值来告诉外界函数的执行情况。value的值是yield之后的表达式的值，done则是函数执行的状态，如果函数未执行完，则其值为false，否则是true。在sayHello中，yield之后是console语句，因此返回的对象中value为undefined。

这个时候，我们再次调用a.next()，程序输出"end say"。next函数的返回值变成这样：

Object {value: undefined, done: true}

可以发现done的值变为了true，因为函数已经执行完了。

Generator可以被用来作迭代器。

首先了解一下迭代器。在ES6规范中，新增了两个协议：可迭代协议和迭代器协议。在迭代器协议中指明，一个实现了next方法并且该方法的返回值有done和value两个属性的对象，可以被当做迭代器。这些要求正好符合我们的Generator对象。举一个被当做迭代器使用的例子：

function *range(start, end){
  for (let i = start; i < end; i++) {
    yield i;
  }
}
var a = range(0, 10);
// 输出0...9
for (let i of a) {
  console.log(i);
}

其实道理是一样的，Generator把程序的控制权交给了外部，哪里调用next，程序就在哪里执行。可想而知for...of的实现原理也一定是在内部循环执行了next方法，直到返回值的done属性变成true才停止。

为什么中间件必须是个Generator function？

了解了Generator，回头再去看那段官方文档上搬来的代码。

var koa = require('koa'); 
var app = koa(); 

// x-response-time  

app.use(function *(next){   
  var start = new Date;
  yield next;
  var ms = new Date - start;
  this.set('X-Response-Time', ms + 'ms'); 
});  

// logger

app.use(function *(next){   
  var start = new Date;   
  yield next;   
  var ms = new Date - start;   
  console.log('%s %s - %s', this.method, this.url, ms); 
});  

// response  

app.use(function *(){   
  this.body = 'Hello World'; 
});  

app.listen(3000);

我们来分析代码。app.use将一个个中间件放入middlewares数组中，而app.listen启动了一个3000端口来监听http服务。实际上app.listen这个方法，底层是这样实现的：

var http = require('http');
var koa = require('koa');
var app = koa();
http.createServer(app.callback()).listen(3000);

这样你就明白了，当请求来临时，会触发在createServer时注册的回调函数（app.callback()的返回值），这个回调函数的执行其实就引发了一连串的中间件的执行。

先说结果，在探索原理。

middlewares数组中的这些中间件顺序执行，先开始进入第一个中间件 —— x-response-time，遇到yield中断执行，转而进入第二个中间件 —— logger，同样遇到yield中断执行，进入第三个中间件 —— response，这次没有遇到yield，第三个中间件执行完毕，页面输出"Hello World"，done的值变为true。这个时候，再返回去执行第二个中间件刚刚中断的地方，直到第二个中间件的done也变为true，返回第一个中间件刚刚中断的位置。

是不是很神奇？这些中间件就像洋葱一样，一层一层的深入进去，又一层一层的走出来。

那么Koa是如何实现这般神奇的流程控制的呢？

Koa内部依赖了一个叫co的流程控制库。

首先，Koa实现了一个叫Koa-compose的中间件，这个中间件用来将middlewares中的所有中间件串联起来。其实现代码如下：

/**
 * Compose `middleware` returning
 * a fully valid middleware comprised
 * of all those which are passed.
 *
 * @param {Array} middleware
 * @return {Function}
 * @api public
 */
function compose(middleware){  
  return function *(next){
    if (!next) next = noop();
    var i = middleware.length;
    while (i--) {
      next = middleware[i].call(this, next);
    }
    return yield *next;
  }
}
/**
 * Noop.
 *
 * @api private
 */
function *noop(){}

compose函数会返回一个能将众多中间件串联起来的Generator函数。这个函数从最后一个中间件开始执行，将生成的Generator对象扔给它的上一个中间件，依次类推，直到第一个中间件。这个结构真的很像一颗洋葱，从最后一个中间件开始，一层一层往上面包。

这样生成一个Generator对象之后，Koa把它交给了co这个流程控制库。co其实是个很抽象的东西。为了理解它的原理，我们可以先思考一下，如果把这个Generator对象交给我们，我们怎么类似于实现刚刚那个图所展示的效果？

从洋葱的最外层皮开始往里剥。执行第一次.next()函数，第一层中间件yield之前的程序执行完毕，通过yield next，我们拿到了第二层中间件的Generator对象。这个时候怎么办呢？按照刚刚那幅图，第一层中间件，必须要等到第二层中间件的done状态变为true之后，才可以继续执行之后的程序，即只有在第二层中间件的done状态变为true之后，才能再次执行第一层中间件Generator对象的.next()函数。同样的，之后所有的中间件都要重复这样的过程，第一层等待第二层，第二层等待第三层......那么当状态改变的时候，是不是应该有个人来通知我们？对，这个时候Promise就该出场了。

co将每个中间件.next()的运行结果的value属性都封装成一个Promise，在其done状态变为true时，resolve()这个Promise，对于洋葱里面的部分，每一层resolve之后，都会触发上一层中间件的.next()函数，并检查其状态。直到洋葱的最外面一层也resolve了，控制权就交还给Koa，而Koa会在这个时候，发起response。

co的大体思想就是这样，如果想继续深入，可以去看co的源码，自己实现一下应该也不会太难。

理解了洋葱模型，就不难明白，yield和Promise在其中所起的作用了。

关于Koa

关于Koa，还有太多值得拿出来讨论的话题，我现在只是对Koa1.x中对Generator的使用做了一次整理，别的话题就慢慢再讨论吧。

最后，如果你有什么建议，欢迎不吝赐教~