摘要:經(jīng)常游蕩在的我總能發(fā)現(xiàn)許多好問(wèn)題和好答案。盡管網(wǎng)絡(luò)上有著各式各樣的關(guān)于該主題的指導(dǎo),但涉及到在各種情景下的最佳實(shí)踐,或者較好實(shí)踐的方面還是不夠清晰。我寄希望于針對(duì)我這篇裹腳布式問(wèn)題的回復(fù)可以改變這一現(xiàn)狀。我感覺(jué)因此收益的絕對(duì)不止是我一個(gè)人。
Koa / Co / Bluebird or Q / Generators / Promises / Thunks interplay? (Node.js) Koa / Co / Bluebird or Q / Generators / Promises / Thunks 的相互關(guān)系(影響/作用)?經(jīng)常游蕩在 SO 的我總能發(fā)現(xiàn)許多好問(wèn)題和好答案。它們的“好”不僅僅在于知識(shí)的價(jià)值,更可貴之處在于如何表達(dá):如何“提問(wèn)”/如何“回答”。不久前我在 SF 發(fā)了一篇 WebComponents 和 React 的對(duì)比 就是一個(gè)很典型的范例,今天我又發(fā)現(xiàn)看到這樣的一篇,不敢獨(dú)享,略做翻譯繼續(xù)奉獻(xiàn)給諸位。(唯一的回答比較長(zhǎng)還沒(méi)翻譯完且我也在等待更好的回答,等有時(shí)間會(huì)補(bǔ)充)
I"m investigating building a web app in part with Koa, but I don"t quite have a handle on the hows, whens, and whys of choosing between - and applying - the range of supportive "making async easier" technologies/approaches (listed below).
我正在為了創(chuàng)建 web 應(yīng)用時(shí)和 Koa 有關(guān)的部分做調(diào)研,但我對(duì)于一系列“讓異步編程更輕松”的技術(shù)/方法(下文列出),很難抉擇如何、何時(shí)、以及為何選擇且運(yùn)用。
Overall the disparate guidance on the web about this subject still leaves things blurry, especially in respect to evolving best practices, or at least better ones, and under what scenarios. There seems to be little or nothing on the web that puts it all in context.
盡管網(wǎng)絡(luò)上有著各式各樣的關(guān)于該主題的指導(dǎo),但涉及到在各種情景下的最佳實(shí)踐,或者較好實(shí)踐的方面還是不夠清晰??雌饋?lái)網(wǎng)上幾乎沒(méi)有“百科全書(shū)”。
I"m hoping the responses to this big arse sprawling post can correct that. Also maybe the questions below can inspire someone to write a thorough blog post or the like to address this matter. My sense is I"m not even close to the only one who would benefit from that.
我寄希望于針對(duì)我這篇“裹腳布”式問(wèn)題的回復(fù)可以改變這一現(xiàn)狀。同時(shí)也希望下面的問(wèn)題可以激發(fā)某人寫(xiě)一篇博客或什么的將其囊括總結(jié)。我感覺(jué)因此收益的絕對(duì)不止是我一個(gè)人。
So I"d be pleased if the bright community could help answer and provide clarity to the following questions in respect to the technologies listed below (in bold type):
所以我很高興若有人能從如下角度針對(duì)后面的問(wèn)題(黑體)提供清楚的回答:
a) How, and under what circumstance (as applicable) are they complements, supplements, substitutes, and/or overlapping solutions to one another?
a) 在何種(可適用的)情形下,它們相互之間可怎樣補(bǔ)充、替換、并且/或者彼此重復(fù)?
b) What are their trade-offs in respect to speed-performance, error handling ease, and debugging ease?
b) 在速度/性能,便于錯(cuò)誤處理和便于調(diào)試這幾方面,它們各自的利弊是什么?
c) When, where, and why may it be better to use "this" versus "that" technology, technologies-combo, and/or approach?
c) 在何時(shí),何處用“這個(gè)”代替“那個(gè)”技術(shù)/技術(shù)組合/方法會(huì)更好,以及原因?yàn)楹危?/p>
d) Which technologies or approaches, if any, may be "dimming stars".
d) 哪一種技術(shù)或方法,如果有的話,可能已經(jīng)是“昨日黃花”。
Technologies:
技術(shù):
Koa
My understanding:
我的理解:
Koa is a minimal foundation for build Node apps geared for taking advantage of ECMAScript-6 features, one feature in particular being generators.
Koa 是受益于 ES6特性,特別是 Generators 特性的用來(lái)開(kāi)發(fā) Node 應(yīng)用的最小化基礎(chǔ)框架。
Co
My understanding:
我的理解:
Co is a library of utilites for running ECMAScript-6 generators (which are native to Node .011 harmony), with the goal to allieve some/much(?) of the need to write boilerplate code for running and managing generators.
Co 是運(yùn)行 ES6 Generators(Node .011 harmony 模式下原生支持)的工具類(lèi)庫(kù),其目標(biāo)是幫助編寫(xiě)部分/更多(?)的用于運(yùn)行和管理 generators 的模版代碼。
Co is intrinsically part of Koa(?).
Co 本質(zhì)上是 Koa 的一部分(?)。
Specific questions:
針對(duì)性問(wèn)題:
If and how does one use Co differently in Koa than in a non-Koa context. In other words, does Koa wholly facade Co?
能否且若能則如何讓 Co 在非 Koa 的場(chǎng)合下以不同于 Koa 的方式使用?換言之,Koa 是否只是換了一個(gè)“馬甲”的 Co?
Could Co be replaced in Koa with some other like generator library if there is/was a better one? Are there any?
在 Koa 當(dāng)中有能代替 Co 的其他 generator 類(lèi)庫(kù)嗎?
Promise Libraries such as "Q" and Bluebird
My understanding:
我的理解:
They are in a sense "polyfills" for implmententing the Promises/A+ spec, if and until Node natively runs that spec.
它們都是 Promises/A+ 規(guī)范的 polyfills 實(shí)現(xiàn),當(dāng)且直到 Node 原生實(shí)現(xiàn)了該規(guī)范。
They have some further non-spec convenience utilities for facilitating the use promises, such as Bluebird"s promisfyAll utility.
它們實(shí)現(xiàn)了一些規(guī)范外的便利方法以便更好的使用 promises,比如 Bluebird 的 promisfyAll。
Specific questions:
針對(duì)性問(wèn)題:
My understanding is the ECMAScript-6 spec does/will largely reflect the Promises/A+ spec, but even so, Node 0.11v harmony does not natively implement Promises. (Is this correct?) However when it does, will technologies such as Q and Bluebird be on their way out?
我理解中的 ES6 規(guī)范(將)會(huì)大量體現(xiàn) Promises/A+ 規(guī)范,可即便如此,Node 0.11v harmony 沒(méi)有原生 Promises 實(shí)現(xiàn)(對(duì)嗎?)。若將來(lái)實(shí)現(xiàn)了,像 Q 和 Bluebird 這樣的技術(shù)是不是就要過(guò)時(shí)了?
I"ve read something to the effect that "Q" and Bluebird support generators. What does this mean? Does it mean in part that, for example, they to some degree provided the same utility as Co, and if so to what degree?
我讀到過(guò)一些東西說(shuō) Q 和 Bluebird 支持 generators。這是什么意思?是不是意味著在某種程度上它們提供了和 Co 一樣的功能?如果是的化,一樣到了何種程度?
Thunks and Promises
(譯注:此二者皆為術(shù)語(yǔ)不做翻譯更佳)
I think I have an fair handle on what they are, but hoping someone can provide a succinct and clear "elevator pitch" definition on what each is, and of course, as asked above, to explain when to use one versus the other -- in a Koa context and not in it.
我想我對(duì)此二者已經(jīng)理解了,不過(guò)還是希望有誰(shuí)能提供一個(gè)簡(jiǎn)明扼要的“電梯推介”(譯注:即在做個(gè)電梯的時(shí)間里,如一分鐘內(nèi),說(shuō)清楚一個(gè)概念),且能解釋下二者的對(duì)比——在使用和不使用 Koa 的情形下。
Specific questions:
針對(duì)性問(wèn)題:
Pro and cons to using something like Bluebird"s promisfy, versus say using Thunkify (github com/visionmedia/node-thunkify)?
對(duì)比使用 Bluebird 等 promise 式的庫(kù)和 thunk 式的庫(kù)(如 https://github.com/visionmedia/node-thunkify)之間的優(yōu)點(diǎn)和缺點(diǎn)
To give some further context to this post and its questions, it might be interesting if Koa techniques presented in the following webpages could be discussed and contrasted (especiallly on a pros vs cons basis):
為了對(duì)本問(wèn)題提供更多的背景資料,下列涉及 Koa 技術(shù)的資料若能一并加以探討和對(duì)比(特別是優(yōu)劣比較)那就再好不過(guò)了:
a) http://www.marcusoft.net/2014/03/koaintro.html (Where"s the thunks or promises, or am I not seeing something?)
b) https://strongloop.com/strongblog/node-js-express-introduction-koa-js-... (Again, where"s the thunks or promises?)
c) http://github.com/koajs/koa/blob/master/docs/guide.md (What does the "next" argument equate to, and what set it and where?)
d) http://blog.peterdecroos.com/blog/2014/01/22/javascript-generators-fir... (Not in a Koa context, but presents the use of Co with a promise library (Bluebird), so I"m assuming the technique/pattern presented here lends itself to usage in Koa(?). If so, then how well?
Thanks all!
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/85646.html
摘要:簡(jiǎn)介指的是兩個(gè)關(guān)鍵字,是引入的新標(biāo)準(zhǔn),關(guān)鍵字用于聲明函數(shù),關(guān)鍵字用來(lái)等待異步必須是操作,說(shuō)白了就是的語(yǔ)法糖。最后希望大家在讀過(guò)異步發(fā)展流程這個(gè)系列之后,對(duì)異步已經(jīng)有了較深的認(rèn)識(shí),并可以在不同情況下游刃有余的使用這些處理異步的編程手段。 showImg(https://segmentfault.com/img/remote/1460000018998406?w=1024&h=379); ...
摘要:以下展示它是如何工作的函數(shù)使用構(gòu)造函數(shù)創(chuàng)建一個(gè)新的對(duì)象,并立即將其返回給調(diào)用者。在傳遞給構(gòu)造函數(shù)的函數(shù)中,我們確保傳遞給,這是一個(gè)特殊的回調(diào)函數(shù)。 本系列文章為《Node.js Design Patterns Second Edition》的原文翻譯和讀書(shū)筆記,在GitHub連載更新,同步翻譯版鏈接。 歡迎關(guān)注我的專(zhuān)欄,之后的博文將在專(zhuān)欄同步: Encounter的掘金專(zhuān)欄 知乎專(zhuān)欄...
摘要:從最開(kāi)始的到封裝后的都在試圖解決異步編程過(guò)程中的問(wèn)題。為了讓編程更美好,我們就需要引入來(lái)降低異步編程的復(fù)雜性。寫(xiě)一個(gè)符合規(guī)范并可配合使用的寫(xiě)一個(gè)符合規(guī)范并可配合使用的理解的工作原理采用回調(diào)函數(shù)來(lái)處理異步編程。 JavaScript怎么使用循環(huán)代替(異步)遞歸 問(wèn)題描述 在開(kāi)發(fā)過(guò)程中,遇到一個(gè)需求:在系統(tǒng)初始化時(shí)通過(guò)http獲取一個(gè)第三方服務(wù)器端的列表,第三方服務(wù)器提供了一個(gè)接口,可通過(guò)...
摘要:注是先前版本處理異步函數(shù)的方式,通過(guò)可以將異步函數(shù)封裝成,傳入普通參數(shù)后形成僅需要參數(shù)的偏函數(shù),以此簡(jiǎn)化調(diào)用代碼目前中的偏函數(shù)已經(jīng)被無(wú)情地化了。 前幾天研究了TJ的koa/co4.x和一系列koa依賴(lài)的源碼,在知乎上做出了人生首次回答(而且我真得再也不想去知乎回答技術(shù)問(wèn)題了_(:з」∠)_),因此把文字搬到這里。 ES2015 Generator/Yield 關(guān)于Generator...
閱讀 4276·2021-10-13 09:39
閱讀 482·2021-09-06 15:02
閱讀 3229·2019-08-30 15:53
閱讀 1040·2019-08-30 13:04
閱讀 2029·2019-08-30 11:27
閱讀 2010·2019-08-26 13:51
閱讀 2092·2019-08-26 11:33
閱讀 2902·2019-08-26 10:36