Delegación de eventos en JavaScript: gestionar interacciones desde el contenedor

Cómo funciona el burbujeo, qué simplifica la delegación y cuándo conviene controlar la propagación.

La delegación de eventos consiste en registrar un listener en un elemento padre para atender las interacciones de varios hijos. Cuando un clic asciende hasta ese padre por burbujeo, el manejador consulta event.target para identificar su origen y decidir si debe actuar. La ventaja central es reducir los puntos de registro y facilitar el manejo de contenido dinámico, no garantizar una aceleración determinada. [2]

In this article

1. La idea esencial: escuchar en el padre, distinguir al hijo
2. El burbujeo explica por qué funciona
3. Ejemplo práctico: una lista que admite nuevos elementos
4. Compartir una función no es lo mismo que delegar
5. Controlar la propagación sin romper la delegación

1. La idea esencial: escuchar en el padre, distinguir al hijo

Un punto de escucha: un contenedor puede gestionar clics de varios elementos hijos mediante un único listener. [2]
Un origen que identificar: event.target permite saber qué elemento recibió la interacción y filtrar los casos relevantes. [2]
Una estructura preparada para crecer: el patrón resulta útil cuando se añaden hijos dinámicamente. [2]

Imagina una lista cuyos elementos deben responder de la misma manera a un clic. Una solución consiste en recorrerlos y registrar un manejador en cada uno. La delegación cambia el lugar de registro: el listener se instala en la lista, no en cada elemento. Después, el manejador decide qué hacer según el origen del evento. No desaparece la necesidad de distinguir las interacciones; esa decisión pasa a estar centralizada. Esta separación entre dónde se escucha y dónde ocurrió el clic es la clave para comprender el patrón. [2]

2. El burbujeo explica por qué funciona

Los elementos de una página pueden estar anidados: por ejemplo, un botón dentro de un contenedor. En el mecanismo de burbujeo, un clic originado en un hijo puede llegar al padre y activar su manejador. Aplicado a una lista, el recorrido relevante es: se pulsa un elemento, el evento alcanza ese objetivo, asciende a la lista y ejecuta el listener registrado en ella. La delegación aprovecha ese recorrido; no necesita instalar una respuesta independiente en cada hijo para atender esa interacción. [1], [2]

Dentro del manejador del padre, event.target identifica el elemento donde se originó el evento. Por eso escuchar en el contenedor no equivale a considerar que cualquier clic corresponde a una opción válida. El ejemplo de GeeksforGeeks introduce precisamente una comprobación del tipo de elemento antes de responder. La distinción práctica es importante: recibir el evento y aceptarlo como una acción de la interfaz son decisiones diferentes. El filtro expresa qué objetivos pertenecen a la interacción que queremos gestionar. [2]

3. Ejemplo práctico: una lista que admite nuevos elementos

Este ejemplo ilustrativo crea una lista de tareas con texto simple. El único listener de clic se registra en la lista; los elementos se agregan sin listeners propios. La comparación normaliza el nombre del nodo antes de comprobarlo. Así se expresa el filtro por tipo de elemento sin depender de cómo se escriban las mayúsculas en esa comprobación. El código puede ejecutarse cuando el documento ya disponga de su elemento body. [2]

const lista = document.createElement("ul");
document.body.appendChild(lista);

lista.addEventListener("click", (evento) => {
  const objetivo = evento.target;

  if (objetivo.nodeName.toLowerCase() !== "li") {
    return;
  }

  console.log("Tarea seleccionada:", objetivo.textContent);
});

function agregarTarea(texto) {
  const tarea = document.createElement("li");
  tarea.textContent = texto;
  lista.appendChild(tarea);
}

agregarTarea("Revisar el informe");
agregarTarea("Preparar la reunión");

// También se puede llamar después, sin registrar otro listener.
agregarTarea("Enviar el resumen");

[2] [2] [2] [2] [2]

Al pulsar el texto de una tarea, el evento asciende a la lista y el manejador muestra su contenido. Al agregar otra tarea mediante agregarTarea, no hay que repetir el registro del listener: la nueva tarea participa del mismo mecanismo. El alcance del ejemplo es deliberadamente sencillo: elementos de lista con texto, sin controles ni etiquetas internas. Si se cambia esa estructura, también debe revisarse el filtro; comprobar únicamente que el objetivo sea un elemento de lista no contempla todos los posibles descendientes de una interfaz más compleja. [2]

4. Compartir una función no es lo mismo que delegar

