uso mutationobserver lugar eventos está desaprobado changes javascript dom browser javascript-events dom4

javascript - lugar - ¿Cuándo se activan las devoluciones de llamada de MutationObserver?



mutationobserver javascript (2)

Sé que las devoluciones de llamada de MutationObservers pueden ser llamadas en algún momento después del cambio DOM. Pero la pregunta es: ¿Cuál es el momento de estas devoluciones de llamada? ¿Las retrollamadas ingresan a la cola de eventos de los navegadores? Si es así, ¿cuándo ingresan a la cola?

Son las devoluciones de llamada:

  • llamado inmediatamente después de que tenga lugar la mutación DOM,
  • se llama tan pronto como termina la función que manipula el DOM,
  • llamada tan pronto como la pila de llamadas esté vacía,
  • en cola inmediatamente después de la mutación DOM,
  • enqueued tan pronto como la función que manipula DOM termine, o
  • en algún otro momento?

Por ejemplo, si se ejecuta el siguiente fragmento de código (con setZeroTimeout definido aquí ):

var target = document.body; new MutationObserver(function(mutations) { console.log(''MutationObserver''); }).observe(target, { attributes: true, childList: true, characterData: true }); // Post message setZeroTimeout(function () { console.log(''message event''); }); // DOM mutation target.setAttribute("data-test", "value");

¿Se debe imprimir "MutationObserver" antes de "message event" o después? ¿O está definido por la implementación?

Obtendré "MutationObserver" antes de "message event" en Chromium 26, aunque la mutación DOM se produce después de la publicación del mensaje. Tal vez esto indica que las devoluciones de llamada de MutationObserver no están utilizando la cola de eventos.

Busqué en Google la especificación HTML, la especificación DOM o los documentos de implementación del navegador, pero no encontré nada relacionado con este comportamiento.

¿Alguna explicación o documentación sobre el momento de devolución de llamada de MutationObservers, por favor?


Los servidores MutationObservers se disparan de forma asincrónica pero ''pronto'', lo que significa que se activan antes que otras cosas en la cola, como el diseño, la pintura o los eventos desencadenados.

Esto mejora la pérdida de sincronía, ya que no tiene que preocuparse por el parpadeo de la pantalla u otras cosas malas que suceden antes de que su observador tenga la oportunidad de reaccionar.

En las notas para desarrolladores, hablan sobre un modelo de tiempo ''final de microtask''. Estoy de acuerdo que esto está mal documentado.


Voy a responder mi propia pregunta dos años después de acuerdo con las especificaciones DOM actualizadas de WHATWG .

Como se muestra en la especificación:

Para poner en cola una microtaxis compuesta del observador de la mutación, ejecuta estos pasos:

  1. Si se establece el indicador de cola de microtask compuesto de observador de mutación, finalice estos pasos.
  2. Establezca la bandera en cola compuesta microtask del observador de la mutación.
  3. Ponga en cola una microtaxis compuesta para notificar a los observadores de la mutación.

Mientras "Hacer cola una microtask compuesta" se vincula a una sección en la especificación HTML que explica el modelo de cola microtask.

Por lo tanto, podemos concluir que las devoluciones de llamadas de MutationObserver se activan como microtaks, que son más rápidas que las tareas de cola de tareas, tal como lo sugiere la respuesta de @Scott Miles anterior .

Para una mayor comprensión del ciclo de eventos y el modelo de procesamiento, la sección de bucle de eventos de la especificación HTML sería perfecta.

Personalmente, me complace ver que MutationObserver s son parte del estándar y tienen un modelo de sincronización bien documentado y consistente. Con MutationObserver soportado en la mayoría de los navegadores modernos , creo que ahora son sólidos para el uso de producción.