Eşzamanlı yinelemelerde… beklemek için kullanma

MDN'nin iki kullanım durumu olduğunu söylüyor for await...of :

for await...ofİterable yanı sıra senkronizasyon Iterables üzerinde nesneleri zaman uyumsuz ifadesi yineleme bir döngü oluşturur ...

Daha öncekinin farkındaydım: kullanarak asenkron yinelenebilir Symbol.asyncIterator. Ama şimdi ikincisi ile ilgileniyorum: senkron yinelemeler.

Aşağıdaki kod senkronize bir yinelenebilir - bir dizi vaat üzerinden yinelenir. Her vaadin yerine getirilmesi konusundaki ilerlemeyi engelliyor gibi görünmektedir.

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('happy'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('sad')))
        const promises = [happy, sad]
        for await(const item of promises) {
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Davranış, aşağıda gösterilen mantığa göre her bir sözü sırayla beklemeye benziyor gibi görünmektedir. Bu iddia doğru mu?

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('happy'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('sad')))
        const promises = [happy, sad]
        for(let p of promises) {
            const item = await p
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Ben soruyorum çünkü bu kod paterni kapalı bir ret telsizi tuzağına sahip Promise.allve Promise.allSettledkaçınıyor ve bu kalıbın dil tarafından açıkça destekleneceği garip görünüyor.

window.addEventListener('unhandledrejection', () => {
  console.log('unhandled rejection; `sad` was not being awaited at the time it rejected')
})

async function asyncFunction() {
    try {
        const happy = new Promise((resolve)=>setTimeout(()=>resolve('success'), 1000))
        const sad = new Promise((_,reject)=>setTimeout(()=>reject('failure')))
        const promises = [happy, sad]
        for(let p of promises) {
            const item = await p
            console.log(item)
        }
    } catch (err) {
        console.log(`an error occurred:`, err)
    }
}

asyncFunction() // "unhandled rejection; `sad` was not being awaited at the time it rejected" (after about zero seconds), and then "happy, an error occurred: sad" (printed in quick succession, after about 5 seconds)

Evet, garip ve bunu yapmamalısın. Söz dizilerini tekrarlamayın, tam olarak bahsettiğiniz işlenmeyen reddetme sorununa yol açar .

Peki bu neden dilde destekleniyor? Özensiz söz semantiği ile devam etmek.

Teklifin bu kısmını tartışan sorunun bu yorumunda tam mantığı bulabilirsiniz :

Sanırım geri dönmeliyiz, Symbol.iteratorçünkü mevcut Promise semantiğimiz tamamen senkronize şeylerin asenkron şeyler olarak kullanılmasına izin vermekle ilgilidir. Buna "özensizlik" diyebilirsiniz. Bu izler yukarıdaki yeraltı suyu mantığı @ , ama sadece daha ayrıntılı olarak paralellikler duymak istiyorsun.

"Zincirleme" anlambilimi bununla ilgilidir .then. Bir Söz .thenveya skaler değer döndürebilirsiniz ; hepsi aynı. Bir Promise.resolveSöz'e bir şey sarmamayı değil, bir Söz'e bir şey aktarmayı çağırırsınız - ya da başka bir şey olduğunda asenkron bir değer elde edin.

Anlambilimi asyncve anlamsızlığı da awaitönemlidir. Bir zaman awaituyumsuz işlevinde Promise olmayan herhangi bir ifadeye tokat atabilirsiniz ve iş kuyruğuna denetim vermeniz dışında her şey aynı şekilde çalışır. Benzer şekilde, sonuç async olarak istediğiniz her şeyi "savunmasız" olarak koyabilirsiniz await. Bir Promise döndüren bir fonksiyonunuz varsa - her neyse! bunu bir asyncişlev haline getirebilir ve kullanıcı açısından hiçbir şey değişmez (teknik olarak farklı bir Promise nesnesi çıkarsanız bile).

Asenkron yineleyiciler ve jeneratörler aynı şekilde çalışmalıdır. Tıpkı yanlışlıkla bir Promise olmayan bir değeri beklediğiniz gibi, makul bir kullanıcı yield*bir zaman uyumsuz üreteç içinde bir yineleyiciyi senkronize etmeyi bekleyebilir . for awaitdöngüler benzer şekilde "sadece" bir kullanıcı bu şekilde defansif bir yineleyici alıyor olabileceğini düşünerek bir döngüyü bu şekilde işaretlerse çalışmalıdır.

Bence bu paralelliklerin hepsini kırmak çok önemli olurdu. Asenkron yineleyicileri daha az ergonomik hale getirir. TC39'da asenkron jeneratörler / yineleyiciler bir sonraki gündeme geldiğinde bunu tartışalım.

sadSöz edilmez olma awaitkod ihtiyaçları bekleyen bitirmek olduğunu - bu başarısız olduğunda ed happyo beklemek başlamadan önce sad. Karar sadvermeden önce söz başarısız oluyor happy. ( Promise.allbu kullanım senaryosuna daha uygun bir araçtır)