for await of : se supone que se usa con iteradores asincrónicos, espera cada promesa dentro del iterador y maneja la respuesta de cada promesa esperada en su cuerpo. Desde los documentos de MDN, esta sintaxis también se puede usar con iteradores de sincronización, por lo que
Tengo los siguientes ejemplos de código que funcionan de manera similar:
(async () => { const entityIds = [1, 2, 3, 4]; for await (const id of entityIds) { console.log(await getEntityById(id)); } })();Y:
(async () => { const entityIds = [1, 2, 3, 4]; for (const id of entityIds) { console.log(await getEntityById(id)); // ESLint: Unexpected `await` inside a loop.(no-await-in-loop) } })(); Pero en el segundo ejemplo, recibo una advertencia de eslint sobre la regla no-await-in-loop . La pregunta es: ¿por qué? Cada iteración de estos 2 bucles esperará a que se complete la función asíncrona, pero el eslint no reaccionará en absoluto en el primer caso.
Se supone que la regla de no espera en bucle en ESLint lo protege contra el procesamiento accidental de algunos datos secuencialmente. El razonamiento es que, a menudo, tener una await en un ciclo no es intencional porque es más eficiente procesar los datos en paralelo. Por lo tanto, todos los usos de await en un bucle se consideran un "error" cuando la regla está activada.
El uso for await...of se considera explícitamente "intencional" por la regla. Verificando las pruebas de la regla (parte inferior de la página de documentación), la siguiente parte aparece como código válido:
valid: [ // ... // Asynchronous iteration intentionally "async function foo() { for await (var x of xs) { await f(x) } }" ], mientras que cualquier uso de await en cualquier otra construcción de bucle no es válido. Incluyendo el uso de await dentro de un bucle dentro de un for await...of :
invalid: [ // ... // In a nested loop of for-await-of { code: "async function foo() { for await (var x of xs) { while (1) await f(x) } }", errors: [error] } ] El razonamiento más probable es que usar for await...of you opta por el procesamiento secuencial. Si procesa un iterable asincrónico, es muy probable que no pueda hacerlo en paralelo y sería un error si lo intenta. Si está procesando un iterable síncrono que produce promesas, todavía existe la posibilidad de que no pueda hacerlo correctamente en paralelo.
ESLint en realidad no puede detectar si tiene un iterable síncrono que produce resultados síncronos como un iterador de matriz, por lo tanto, asume que es una de las dos primeras opciones.
En mi opinión, la regla es defectuosa ya que es todo o nada. Habilitarlo significa que no desea bucles con await en ellos. Todavía hay casos válidos en los que desea un procesamiento secuencial con for...of y await inside. Lo que significa que es probable que su código esté plagado de inhabilitaciones temporales de la regla cuando no la necesite.
Mi sugerencia es deshabilitar la regla de no esperar en el ciclo y ejercitar el sentido común cuando usa procesamiento secuencial y paralelo.