578 votes

Différence entre .on('click') et .click()

Y a-t-il une différence entre les codes suivants ?

$('#whatever').on('click', function() {
     /* your code here */
});

et

$('#whatever').click(function() {
     /* your code here */
});

811voto

andreister Points 3163

Je pense que la différence réside dans les habitudes d'utilisation.

Je préférerais .on sur .click parce que l'ancien puede utilisent moins de mémoire et de travail pour les éléments ajoutés dynamiquement.

Considérons le html suivant :

<html>
    <button id="add">Add new</button>
    <div id="container">
        <button class="alert">alert!</button>
    </div>
</html>

où nous ajoutons de nouveaux boutons via

$("button#add").click(function() {
    var html = "<button class='alert'>Alert!</button>";
    $("button.alert:last").parent().append(html);
});

et que nous voulons que "Alerte !" affiche une alerte. Nous pouvons utiliser "click" ou "on" pour cela.


Lorsque nous utilisons click

$("button.alert").click(function() {
    alert(1);
});

avec ce qui précède, un séparé Le gestionnaire est créé pour chaque élément qui correspond au sélecteur. Cela signifie que

  1. de nombreux éléments correspondants créeraient de nombreux gestionnaires identiques et augmenteraient ainsi l'empreinte mémoire
  2. les éléments ajoutés dynamiquement n'auront pas le gestionnaire - par exemple, dans le code html ci-dessus, les boutons "Alerte !" nouvellement ajoutés ne fonctionneront pas à moins que vous ne rebasiez le gestionnaire.

Lorsque nous utilisons .on

$("div#container").on('click', 'button.alert', function() {
    alert(1);
});

avec ce qui précède, un solo handler pour tous les éléments qui correspondent à votre sélecteur, y compris ceux créés dynamiquement.


...une autre raison d'utiliser .on

Comme Adrien l'a commenté ci-dessous, une autre raison d'utiliser .on est un événement à espacement des noms.

Si vous ajoutez un gestionnaire avec .on("click", handler) vous l'enlevez normalement avec .off("click", handler) qui supprimera ce même gestionnaire. Évidemment, cela ne fonctionne que si vous avez une référence à la fonction, et si vous n'en avez pas ? Vous utilisez les espaces de noms :

$("#element").on("click.someNamespace", function() { console.log("anonymous!"); });

avec déverrouillage par

$("#element").off("click.someNamespace");

2 votes

Et pourquoi pas : $('button.alert').on('click', function() { alert(1) ; }) ; ?

12 votes

@andreister : corrigez-moi si je me trompe mais je crois qu'un autre avantage est l'utilisation des espaces de noms lors de l'utilisation de on('click' ...) voir stackoverflow.com/a/3973060/759452 ie. on('click.darkenallothersections' ...) et en même temps avoir on('click.displaynextstep' ...) alors je peux délier seulement celui que je choisis en utilisant .unbind('click.displaynextstep')

0 votes

Je ne pense pas qu'un gestionnaire distinct soit créé pour chaque élément qui correspond au sélecteur. Je pense qu'un gestionnaire est créé, mais que la surcharge provient de la liaison de ce gestionnaire à plusieurs éléments et du contrôle de tous ces éléments. En tout cas, je n'ai pas trouvé cela dans la documentation.

41voto

gilly3 Points 33285

Y a-t-il une différence entre les codes suivants ?

Non, il n'y a pas de différence fonctionnelle entre les deux échantillons de code dans votre question. .click(fn) est une "méthode raccourcie" pour .on("click", fn) . De la documentation pour .on() :

Il existe des méthodes abrégées pour certains événements tels que .click() qui peuvent être utilisées pour attacher ou déclencher des gestionnaires d'événements. Pour obtenir une liste complète des méthodes abrégées, consultez le site Web de la Commission européenne. catégorie d'événements .

Notez que .on() diffère de .click() en ce sens qu'il a la capacité de créer les gestionnaires d'événements délégués en passant un selector alors que .click() ne le fait pas. Lorsque .on() est appelé sans un selector il se comporte exactement comme le paramètre .click() . Si vous souhaitez une délégation d'événements, utilisez .on() .

5 votes

Qu'en est-il du problème de performance signalé par @andreister ?

0 votes

@rubo77 négligeable au mieux. Nous prenons des millisecondes à un chiffre.

1 votes

@RoryMcCrossan c'est un gros problème pour moi - Je cherche cela parce que j'ai jusqu'à 3000 questions sur une page qui ont besoin d'événements. Un millisec chacun fait que ma page prend 3 secondes de plus pour s'exécuter. Votre commentaire n'est pas utile pour les grandes listes.

25voto

Interrobang Points 7243

.on() est la méthode recommandée pour réaliser toutes vos liaisons d'événements à partir de la version 1.7 de jQuery. Elle reprend toutes les fonctionnalités des deux .bind() y .live() en une seule fonction qui change de comportement lorsque vous lui passez différents paramètres.

