Hacemos una verificación profunda cada uno de los escritos de nuestra web con el objetivo de mostrarte en todo momento la información con la mayor veracidad y certera.
Solución:
Hay varias formas de manejar eventos en javascript / jQuery. Dos de ellos son:
- Puede utilizar un controlador de eventos directo en el objeto.
- Puede usar el manejo de eventos delegados donde maneja un evento propagado en un padre.
Si está utilizando un controlador de eventos directo en el objeto y no hay controladores de eventos delegados configurados en la página, entonces no hay razón para e.stopPropagation().
Pero, si tiene controladores de eventos delegados que utilizan la propagación, a veces desea asegurarse de que un controlador de eventos delegado de nivel superior no se active en el evento actual.
En tu ejemplo particular:
$(document.body).on('click', "a.ajaxLink", function(e){
Este es un controlador de eventos delegado. Busca cualquier evento de clic que se propague hasta el document.body objeto, pero se originó en un a.ajaxLink objeto. Aquí, hay pocas ventajas para e.stopPropagation() porque el evento ya se ha propagado casi por completo (también subirá a la document, pero a menos que también tenga un controlador para click sobre el document objeto, entonces no hay razón para e.stopPropagation() en este controlador.
Donde tendría mucho sentido sería cuando tiene un controlador de eventos delegado de nivel superior (como el de su ejemplo) y tiene controladores de eventos de nivel inferior (ya sea directamente en los objetos o utilizando el manejo de eventos delegado, pero en un nivel por debajo del document.body objeto. En ese caso, si solo desea que el controlador de eventos de nivel inferior obtenga el evento, entonces llamaría e.stopPropagation() en su manejador para que el document.body el manejador nunca vio el evento.
$("a.ajaxLink").click(function(e)
if (some condition)
// do something specific to this condition
code here
// stop propagation so the default behavior for click in document.body does not fire
e.stopPropagation();
)
Nota: Usando return false desde un controlador de eventos jQuery activa tanto e.stopPropagation() y e.preventDefault(). Pero, si está en un controlador de eventos delegado, el e.preventDefault() no hace nada porque el comportamiento predeterminado (si hubiera uno) ya se disparó cuando el objeto de destino vio el evento por primera vez. Los comportamientos predeterminados ocurren antes de la propagación del evento, por lo que e.preventDefault() solo funciona en controladores de eventos directamente en el objeto de destino.
No hay una degradación notable del rendimiento porque permite que un evento aumente porque estos son eventos de nivel de usuario y simplemente no ocurren lo suficientemente rápido como para importar, el burbujeo no es particularmente lento cuando no hay controladores en todos los objetos intermedios. El sistema ya casos especiales algunos eventos como mousemove eso puede suceder rápidamente para resolver ese problema. Si tiene un proyecto gigante con cientos o miles de controladores de eventos, hay casos en los que el manejo de eventos delegado es más eficiente y hay casos en los que los controladores de eventos directos en los objetos de destino reales son más eficientes. Pero, excepto en escenarios gigantes, la diferencia de rendimiento probablemente no sea notable.
Aquí hay un ejemplo donde el burbujeo / delegación es más eficiente. Tiene una tabla gigante con miles de filas y cada fila tiene dos botones (agregar / eliminar decir). Con el manejo de eventos delegado, puede manejar todos los botones en dos manejadores de eventos simples que adjunta al objeto de tabla (un padre común de los botones). Esto será mucho más rápido para instalar los controladores de eventos en lugar de instalar varios miles de controladores de eventos directamente en todos y cada uno de los botones. Estos controladores de eventos delegados también funcionarán automáticamente en filas / objetos recién creados en la tabla. Este es el escenario ideal para los controladores de eventos delegados / de propagación de eventos. Tenga en cuenta que, en este escenario, no hay razón para detener la propagación / propagación.
A continuación, se muestra un ejemplo en el que los controladores de eventos delegados son muy ineficientes. Supongamos que tiene una página web de buen tamaño con cientos de objetos y controladores de eventos. Puede hacer que cada uno de los controladores de eventos sea un controlador de eventos delegado adjunto al document objeto. Pero esto es lo que sucede. Ocurre un clic. No hay un controlador de eventos en el objeto real, por lo que aparece. Finalmente, llega al objeto del documento. El objeto de documento tiene cientos de controladores de eventos. El motor de procesamiento de eventos (jQuery en este caso) tiene que examinar cada uno de esos controladores de eventos y comparar el selector en el controlador de eventos delegado para cada uno con el objetivo del evento original para ver si coinciden. Algunas de estas comparaciones no son rápidas, ya que pueden ser selectores CSS completos. Tiene que hacer eso para cientos de eventos delegados. Esto es malo para el rendimiento. Esta es exactamente la razón .live() en jQuery estaba en desuso porque funcionaba de esta manera. En cambio, los controladores de eventos delegados deben colocarse lo más cerca posible del objeto de destino (el padre más cercano que sea práctico dadas las circunstancias). Y, cuando no hay necesidad de un controlador de eventos delegado, los controladores deben colocarse en el objeto de destino real, ya que este es el más eficiente en tiempo de ejecución.
De vuelta a tu pregunta original. No hay tiempo en el que desee desactivar el burbujeo en general. Como describí anteriormente en mi respuesta, hay instancias específicas en las que un controlador de eventos más lejos en el árbol quiere manejar el evento y evitar que cualquier controlador de eventos delegado más arriba en el árbol DOM procese este evento. Ese es un momento para e.stopPropatation().
Aquí hay varias otras publicaciones relevantes con información útil sobre este tema (como se ha discutido ampliamente antes):
¿Por qué no llevar la delegación de eventos de Javascript al extremo?
¿Todos los eventos de jquery deberían estar vinculados a $ (documento)?
¿JQuery.on () funciona para elementos que se agregan después de que se crea el controlador de eventos?
jQuery en () y stopPropagation ()
Práctica recomendada para evitar problemas de memoria o rendimiento relacionados con la vinculación de una gran cantidad de objetos DOM a un evento de clic
Método jQuery .live () vs .on () para agregar un evento de clic después de cargar HTML dinámico
Imagina que tienes un botón y quieres gestionar un evento de clic:
Sin la propagación de eventos, hacer clic en la imagen o el texto no activaría el controlador de eventos de clic vinculado al botón, ya que el evento nunca saldría del elementos.
Un caso en el que no desea la propagación de eventos es cuando los elementos anidados tienen sus propios controladores de eventos. He aquí un ejemplo:
Si no detiene la propagación del evento con .arrowcontrolador de eventos, también activará el controlador de eventos del botón.
Recuerda dar difusión a esta noticia si lograste el éxito.