摘要：簡(jiǎn)單的說(shuō)，即將到來(lái)的標(biāo)準(zhǔn)指出是一個(gè)，所以作為一個(gè)，必須可以被子類化。保護(hù)還是子類化這是個(gè)問(wèn)題我真的希望我能創(chuàng)建一個(gè)忠實(shí)的給及以下。

原文地址：http://blog.getify.com/promis...

如果你需要趕上我們關(guān)于Promise的進(jìn)度，可以看看這個(gè)系列前兩篇文章深入理解Promise五部曲--1.異步問(wèn)題和深入理解Promise五部曲--2.控制權(quán)轉(zhuǎn)移問(wèn)題。

在前面，我們說(shuō)明了幾個(gè)關(guān)于Promises如何工作的要點(diǎn)，這些要點(diǎn)是我們之所以可以信任promise機(jī)制作為控制轉(zhuǎn)移的一種解決方案的基礎(chǔ)。

這些要點(diǎn)直接來(lái)自Promises/A+規(guī)范。任何本地實(shí)現(xiàn)或者polyfill或者庫(kù)都必須通過(guò)一個(gè)全面嚴(yán)格的測(cè)試來(lái)確定是否符合規(guī)范。

對(duì)于promises可靠性是最基本的，因?yàn)槿绻麤](méi)有可靠性，那么你就跟使用普通的回調(diào)一樣了。你必須謹(jǐn)慎地編寫(xiě)那些涉及到異步調(diào)用第三方庫(kù)的代碼。你必須自己來(lái)解決狀態(tài)跟蹤的問(wèn)題然后確保第三方庫(kù)不會(huì)出問(wèn)題。

如果沒(méi)有可靠的promises你自己可以完成異步任務(wù)嗎？當(dāng)然可以。但是問(wèn)題是，你自己無(wú)法處理得很完美，你得把很多額外的變量加到你的代碼中并且你會(huì)產(chǎn)生一個(gè)未來(lái)的維護(hù)風(fēng)險(xiǎn)，代碼會(huì)變得很難維護(hù)。

Promises是被設(shè)計(jì)用來(lái)規(guī)范和集中這種邏輯的。你可以使用一個(gè)規(guī)范的promise系統(tǒng)而不用擔(dān)心可靠性問(wèn)題，因?yàn)樗鼤?huì)按照Promises機(jī)制來(lái)執(zhí)行。

在理論上這個(gè)可靠性保證合同聽(tīng)起來(lái)很棒。但是在JavaScript中真的有可能有這么一個(gè)機(jī)制嗎？

在我開(kāi)始說(shuō)這個(gè)問(wèn)題之前，我們首先排除一些JS代碼中的可靠性問(wèn)題：

我們這里的討論跟密碼/加密中的“私有性”和“安全”無(wú)關(guān)。

和JS代碼可以被用戶通過(guò)查看源碼看到無(wú)關(guān)。

和一個(gè)黑客可以侵入你的服務(wù)器來(lái)發(fā)送一些惡意代碼或者通過(guò)中間人攻擊來(lái)劫持瀏覽器和服務(wù)器之間的連接來(lái)實(shí)現(xiàn)同樣的目的或者甚至在運(yùn)行時(shí)使用XSS漏洞來(lái)注入惡意代碼無(wú)關(guān)。

同時(shí)，也和惡意代碼一旦存在你的頁(yè)面就可以理論上修改JavaScript運(yùn)行時(shí)功能(比如通過(guò)修改Object.prototype或者Function.prototype)來(lái)破壞你的程序這個(gè)事實(shí)無(wú)關(guān)。

相似的，和一些粗心的代碼可能會(huì)意外地通過(guò)非標(biāo)準(zhǔn)的方式來(lái)修改標(biāo)準(zhǔn)JS函數(shù)無(wú)關(guān)。

最后，和如果你頁(yè)面中依賴于第三方庫(kù)那么他們的服務(wù)器，連接和代碼也會(huì)出現(xiàn)上面所說(shuō)的漏洞無(wú)關(guān)。

