0
351
VistasDelegación de eventos DOM o no, ¿cuál es el mejor recurso?
Contexto:
- HTML con una tabla larga con muchas filas y muchas columnas.
- Cada celda contiene elementos y subelementos adicionales.
- En la última celda de cada fila, botones diferentes pero iguales para cada fila
Pregunta:
En esta configuración, en cuanto a los recursos del navegador (fluidez, tiempo de carga, capacidad de respuesta,...) lo mejor es:
- ¿Usar un controlador de clic de delegado único en el elemento
<table>? Esto se desencadenaría con cualquier clic en cualquier otra celda o subelemento y, básicamente, se desencadenaría muchas más veces por nada. - ¿Usar un controlador de eventos en cada
<button>en cada fila? Esto agregaría muchos controladores, pero cada uno se ejecutaría solo una vez cuando fuera necesario. - Una alternativa ?
¿Hay una diferencia real para el navegador en sí? ( no consideremos las prácticas de codificación )
En el caso del (1) delegado, ¿el navegador no tiene que agregar oyentes a cada elemento secundario para saber que se ha hecho clic en él?
1 Respuestas
Responde la pregunta0
Las principales ventajas de rendimiento de la delegación de eventos en el caso que describe son
Solo tiene que conectar un controlador una vez, en lugar de recorrer todas las filas para hacerlo. Pero si tiene una mesa tan grande que conectar los controladores a los botones es una operación lenta, es probable que tenga otros problemas de rendimiento con esa mesa.
Un pequeño ahorro de memoria (las inscripciones de eventos).
No hay una desventaja de rendimiento de la que preocuparse si se trata de un controlador de click . (Eso podría no ser cierto para, digamos, un controlador de movimiento del mousemove ).
Hay complicaciones de código y problemas de mantenimiento a considerar (el controlador delegado es un poco más complicado de escribir; conectar el controlador a cada botón es más fácil de equivocarse si los botones se agregan dinámicamente en algún momento), pero ha dicho que está principalmente preocupado por el rendimiento.
En el caso del (1) delegado, ¿el navegador no tiene que agregar oyentes a cada elemento secundario para saber que se ha hecho clic en él?
No, solo el oyente de un evento. Lo que pasa es que hace clic en la burbuja . Aquí hay un diagrama de la antigua especificación de eventos DOM3 (no puedo encontrar este diagrama o un equivalente en la especificación ahora canónica WHAT-WG DOM , lo cual es desafortunado):
El controlador solo se adjunta a un elemento. Se encuentra cuando el clic burbujea (se propaga) a ese elemento.
- ¿Usar un controlador de clic de delegado único en el elemento
<table>? Esto se activaría con cualquier clic en cualquier otra celda o subelemento y, básicamente, se activaría muchas más veces por nada.
Eso es cierto, pero es inofensivo. La cantidad de trabajo requerida es prácticamente nula.
- ¿Usar un controlador de eventos en cada
<button>en cada fila? Esto agregaría muchos controladores, pero cada uno se ejecutaría solo una vez cuando fuera necesario.
No necesita muchos controladores , puede reutilizar la misma función para varios botones. Son solo registros múltiples de controladores:
function buttonHandler(event) { // ... } // ... for (const btn of document.querySelectorAll(".selector-for-button")) { btn.addEventListener("click", buttonHandler); // Adds a registration, not // an additional function } Eso no crea una nueva función para cada botón, reutiliza la misma función para todos los botones. Durante la llamada, event.currentTarget se referirá al botón específico en el que se hizo clic (al que conectamos el controlador). (Si el botón tiene elementos secundarios, event.target puede referirse a uno de esos elementos secundarios, pero event.currentTarget se referirá al botón).
Entonces, en cualquier situación dada, debe sopesar esas diversas consideraciones para decidir qué quiere hacer.