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