現(xiàn)在我可以繼續(xù)了，但是我認(rèn)為你已經(jīng)找到關(guān)鍵點(diǎn)了。我們?cè)谕ㄟ^(guò)一個(gè)假設(shè)來(lái)縮小我們的討論范圍：當(dāng)所有的代碼以及主機(jī)環(huán)境都在一種預(yù)期的安全的狀態(tài)中時(shí)，你的程序會(huì)如何執(zhí)行？

這并不是說(shuō)我們使用Promise所做的事情對(duì)上面這些問(wèn)題沒(méi)有幫助。這僅僅是由于這些問(wèn)題在一個(gè)更高的層面上---這些問(wèn)題遠(yuǎn)離了編寫(xiě)API和模式，這些問(wèn)題留給專家來(lái)討論。

我們看看下面這個(gè)例子：

var myPromise = {
    state: {
        status: 1,
        value: "Hello World"
    },
    then: function(success,failure) {
        // implement something like a thenable"s behavior
    }
};

我可以新建一個(gè)像這樣的對(duì)象，然后在平時(shí)使用它并且說(shuō)我在用promises。實(shí)際是，我可以再完善一下使它可以通過(guò)整個(gè)Promises/A+ 測(cè)試網(wǎng)站的測(cè)試。

你如何回答這個(gè)問(wèn)題比你意識(shí)到的更重要。在很多開(kāi)發(fā)者社區(qū)中很多人的回答是，是的。
我很確定的說(shuō)，不是！

為什么？如果你通過(guò)了promises測(cè)試網(wǎng)站，那么它就是一個(gè)promise 了，不是嗎？而且，它在所有情況下都按照規(guī)范來(lái)執(zhí)行，不是嗎？

promises的精髓遠(yuǎn)不是規(guī)范說(shuō)的那么簡(jiǎn)單，是可靠性。

可靠性是一個(gè)promise就是一個(gè)狀態(tài)(狀態(tài)會(huì)從"pending"轉(zhuǎn)變成"resolved"或者"rejected"其中一個(gè))的容器，這些狀態(tài)會(huì)附帶一個(gè)結(jié)果值(成功信息或者錯(cuò)誤信息)?？煽啃允且坏┮粋€(gè)promise的狀態(tài)變?yōu)?resolved"或者"rejected"，那么就不能改變也不會(huì)改變。可靠性就是完成的promise是不可變的。

但是promises的精髓還有一些更深層次的東西，這些是無(wú)法通過(guò)閱讀規(guī)范看出來(lái)的：改變一個(gè)promise狀態(tài)和設(shè)置它的完成值的能力只存在于原始的promise的實(shí)現(xiàn)。也就是說(shuō)這個(gè)能力的實(shí)現(xiàn)掌握在開(kāi)發(fā)者手里。

規(guī)范的早期版本中，把resolve/reject的功能分離出來(lái)放在一個(gè)對(duì)象中，叫做Deferred。把這想成一個(gè)對(duì)象對(duì)：在創(chuàng)建的時(shí)候，我們創(chuàng)建一個(gè)promise和一個(gè)deferred，deferred可以resolve這個(gè)promise。重要的是，這兩個(gè)可以被分開(kāi)，一部分代碼可以resolve/reject一個(gè)promise而另外一部分只能監(jiān)聽(tīng)這個(gè)變化然后做出回應(yīng)。

規(guī)范的后續(xù)版本中簡(jiǎn)化了promises，通過(guò)刪除deferred對(duì)象，取而代之的是簡(jiǎn)單的暴露出原來(lái)屬于deferred的resolve()和reject()方法。

var p = new Promise( function(resolve,reject){
    // I have `resolve()` and `reject()` from the
    // hidden `deferred`, and I **alone** control
    // the state of the promise.
} );

// now, I can pass around `p` freely, and it can"t
// be changed by anyone else but the creator.

看看之前的那個(gè)myPromise對(duì)象。你注意到了什么嗎？

var myPromise = {
    state: {
        status: 1,
        value: "Hello World"
    },
    then: function(success,failure) {
        // implement something like a thenable"s behavior
    }
};

如果你到處傳遞myPromise，然后不管惡意代碼還是意外的代碼都可以改變myPromise.state.status或者myPromise.state.value屬性，我們是不是開(kāi)了一個(gè)很大的后門(mén)，失去了Promises的可靠性。

