同期イテラブルでの待機に使用する

MDNによると for await...of、2つのユースケースがあります。

このfor await...ofステートメントは、非同期反復可能オブジェクトだけでなく、同期反復可能オブジェクトに対してもループするループを作成します...

私は以前に前者を知っていました：を使用しSymbol.asyncIteratorた非同期反復可能オブジェクト。しかし、今は後者に興味があります。同期イテラブルです。

次のコードは、同期イテラブル（promiseの配列）を反復処理します。それは、各約束の履行の進展を妨げるように見えます。

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)

以下に示すロジックに従って、この動作は各プロミスを順番に待つのと同じように見えます。この主張は正しいですか？

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)

このコードのパターンには暗黙の拒否によるワイヤーアップの落とし穴がPromise.allありPromise.allSettled、それを回避するため、このパターンが言語によって明示的にサポートされているのは奇妙に思えます。

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)

はい、それは奇妙です、そしてあなたはこれをするべきではありません。promiseの配列を反復しないでください。これは、あなたが言及した未処理の拒否の問題に正確につながります。

では、なぜこれが言語でサポートされているのでしょうか？ずさんな約束のセマンティクスを続ける。

正確な理由は、提案のこの部分について議論している問題のこのコメントにあります。

私たちはにフォールバックすべきだと思うSymbol.iterator私たちの現在の約束の意味が同期物事が非同期なものとして使用できるようにすることについてのすべてですので。これを「だらしない」と呼ぶかもしれません。上記の@groundwaterのロジックに従います が、類似点を詳しく説明したいだけです。

の「連鎖」セマンティクスは.then、これについてすべてです。Promise from .thenまたはスカラー値を返すことができます。それはすべて同じです。Promise.resolvePromiseで何かをラップするのではなく、何かをPromiseにキャストするように呼び出し ます。何かがある場合は非同期の値を取得します。

意味asyncとawaitすべて同様にずさんであることについてです。awaitジョブキューに制御を委譲することを除いて、非同期関数内の任意の非Promise式を平手打ちすることができ、すべてがまったく同じように正常に機能します。同様に、結果が得async られる限り、あなたが望むものを「防御的に」置くことができますawait。Promiseを返す関数がある場合-何でも！あなたはそれをasync機能させることができ 、ユーザーの観点からは、何も変更されません（技術的には、別のPromiseオブジェクトを取得したとしても）。

非同期イテレータとジェネレータは同じように動作するはずです。誤ってPromiseでなかった値を待つことができるのと同じように、合理的なユーザーはyield*、非同期ジェネレーター内の同期イテレーターを期待できます。for awaitユーザーが非同期的にイテレータを取得している可能性があると考えて、ユーザーがそのように防御的にループをマークした場合、ループも同様に「正常に機能する」はずです。

これらすべての類似点を打破することは大きな問題になると思います。これにより、非同期イテレータの人間工学性が低下します。次回、非同期ジェネレーター/イテレーターがTC39の議題に登場するときに、これについて話し合いましょう。

sad約束はされていないことawait、それが失敗したとき編-そのコードは、上で待機して終了する必要がありhappy、それが上の待つ始めることができる前にsad。sad約束は前に失敗してhappy解決します。（Promise.allこのユースケースにより適したツールです）