Al hacer clic, esto genera 1 y luego 2:
const myElem = document.getElementById("myElem") myElem.addEventListener('click', () => queueMicrotask(() => console.log(1))); window.addEventListener('click', () => console.log(2)); <button id="myElem">Click me</button> Si queueMicrotask se reemplaza con setTimeout , genera 2 y luego 1. Esto significa que el burbujeo ocurre en las microtareas, pero no en las macrotareas.
¿Es parte de la especificación DOM o solo un detalle de implementación del navegador?
Las únicas formas en que puede surgir un burbujeo de eventos en una tarea en cola micro sería que envíe un evento personalizado en un elemento desde el código que se ejecuta desde la cola de tareas de microtarea, o si los observadores de mutaciones reciben una señal interna de que el DOM ha sido modificado (usando eventos de "cambio de ranura") desde dentro de una microtarea. En ambos casos, los eventos se activan desde dentro de una microtarea que se está ejecutando, y el burbujeo de eventos se produce sincrónicamente en el subproceso de ejecución de JavaScript. Por el contrario, los eventos "nativos" son activados por el navegador e invocan los controladores de eventos de forma asíncrona a través del bucle de eventos .
Lo que falta en el escenario de eventos publicado es que si se agregaron varios controladores de eventos para el mismo tipo de evento nativo, los controladores se llaman desde el bucle de eventos . Por lo tanto, cualquier microtarea puesta en cola por un controlador se ejecutará antes de que el control de la llamada del controlador regrese a la cola de eventos.
A modo de demostración del flujo de eventos para dos controladores de "clic":
"use strict"; document.querySelector("div").addEventListener("click", click1); window.addEventListener("click", click2 /*, {capture:true}*/ ); function click1(event) { console.log("click1 called for div") queueMicrotask( ()=> console.log("microtask1 executes")); console.log("click1 exits"); } function click2(event) { console.log("click2 called for window") queueMicrotask( ()=> console.log("microtask2 executes")); console.log("click2 exits"); } div {background-color: yellow} <div>Click this div</div> or click the window,Ejecute el fragmento y haga clic en div para confirmar que se llama al controlador de div, sale y se ejecuta la microtarea que generó, antes de que se llame al controlador de ventana después de que se produzca la burbuja. Tenga en cuenta que, aunque se llamen desde el bucle de eventos, el orden en que se llamen dependerá de si se usa la captura de eventos (comentada en el fragmento).
Si reemplaza queueMicrotask con setTimeout en el controlador de primer clic de la publicación, la función de devolución de llamada ya no se ejecuta en la cola de microtarea antes de volver al bucle de eventos, lo que permite que el bucle de eventos llame al controlador de segundo clic (para un evento generado antes). caducidad del temporizador) antes de la devolución de llamada del temporizador.
La diferencia en el orden no se trata del burbujeo de eventos. Ocurre porque setTimeout , como los propios oyentes de clics, hace que la ejecución de su función anónima espere (al menos) una iteración completa del ciclo de eventos. El beneficio de queueMicrotask es evitar este retraso adicional.
Esto podría ayudar a aclarar el proceso:
const betweenTasks = (msg) => queueMicrotask( ()=>console.log(msg) ), futureTask = (msg) => setTimeout( ()=>console.log(msg), 0), myElem = document.getElementById("my-elem"); myElem.addEventListener("click", () => { futureTask("callbacks to `setTimeout` must wait additional iteration(s)"); betweenTasks("microtasks run between tasks"); console.log("callbacks to event listeners must wait in the task queue"); }); window.addEventListener("click", () => { console.log("bubbled callbacks happen later than direct-target callbacks"); }); <button id="my-elem">Click me</button>