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給你帶來的困擾！