VB.net 2010 视频教程 VB.net 2010 视频教程 python基础视频教程
SQL Server 2008 视频教程 c#入门经典教程 Visual Basic从门到精通视频教程
当前位置:
首页 > temp > JavaScript教程 >
  • 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给你带来的困扰!

 

 出处:https://www.cnblogs.com/jaxu/p/6344366.html


相关教程