JavaScript
Diferencia tasks y microtasks, explica su orden en el Event Loop y cómo promesas, queueMicrotask y renderizado compiten por el hilo principal.
Una inicia una unidad de trabajo del host. Una representa una continuación de alta prioridad que se procesa cuando termina la ejecución actual, antes de avanzar normalmente hacia otra task.
console.log("A");
setTimeout(() => console.log("task"), 0);
Promise.resolve().then(() => {
console.log("microtask");
});
console.log("B");Resultado habitual:
A
B
microtask
taskLa plataforma mantiene distintas task sources; no todas viven necesariamente en una sola cola literal.
then, catch, finally.await.queueMicrotask.Después de que termina una task o una ejecución relevante, el runtime procesa microtasks hasta vaciar la cola.
queueMicrotask(() => {
console.log("first");
queueMicrotask(() => {
console.log("second");
});
});La segunda también puede ejecutarse dentro del mismo checkpoint.
function repeat() {
queueMicrotask(repeat);
}
repeat();Si cada microtask agrega otra, el navegador puede no alcanzar otra task ni una oportunidad de renderizado.
Las microtasks no son una forma de “hacer trabajo gratis”.
let ready = false;
Promise.resolve().then(() => {
console.log(ready); // true
});
ready = true;Incluso una promesa ya resuelta programa su reacción como trabajo posterior.
queueMicrotask(() => {
synchronizeState();
});Comunica directamente que deseas una microtask. Usar una promesa resuelta solo para programar puede distorsionar el propósito y cambia algunos detalles de reporte de errores.
El navegador suele considerar renderizar entre tasks, después de microtasks, pero no debe asumirse un paint exacto tras cada callback.
element.textContent = "Loading";
heavyWork();
element.textContent = "Done";El usuario puede no alcanzar a ver Loading porque el hilo no obtuvo una oportunidad de pintar entre ambas asignaciones.
requestAnimationFrame programa trabajo cercano a una actualización visual.
element.textContent = "Loading";
requestAnimationFrame(() => {
heavyWork();
element.textContent = "Done";
});Aun así, heavyWork puede bloquear el frame si es demasiado largo.
async function example() {
console.log("inside A");
await null;
console.log("inside B");
}
console.log("start");
example();
console.log("end");Resultado:
start
inside A
end
inside BLa parte posterior a await se reanuda mediante una continuación asociada a promesas.
queueMicrotask(() => {
throw new Error("Failed");
});El error ocurre fuera del stack que programó la microtask. Un try alrededor de queueMicrotask no lo captura.
Las microtasks permiten agrupar múltiples cambios síncronos antes de ejecutar una actualización.
let scheduled = false;
function scheduleFlush() {
if (scheduled) return;
scheduled = true;
queueMicrotask(() => {
scheduled = false;
flushChanges();
});
}Varias llamadas dentro de la misma task producen un solo flush.
Una microtask continúa antes de la siguiente task y normalmente antes del renderizado. Para ceder realmente, utiliza una API que programe trabajo en otro momento apropiado.
try exterior un error lanzado después.requestAnimationFrame con un worker.await utilizan microtasks.¿Por qué queueMicrotask no es apropiado para dividir un cálculo largo y mantener la interfaz fluida?
Porque las microtasks se vacían antes de continuar normalmente hacia otra task y una oportunidad de renderizado. Una cadena de microtasks puede seguir monopolizando el hilo.
Timers y planificación explica qué garantizan realmente setTimeout y setInterval, y cómo elegir mecanismos de scheduling.