Hay una mejora intermedia que conviene distinguir: definir una función una sola vez y registrarla en varios hijos. Eso evita crear funciones equivalentes repetidamente, pero cada hijo sigue teniendo su propio listener. La delegación da un paso diferente al trasladar el registro al padre. La tabla compara estas decisiones de estructura, no resultados de una prueba de velocidad. Permite separar dos cuestiones que suelen confundirse: cuántas funciones se crean y en cuántos elementos se registra la escucha. [2]

GeeksforGeeks presenta la reducción de listeners como una mejora de rendimiento y memoria. La conclusión útil es más acotada: delegar reduce los registros asociados individualmente a los hijos y puede simplificar su gestión. No hay aquí mediciones para prometer cuánto más rápida será una aplicación. Por tanto, conviene elegir el patrón por su adecuación a una colección de interacciones similares y por su mantenimiento; si la velocidad es un requisito concreto, debe comprobarse en la aplicación correspondiente. [2]

Enfoque	Dónde se registra la escucha	Distinción práctica
Función independiente por hijo	En cada elemento hijo	Repite funciones de respuesta equivalentes. [2]
Función compartida	En cada elemento hijo	Reutiliza la función, pero mantiene los listeners individuales. [2]
Delegación	En el elemento padre	Centraliza la escucha y distingue el origen mediante event.target. [2]

5. Controlar la propagación sin romper la delegación

El burbujeo también puede activar respuestas que no se pretendían combinar. MDN muestra un video dentro de un contenedor: el clic en el video inicia la reproducción, mientras que el clic gestionado por el contenedor lo oculta. Sin controlar la propagación, pulsar el video ejecuta ambas acciones. La solución de ese ejemplo llama a event.stopPropagation() en el manejador del video, de modo que ese clic no continúa ascendiendo hasta el contenedor. [1]

Esa solución tiene una consecuencia directa para la delegación: si un hijo detiene el ascenso del evento antes de que llegue al padre, el listener delegado no podrá atenderlo por ese recorrido. No conviene utilizar stopPropagation() como una corrección automática ante cualquier comportamiento inesperado. Primero hay que decidir qué contenedor debe recibir la interacción y qué objetivos debe aceptar su manejador. Filtrar una acción en el padre y cortar la propagación en el hijo resuelven problemas diferentes. [1], [2]

Frequently asked questions

¿Delegar significa que event.target pasa a ser el padre?

No. El listener está registrado en el padre, pero event.target identifica el elemento que originó la interacción. Precisamente esa diferencia permite centralizar la escucha sin perder la información necesaria para distinguir qué hijo recibió el clic. [2]

¿Por qué sirve para elementos añadidos dinámicamente?

Porque la escucha está en el contenedor y no depende de haber registrado un listener en cada hijo durante su creación. Si el evento del nuevo elemento asciende hasta ese contenedor y el filtro lo acepta, el mismo manejador puede atenderlo. [2]

¿Una función reutilizada ya constituye delegación?

No necesariamente. Puedes registrar una misma función en todos los hijos y seguir teniendo un listener en cada uno. Hay delegación en el enfoque descrito cuando el registro se concentra en el padre y el manejador utiliza el origen del evento para decidir cómo responder. [2]

¿La delegación garantiza un mejor rendimiento?

Reduce el número de listeners frente al registro individual descrito, pero eso no permite asegurar una mejora perceptible en cualquier interfaz. Las referencias no aportan un benchmark para cuantificarla. Es más preciso justificar la elección por la estructura de las interacciones y comprobar por separado los requisitos de rendimiento. [2]

¿Qué reviso si el padre no recibe el clic?

Comprueba si un manejador del hijo llama a stopPropagation(). MDN muestra que esa llamada impide que el clic siga ascendiendo al contenedor. Si la respuesta del padre depende del burbujeo, detenerlo antes interrumpe justamente el mecanismo que necesita la delegación. [1], [2]

Conclusion

La esencia de la delegación es aprovechar la propagación para escuchar en un lugar común y decidir según el origen. En listas de elementos similares, esto reduce registros individuales y facilita incorporar nuevos hijos. Para aplicarla correctamente, define el contenedor, filtra los objetivos relevantes y comprueba que ninguna interrupción de la propagación impida recibir el evento. Su valor está en una organización más adecuada de las interacciones, sin convertir esa ventaja estructural en una promesa de rendimiento no medida. [2], [1]

Source notes

La explicación se centra en clics y burbujeo; no establece que todos los tipos de eventos se comporten igual ni desarrolla variantes basadas en captura.

El ejemplo usa elementos de lista con texto simple. Las interfaces con descendientes internos requieren adaptar la identificación del objetivo.

Explore next

Sources

Open a source or expand its cited passages.

Relevance scores are model estimates of how well each source addresses this question, not probabilities or fact-check ratings. Reasoned guidance is identified on hover.