Sử dụng để chờ đợi với các vòng lặp đồng bộ

MDN cho biết for await...of có hai trường hợp sử dụng:

Câu for await...oflệnh tạo ra một vòng lặp lặp qua các đối tượng lặp không đồng bộ cũng như trên các vòng lặp đồng bộ hóa, ...

Trước đây tôi đã biết về cái trước: async iterables bằng cách sử dụng Symbol.asyncIterator. Nhưng bây giờ tôi quan tâm đến cái sau: iterables đồng bộ.

Đoạn mã sau lặp lại qua một lần lặp đồng bộ - một mảng các lời hứa. Nó xuất hiện để chặn progess về việc thực hiện từng lời hứa.

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)

Hành vi có vẻ giống như chờ đợi lần lượt từng lời hứa, theo logic được hiển thị bên dưới. Là khẳng định này là chính xác?

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)

Tôi hỏi bởi vì mẫu mã này có một cạm bẫy từ chối ngầm ẩn Promise.allvà Promise.allSettledtránh, và có vẻ lạ đối với tôi rằng mẫu này sẽ được ngôn ngữ hỗ trợ rõ ràng.

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)

Vâng, nó là lạ, và bạn không nên làm điều này. Đừng mảng lặp của lời hứa, nó dẫn chính xác cho vấn đề unhandled-từ chối bạn đề cập đến .

Vậy tại sao điều này được hỗ trợ trong ngôn ngữ? Để tiếp tục với ngữ nghĩa lời hứa cẩu thả.

Bạn có thể tìm thấy lý do chính xác trong bình luận này về vấn đề thảo luận về phần này của đề xuất :

Tôi nghĩ rằng chúng ta nên quay trở lại Symbol.iteratorbởi vì ngữ nghĩa Promise hiện tại của chúng ta đều hướng đến việc cho phép những thứ đồng bộ hóa được sử dụng như những thứ không đồng bộ. Bạn có thể gọi đây là "sự cẩu thả". Nó tuân theo logic của nước ngầm ở trên , nhưng tôi chỉ muốn đánh vần các điểm tương đồng chi tiết hơn.

Các ngữ nghĩa "chuỗi" .thenlà tất cả về điều này. Bạn có thể trả về một Promise từ .thenhoặc giá trị vô hướng; tất cả đều giống nhau Bạn gọi Promise.resolvekhông phải để bọc một cái gì đó trong một Lời hứa, mà là để gửi một cái gì đó cho một Lời hứa - nhận được một giá trị không đồng bộ khi bạn có thứ gì đó hoặc thứ khác.

Các ngữ nghĩa của asyncvà awaittất cả là về cẩu thả là tốt. Bạn có thể tát awaitvào bất kỳ biểu thức không hứa hẹn nào trong hàm async và mọi thứ đều hoạt động tốt, chính xác theo cùng một cách, ngoại trừ việc bạn nhường quyền kiểm soát cho hàng đợi công việc. Tương tự như vậy, bạn có thể "phòng thủ" đặt async xung quanh bất cứ điều gì bạn muốn, miễn là awaitkết quả của bạn. Nếu bạn có một chức năng trả về một Promise - bất cứ điều gì! bạn có thể làm cho asyncchức năng đó và, từ góc độ người dùng, không có gì thay đổi (ngay cả khi, về mặt kỹ thuật, bạn nhận được một đối tượng Promise khác).

Các trình lặp và bộ tạo Async nên hoạt động theo cùng một cách. Giống như bạn có thể chờ đợi một giá trị, vô tình, không phải là một Promise, một người dùng hợp lý sẽ mong đợi có thể có yield*một trình lặp đồng bộ hóa trong một trình tạo không đồng bộ. for awaitcác vòng lặp sẽ tương tự "chỉ hoạt động" nếu người dùng đánh dấu một cách chắc chắn một vòng lặp theo cách đó, nghĩ rằng họ có thể đang nhận được một trình lặp không đồng bộ.

Tôi nghĩ rằng nó sẽ là một vấn đề lớn để phá vỡ tất cả những tương đồng. Nó sẽ làm cho các trình lặp async ít tiện dụng hơn. Chúng ta hãy thảo luận về điều này vào lần tới khi các trình tạo / lặp không đồng bộ xuất hiện trong chương trình nghị sự tại TC39.

Các sadlời hứa không được awaited khi nó không thành công - đó là nhu cầu mã để hoàn thành chờ đợi vào happytrước khi nó có thể bắt đầu chờ đợi sad. Các sadlời hứa là không trước khi happygiải quyết. ( Promise.alllà một công cụ phù hợp hơn với trường hợp sử dụng này)