當(dāng)然，答案是肯定的。把狀態(tài)暴露給方法使得這不是一個(gè)真正的promise。因?yàn)楝F(xiàn)在promise的保證已經(jīng)完全不可靠了。

如果你從一個(gè)第三方庫(kù)中得到了一個(gè)這樣的對(duì)象，你不會(huì)信任它的，不是嗎？更重要的，如果你把這個(gè)對(duì)象傳遞給其他第三方庫(kù)，你肯定不會(huì)相信只有原始的創(chuàng)建者才能修改它，不是嗎？

當(dāng)然不會(huì)相信。那就太天真了。

你看，使用promises是基于可靠性的。然后可靠性是基于promise的狀態(tài)是與外部影響隔離的，只有創(chuàng)建者能改變。注意到我并沒(méi)有說(shuō)狀態(tài)必須是私有的，只要它不會(huì)被外界改變就可以。

如果沒(méi)有promise的對(duì)象不會(huì)被除了創(chuàng)建者改變的可靠性，那么promise就幾乎失去了它的意義。

注意，這正是事情變得模糊的地方，是不可忽視的事實(shí)。

大多數(shù)為了在舊的JS環(huán)境下能夠支持promise的polyfill會(huì)把狀態(tài)通過(guò)可變的方式暴露出來(lái)。

Ouch!!!

在這方面，我的ES6 Promise polyfill"Native Promise Only"沒(méi)有把state暴露出來(lái)。據(jù)我所知，這是唯一一個(gè)沒(méi)有把promise狀態(tài)暴露出來(lái)的polyfill。
為什么？因?yàn)槲也粌H僅關(guān)心Promise規(guī)范，我更在意Promises的精髓。

但是究竟為什么所有這些高度可信的Promise polyfill和庫(kù)會(huì)忘了promise中這么重要的東西呢？因?yàn)樵谠鶭avascript有一些限制，這是一些內(nèi)置機(jī)制不需要遵循的。

簡(jiǎn)單的說(shuō)，即將到來(lái)的ES6標(biāo)準(zhǔn)指出Promise是一個(gè)“class”，所以作為一個(gè)“class”，promise必須可以被子類化。換句話說(shuō)，你必須可以創(chuàng)建一個(gè)class CustomPromise extends Promise{..}子類，在這個(gè)基礎(chǔ)上你可以擴(kuò)展內(nèi)置promises的功能。

例如，你需要一個(gè)自定義的promise，這個(gè)promise可以處理超過(guò)一條消息。至少理論上，實(shí)現(xiàn)這個(gè)只需要你繼承內(nèi)置Promise類然后擴(kuò)展它。

鑒于我對(duì)JS中類概念的偏見(jiàn)，我認(rèn)為Promise子類化是一種沒(méi)有意義的鬧劇或者轉(zhuǎn)移注意力的幌子。我努力讓自己想出一些Promise子類化的好處，可是我實(shí)在想不出來(lái)。

而且，如果要繼續(xù)保持一些特性來(lái)遵循Promises/A+ Test Suite,這些子類的實(shí)現(xiàn)很可能變得相當(dāng)笨拙。

最后，我對(duì)于promise的子類化沒(méi)有任何好感。

不涉及太多JS的細(xì)節(jié)，把Promise表達(dá)成一個(gè)可以被繼承的"class"需要你把實(shí)例方法加入到Promise.prototype對(duì)象中。

但是當(dāng)你這么做的時(shí)候，你就把then..()和catch(..)變成共享方法，所有Promise實(shí)例都可以訪問(wèn)到，然后這些方法只能通過(guò)this訪問(wèn)每個(gè)實(shí)例上的公共屬性。

換句話說(shuō)，如果要使得promise可以子類化，只使用簡(jiǎn)單的JS是不可能的，必須使用閉包或其他方法來(lái)為每個(gè)實(shí)例創(chuàng)建私有的promise狀態(tài)。

我知道現(xiàn)在你已經(jīng)開(kāi)始想各種你見(jiàn)過(guò)的可以實(shí)現(xiàn)閉包私有和this公共繼承混合的方法。

