JQuery .on (); Vs JavaScript .addEventListener ();

Quelqu'un peut-il m'expliquer pourquoi y a-t-il une différence dans l'ordre dans lequel les gestionnaires d'événements sont exécutés en fonction de leur attachement? Dans l'exemple ci-dessous, j'utilise les méthodes .on() et .addEventListener() pour gérer un événement spécifique sur différents éléments DOM .

Jsfiddle : http://jsfiddle.net/etsS2/

Je pensais que dans cet exemple particulier, l'ordre dans lequel les gestionnaires d'événements vont être exécutés dépendra de l' event-bubbling des event-bubbling – donc à partir de la target événement d'origine et en remontant à l'élément du document .

 document.getElementById('outer').addEventListener('mouseup', function (event) { //$('#outer').on('mouseup', function (event) { alert('This alert should not show up!'); }, false);

Si je décompose le on(); Version tout fonctionne comme prévu – existe-t-il une différence dans la façon dont jQuery gère les événements contrairement au JavaScript simple?

Lorsque vous utilisez .on() au niveau du document, vous attendez que l'événement bouge jusqu'à ce point. Le gestionnaire d'événements pour tout conteneur intermédiaire sera déjà appelé.

L'événement "bubbling" est le processus par lequel le navigateur recherche les gestionnaires d'événements enregistrés auprès des parents de l'élément qui était le récipient original réelle de l'événement. Il fonctionne vers le haut dans l'arbre DOM. Le niveau du document est le dernier niveau vérifié. Ainsi, votre gestionnaire enregistré avec .on() ne fonctionnera pas jusqu'à ce que ce niveau soit atteint. En attendant, l'autre gestionnaire d'événements au niveau "externe" est atteint en premier et il est exécuté par le navigateur.

Ainsi, ce return false; Dans le gestionnaire enregistré avec .on() est à peu près inutile, comme un appel à event.stopPropagation() . Au-delà, mélanger l'enregistrement des gestionnaires d'événements natifs avec le travail qu'une bibliothèque comme jQuery fera est probablement une très mauvaise idée à moins que vous sachiez sérieusement ce que vous faites.

Une question a été posée presque exactement comme celle-ci il y a quelque temps encore aujourd'hui.

Regardez la version addEventListener :

 document.getElementById('outer').addEventListener('mouseup', function (event) { alert('This alert should not show up!'); }, false);

Cela fonctionne bien car le troisième argument est useCapture , qui spécifie si la phase de capture de l'événement doit être utilisée ou non.

Lorsque vous passez à la version jQuery:

 $('#outer').on('mouseup', function (event) { alert('This alert should not show up!'); }, false);

Je pense que ce qui se passe, c'est que le troisième argument ne fait que remplacer votre fonction de gestionnaire d'événements et entraîne le gestionnaire d'événements à ne rien faire que return false; Ce qui n'est clairement pas ce qui est prévu.

Du document jQuery (souligné dans l'original):

Une fonction à exécuter lorsque l'événement est déclenché. La valeur false est également autorisée en tant que raccourci pour une fonction qui renvoie faussement .

Supprimez le false argument et la version jQuery fonctionnera correctement:

 $('#outer').on('mouseup', function (event) { alert('This alert should not show up!'); });

Notez que l' alert devrait s'afficher, de sorte que l'approche addEventListener fonctionne correctement. Voir la réponse de @ Pointy pour savoir pourquoi.