Arrêter le bouillonnement d'événements - améliore-t-il les performances ?

Question

Si je ne reviens pas false à partir d'un rappel d'événement, ou en utilisant e.stopPropagation de jQuery, l'événement fait des bulles dans le DOM.

Dans la plupart des cas, je me fiche de savoir si l'événement fait des bulles ou non. Comme dans cet exemple de structure DOM :

<div id="theDiv">
    <form id="theForm" >
        <input type="submit" value="submit"/> 
    </form>
</div>

Normalement, je n'ai pas plusieurs callbacks de soumission imbriqués comme celui-ci :

$('#theDiv').submit(function() {
    alert('DIV!');
});
$('#theForm').submit(function(e) {
    alert('FORM!');
    e.preventDefault();
});

Violon
Cette DEMO montre la submit à une bulle d'événement <div> !
Cela ne fait aucune différence pour moi d'arrêter la propagation ou d'empêcher la défaillance.

Dans ces scénarios, Si j'arrête la propagation, est-ce que j'obtiendrai des avantages en termes de performances ?

Answer 1

Avantages en termes de performance ? Oui, il y a de légers avantages, comme indiqué dans le document suivant ce test de performance entre jQuery live() y on() . Comme @Joseph l'a également noté, la différence entre les deux est que le live se propage jusqu'en haut de l'arbre, alors que le on() ne va qu'au parent commun le plus proche.

Dans ces tests, il est démontré que on() peut surpasser live() jusqu'à 4 fois. En pratique, cela ne vaut probablement pas la peine de se fendre la poire, mais si vous avez des structures html très profondes et beaucoup de déclencheurs d'événements, la différence de performance dans l'arrêt de la propagation peut valoir la peine, je suppose.

Answer 2

Voici une comparaison entre on() y live() qui impliquent le bubbling et la raison pour laquelle jQuery a remplacé live() . le problème avec live() était que les événements étaient attachés au document, ce qui entraînait une longue remontée de l'arbre pour trouver le gestionnaire. on() est que vous pouvez attacher le gestionnaire au parent commun le plus proche, évitant ainsi le long voyage dans l'arbre à la recherche d'un gestionnaire - ce qui se traduit par des performances plus rapides.

mais je vous suggère de faire vos propres tests pour vérifier.

Answer 3

Ce test montre qu'il y a un avantage en termes de performances à interrompre l'événement plus tôt. (15%-30%) Et il y aurait probablement une plus grande différence sur un DOM complexe. Il est également intéressant de noter que les écouteurs d'événements capturés semblent être légèrement plus rapides que les écouteurs d'événements bouillonnants, indépendamment de ce que vous faites avec l'événement après l'avoir traité. C'est étrange mais intéressant ; je n'ai testé que dans un seul navigateur.