我可以寫(xiě)一整本書(shū)來(lái)說(shuō)明為什么這樣行不通，但是我這里就簡(jiǎn)單的說(shuō)下：不要管你所聽(tīng)到的，只使用ES5中可以使用的方法，你是不可能創(chuàng)建私有狀態(tài)同時(shí)又可以有效子類化的promise。

這兩個(gè)概念在ES5以下是互相排斥的。

另一個(gè)ES6中的新特性是WeakMap。簡(jiǎn)單的說(shuō)，一個(gè)WeakMap實(shí)例能夠使用對(duì)象引用作為鍵，然后和一個(gè)數(shù)據(jù)相聯(lián)系，而不需要真正把數(shù)據(jù)存儲(chǔ)在對(duì)象上。

這正是我們需要的，不是嗎？我們需要一個(gè)我們公共的then(..)和catch(..)可以訪問(wèn)的WeakMap，無(wú)論this綁定的是什么，它們都可以根據(jù)this訪問(wèn)到并且查找對(duì)應(yīng)的被保護(hù)的狀態(tài)值。這個(gè)特權(quán)Promise方法可以取得這個(gè)內(nèi)部狀態(tài)，但是外部不能。

不過(guò)，事情并沒(méi)有這么美好：

WeakMap根本不可能通過(guò)原生JS用性能可接受的方法實(shí)現(xiàn)。

