yield next和yield* next的区别

　　yield next和yield* next之间到底有什么区别？为什么需要yield* next？经常会有人提出这个问题。虽然我们在代码中会尽量避免使用yield* next以减少新用户的疑惑，但还是经常会有人问到这个问题。为了体现自由，我们在koa框架内部使用了yield* next，但是为了避免引起混乱我们并不提倡这样做。

　　相关文档，可以查看这里的说明harmony proposal.

yield委托（delegating）做了什么？

　　假设有下面两个generator函数：

function* outer() {
  yield 'open'
  yield inner()
  yield 'close'
}
 
function* inner() {
  yield 'hello!'
}

　　通过调用函数outer()能产出哪些值呢？

var gen = outer()
gen.next() // -> 'open'
gen.next() // -> a generator
gen.next() // -> 'close'

　　但如果我们把其中的yield inner()改成yield* inner()，结果又会是什么呢？

var gen = outer()
gen.next() // -> 'open'
gen.next() // -> 'hello!'
gen.next() // -> 'close'

　　事实上，下面两个function本质上来说是等价的：

function* outer() {
  yield 'open'
  yield* inner()
  yield 'close'
}
 
function* outer() {
  yield 'open'
  yield 'hello!'
  yield 'close'
}

　　从这个意义上来说，委托的generator函数替代了yield*关键字的作用！

这与Co或Koa有什么关系呢？

　　Generator函数已经很让人抓狂了，它并不能帮助Koa的generator函数使用Co来控制流程。很多人都会被本地的generator函数和Co框架提供的功能搞晕。

　　假设有以下generator函数：

function* outer() {
  this.body = yield inner
}
 
function* inner() {
  yield setImmediate
  return 1
}

　　如果使用Co，它实际上等价于下面的代码：

function* outer() {
  this.body = yield co(function inner() {
    yield setImmediate
    return 1
  })
}

　　但是如果我们使用yield委托，完全可以去掉Co的调用：

function* outer() {
  this.body = yield* inner()
}

　　那么最终执行的代码会变成下面这样：

function* outer() {
  yield setImmediate
  this.body = 1
}

　　每一个Co的调用都是一个闭包，因此它会或多或少地存在一些性能上的开销。不过你也不用太担心，这个开销不会很大，但是如果使用委托yield，我们就可以降低对第三方库的依赖而从代码级别避免这种开销。

有多快？

　　这里有一个链接，是之前我们讨论过的有关该话题的内容：https://github.com/koajs/compose/issues/2. 你不会看到有太多的性能差异（至少在我们看来），特别是因为实际项目中的代码会显著地降低这些基准。因此，我们并不提倡使用yield* next，不过在内部使用也并没有坏处。

　　有趣的是，通过使用yield* next，Koa比Express要快！Koa没有使用dispatcher（调度程序），这与Express不同。Express使用了许多的调度程序，如connect, router等。

　　使用委托yield，Koa事实上将：

co(function* () {
  var start = Date.getTime()
  this.set('X-Powered-By', 'koa')
  if (this.path === '/204')
    this.status = 204
  if (!this.status) {
    this.status = 404
    this.body = 'Page Not Found'
  }
  this.set('X-Response-Time', Date.getTime() - start)
}).call(new Context(req, res))

　　拆解成：

app.use(function* responseTime(next) {
  var start = Date.getTime()
  yield* next
  this.set('X-Response-Time', Date.getTime() - start)
})
 
app.use(function* poweredBy(next) {
  this.set('X-Powered-By', 'koa')
  yield* next
})
 
app.use(function* pageNotFound(next) {
  yield* next
  if (!this.status) {
    this.status = 404
    this.body = 'Page Not Found'
  }
})
 
app.use(function* (next) {
  if (this.path === '/204')
    this.status = 204
})

　　一个理想的Web application看起来就和上面这段代码差不多。在上面使用Co的那段代码中，唯一的开销就是启动单个co实例和我们自己的Context构造函数，方便起见，我们将node的req和res对象封装进去了。

使用它进行类型检查

　　如果将yield*应用到不是generator的函数上，你将会看到下面的错误：

TypeError: Object function noop(done) {
  done();
} has no method 'next'

　　这是因为基本上任何具有next方法的东西都被认为是一个generator函数！就我个人而言，我很喜欢这个，因为默认我会假设我就是一个yield* gen()。我重写了很多我的代码来使用generator函数，如果我看到某些东西没有被写成generator函数，那么我会想，我可以将它们转换成generator函数而使代码更简化吗？

　　当然，这也许并不适用于所有人，你也许能找到其它你想要进行类型检查的原因。

上下文

　　Co会在相同的上下文中调用所有连续的可yield的代码。如果你想在yield function中改变调用的上下文，会有些麻烦。看下面的代码：

function Thing() {
  this.name = 'thing'
}
 
Thing.prototype.print = function (done) {
  var self = this
  setImmediate(function () {
    console.log(self.name)
  })
}
 
// in koa
app.use(function* () {
  var thing = new Thing()
  this.body = yield thing.print
})

　　这里你会发现this.body是undefined，这是因为Co事实上做了下面的事情：

app.use(function* () {
  var thing = new Thing()
  this.body = yield function (done) {
    thing.print.call(this, done)
  }
})

　　而这里的this指向的是Koa的上下文，而不是thing。

　　上下文在JavaScript中很重要，在使用yield*时，可以考虑使用下面两种方法之一：

yield* context.generatorFunction()
yield context.function.bind(context)

　　这样可以让你避开99%的generator函数的上下文问题，从而避免了使用yield context.method给你带来的困扰！