Tel que vous avez rédigé votre exemple, il n'y a aucune différence entre les deux. Les deux lient un gestionnaire à l'objet click événement de #whatever . on() offre une flexibilité supplémentaire en vous permettant de déléguer les événements déclenchés par les enfants de l'option #whatever à une seule fonction de gestion, si vous le souhaitez.

// Bind to all links inside #whatever, even new ones created later.
$('#whatever').on('click', 'a', function() { ... });

0 votes

"Lier à tous les liens à l'intérieur de #whatever, même les nouveaux créés plus tard." N'est-ce pas exactement ce que .live() fait ? De plus, cela semble être en contradiction avec les autres réponses qui disent qu'il n'a que les fonctionnalités suivantes .click() et ne s'applique donc pas aux événements futurs.

3 votes

@babonk - Cela ne contredit pas les autres réponses, car comme Interrobang l'a dit dans le premier paragraphe .on() peut faire ce que .click() fait et faire ce qui .bind() y .live() faire - cela dépend des paramètres avec lesquels vous l'appelez. (D'autres réponses l'ont également mentionné.) Notez cependant que "Lier à tous les liens à l'intérieur de #quelquechose" est no ce que .live() fait, c'est ce que .delegate() fait. .live() se lie à tout ce qui se trouve à l'intérieur document plutôt que de vous laisser spécifier le conteneur. Notez également .live() est déprécié à partir de jQuery 1.7.

0 votes

+1 pour les événements délégués : "En choisissant un élément dont la présence est garantie au moment où le gestionnaire d'événement délégué est attaché, vous pouvez utiliser les événements délégués pour éviter de devoir attacher et retirer fréquemment les gestionnaires d'événements." api.jquery.com/on

21voto

nnnnnn Points 70578

Comme mentionné dans les autres réponses :

$("#whatever").click(function(){ });
// is just a shortcut for
$("#whatever").on("click", function(){ })

Notant toutefois que .on() supporte plusieurs autres combinaisons de paramètres qui .click() ne le fait pas, ce qui lui permet de gérer la délégation d'événements (en remplaçant le .delegate() y .live() ).

(Et il existe évidemment d'autres méthodes de raccourci similaires pour "keyup", "focus", etc.)

La raison pour laquelle je poste une réponse supplémentaire est de mentionner ce qui se passe si vous appelez .click() sans paramètres :

$("#whatever").click();
// is a shortcut for
$("#whatever").trigger("click");

Notant que si vous utilisez .trigger() directement, vous pouvez également passer des paramètres supplémentaires ou un objet d'événement jQuery, ce que vous ne pouvez pas faire avec la fonction .click() .

Je voulais également mentionner que si vous regardez le code source de jQuery (dans jquery-1.7.1.js), vous verrez qu'en interne, la fonction .click() (ou .keyup() etc.) appellera en fait la fonction .on() o .trigger() . Cela signifie évidemment que vous pouvez être sûr qu'ils ont réellement le même résultat, mais cela signifie également que l'utilisation de l'option .click() a un tout petit peu plus de frais généraux - pas de quoi s'inquiéter ou même y penser dans la plupart des circonstances, mais théoriquement, cela pourrait avoir de l'importance dans des circonstances extraordinaires.

EDIT : Enfin, notez que .on() vous permet de lier plusieurs événements à la même fonction en une seule ligne, par exemple :

$("#whatever").on("click keypress focus", function(){});

0 votes

Les méthodes ne sont-elles pas toutes deux chargées en mémoire pour être utilisées ? Cela n'a donc pas d'importance ? Et pour la lisibilité, c'est peut-être plus pratique ?

0 votes

@VinceV. - Oui. Pour les gestionnaires d'événements non délégués "standard", les deux méthodes font la même chose et la différence de performance est négligeable, donc la méthode que vous utilisez est vraiment une question de préférence personnelle. (Je choisirais généralement .click() .)

9voto

dana Points 4890

Ils semblent être les mêmes... Documentation de la cliquez() fonction :

Cette méthode est un raccourci de .bind('click', handler)

Documentation de la on() fonction :

À partir de la version 1.7 de jQuery, la méthode .on() fournit toutes les fonctionnalités requises pour attacher des gestionnaires d'événements. pour attacher des gestionnaires d'événements. Pour obtenir de l'aide sur la conversion des anciennes méthodes d'événements de jQuery consultez .bind(), .delegate() et .live(). Pour supprimer les événements liés par la méthode .on(), consultez la méthode .off().

0 votes

Vos deux vues doivent être fusionnées. Click() est un raccourci pour .Bind() et .On() ... Selon JQUERY 1.7.0 + , il s'agit également d'un raccourci pour Trigger('click'). [ [api.jquery.com/click/]](http://api.jquery.com/click/])

0 votes

Il s'agit d'une explication assez directe tirée de la documentation, mais la réponse ci-dessous contient un bon exemple de la raison pour laquelle l'un est meilleur que l'autre dans .click vs .on

0 votes

@phatskat - Il se trouve que je suis d'accord avec vous :)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X