就算我們?cè)贓S5及以下可以使用WeakMap，它還是沒(méi)有完全解決子類化的問(wèn)題，因?yàn)槟惚仨氹[藏WeakMap實(shí)例使得只有你的Promise方法可以訪問(wèn)，但是這樣的話另一個(gè)Promise的子類也能訪問(wèn)到。

假設(shè)我們可以解決第二個(gè)問(wèn)題---其實(shí)我們不能，就做一個(gè)假設(shè)。那么WeakMap的實(shí)現(xiàn)應(yīng)該是什么樣的呢？

var WeakMap = function(){
    var objs = [], data = [];

    function findObj(obj) {
        for (var i=0; i
OK，基本的思想就是我們維護(hù)兩個(gè)數(shù)組(objs，data)，通過(guò)下標(biāo)相對(duì)應(yīng)。在第一個(gè)數(shù)組中保存對(duì)象引用，在另一個(gè)保存數(shù)據(jù)。
漂亮，不是嗎？
看看性能怎么樣吧?？纯?b>findObj(..)，它要循環(huán)整個(gè)數(shù)組來(lái)找到相應(yīng)的數(shù)據(jù)。引用越多性能就越低。
但是這還不是最壞的地方。WeakMap之所以叫做“Weak”是由于垃圾回收行為。在我們WeakMap的實(shí)現(xiàn)中，會(huì)保存每個(gè)對(duì)象的引用，這就意味著就算程序已經(jīng)沒(méi)有對(duì)于對(duì)象的引用了，這些對(duì)象還是不能被回收。但是真正的WeakMap就是這么“weak”，所以你不需要做任何事情來(lái)優(yōu)化垃圾回收。
好的，WeakMap是一個(gè)錯(cuò)誤的希望。它并沒(méi)有解決ES6中的問(wèn)題并且使得事情在ES5及以下變得更糟。
保護(hù)state還是子類化？
這是個(gè)問(wèn)題！
我真的希望我能創(chuàng)建一個(gè)忠實(shí)的Peomisepolyfill給ES5及以下。但是必須做一個(gè)選擇，在這里出現(xiàn)了一個(gè)分歧。要不就放棄子類化的功能，要不就放棄作為promise的可靠性。
那么我們?cè)撛趺醋瞿兀?/p>
總結(jié)
我會(huì)做另一個(gè)promise polyfill，這個(gè)polyfill選擇保留子類化的能力，以可變的state為代價(jià)。
我已經(jīng)選擇了拋棄子類化使得我的promise polyfill可以很可靠。就像我之前說(shuō)的，我認(rèn)為promise的子類化最終會(huì)被證明是一個(gè)華而不實(shí)的東西。我不會(huì)犧牲promise的可靠性來(lái)順從子類化。
很顯然，其他人對(duì)于這個(gè)問(wèn)題會(huì)有不同的看法。但是我只想讓你問(wèn)問(wèn)你自己：一個(gè)不可靠的promise可以用來(lái)干嘛？什么代碼能真正拯救你？什么代碼可以做得更好？
現(xiàn)有的Promise polyfill和庫(kù)的問(wèn)題比不可變的state vs 子類化更深層面。在第四部分：擴(kuò)展問(wèn)題中，我會(huì)指出許多現(xiàn)有polyfill和庫(kù)中的問(wèn)題。
譯者注
這篇文章不大好翻譯也不大好理解，所以在這里總結(jié)下我的理解，希望對(duì)大家的理解有所幫助，如果大家有什么不同的看法，歡迎討論。
這篇文章圍繞Promise的可靠性展開(kāi)，Promise的可靠性是它的精髓所在。要實(shí)現(xiàn)Promise的可靠性最關(guān)鍵的就是要保證Promise的狀態(tài)值state不能被外部改變，這樣才能保證狀態(tài)值的不可逆。
而現(xiàn)在幾乎所有的Promise庫(kù)都忽略了這個(gè)關(guān)鍵，而它們會(huì)忽略這個(gè)關(guān)鍵點(diǎn)一個(gè)很重要的原因就是在ES6的規(guī)范中，Promise被規(guī)定為一個(gè)類，也就是說(shuō)Promise是可以被子類化的。然而在ES5及以下的規(guī)范中，在沒(méi)有private關(guān)鍵字的情況下，是不可能實(shí)現(xiàn)可子類化同時(shí)又能保證Promise的狀態(tài)值不會(huì)被外部改變（真的嗎？我保持懷疑態(tài)度）。而在ES6中出現(xiàn)的新對(duì)象WeakMap確實(shí)給實(shí)現(xiàn)Promise帶來(lái)了新的思路，可以在ES5及以下環(huán)境中實(shí)現(xiàn)WeakMap，利用它的特點(diǎn)可以實(shí)現(xiàn)符合要求的Promise。具體實(shí)現(xiàn)思路就是：定義一個(gè)全局私有的WeakMap，這個(gè)WeakMap只有公共的方法then()和catch()可以訪問(wèn)到，在這個(gè)WeakMap中以每個(gè)Promise實(shí)例的this作為鍵，狀態(tài)值state作為值進(jìn)行存儲(chǔ)。這樣在每個(gè)Promise實(shí)例中都可以通過(guò)自己的this對(duì)象查找自己的狀態(tài)值，而不能查找到其他Promise實(shí)例的狀態(tài)值，這樣就實(shí)現(xiàn)了狀態(tài)值的外部不可修改。但是WeakMap有一個(gè)很大的問(wèn)題就是性能比較低并且不利于垃圾回收，所以這并不是一個(gè)理想的解決方案。
綜上兩個(gè)原因就導(dǎo)致了現(xiàn)在大部分庫(kù)暴露state狀態(tài)值，它們?yōu)榱藢?shí)現(xiàn)子類化選擇了暴露狀態(tài)值，丟棄了Promise的精髓所在。
而在作者看來(lái)子類化對(duì)于Promise的重要性遠(yuǎn)遠(yuǎn)比不上Promise的可靠性，所以它選擇了放棄子類化而保證Promise的可靠性。事實(shí)確實(shí)是這樣，如果不能保證Promise的可靠性，那么就會(huì)出現(xiàn)第一篇中出現(xiàn)的那個(gè)不可靠的情況，這樣Promise除了改善了回調(diào)金字塔的問(wèn)題，跟普通的回調(diào)也就沒(méi)有什么區(qū)別了，也就失去了它更重要的意義。
深入理解Promise五部曲--1.異步問(wèn)題
深入理解Promise五部曲--2.轉(zhuǎn)換問(wèn)題
深入理解Promise五部曲--3.可靠性問(wèn)題
深入理解Promise五部曲--4.擴(kuò)展性問(wèn)題
深入理解Promise五部曲--5.樂(lè)高問(wèn)題
最后，安利下我的個(gè)人博客，歡迎訪問(wèn)：http://bin-playground.top