Quel est le problème avec la méthode jQuery live ?

Question

En live() a été dépréciée dans la version 1.7 de jQuery. La documentation de jQuery recommande maintenant

Utilice .on() pour attacher des gestionnaires d'événements. Les utilisateurs d'anciennes versions de jQuery doivent utiliser .delegate() de préférence à .live() .

Je comprends comment on y delegate fonctionnent, mais je ne comprends pas pourquoi ils sont meilleurs. live() est plus simple et plus facile à utiliser.

Y a-t-il une raison pour laquelle live a été déprécié ? En quoi les autres méthodes sont-elles meilleures ? Est-ce que quelque chose de mal va arriver si je continue à utiliser live ?

Answer 1

Voir certaines des explications ici :

http://www.ultimatewebtips.com/why-jquery-live-is-a-bad-option-to-use/ (Le site semble être en panne)

Citation :

1. Vous ne pouvez pas utiliser .live() pour les widgets réutilisables.

2. .stopPropagation() ne fonctionne pas avec le direct.

3. .live() est plus lent.

4. .live() n'est pas chaînable.

Plus d'informations sur beauté de .on() est qu'il rationalise très bien tous les événements : http://api.jquery.com/on/

Connaissez-vous le lien api et voyez comment .on() fonctionne :)

Citation :

La méthode .on() attache des gestionnaires d'événements à l'ensemble actuellement sélectionné d'éléments sélectionnés dans l'objet jQuery. Depuis la version 1.7 de jQuery, la méthode .on() fournit toutes les fonctionnalités nécessaires pour associer des gestionnaires d'événements. Pour aide à la conversion des anciennes méthodes d'événements de jQuery, consultez .bind(), .delegate() et .live(). Pour supprimer les événements liés à l'aide de la méthode .on(), consultez la rubrique .off(). Pour attacher un événement qui ne s'exécute qu'une seule fois et qui s'efface ensuite de lui-même, consultez .one(). puis s'efface, voir .one()

Answer 2

live() est inefficace pour deux raisons :

• Dans la construction $('selector').live() jQuery doit d'abord sélectionner tous les éléments. Cependant, lorsque l'on appelle live() il n'a besoin que du sélecteur de l'objet jQuery (stocké dans le fichier .selector ) et n'utilise en fait aucun des éléments sélectionnés. Par conséquent, il est quelque peu inutile de sélectionner d'abord tous les éléments correspondants, puis de ne pas les utiliser. on() y delegate() prennent le sélecteur de cible comme un paramètre ce qui signifie qu'aucun élément cible n'est sélectionné au préalable et que le test ne se produit que lorsque l'événement est déclenché.
• live() par défaut, est lié à la document donc tous les événements doivent remonter à travers le DOM entier. Vous puede le réduire en spécifiant un contexte avec $(selector, context).live() mais il est préférable d'utiliser on() o delegate() pour ça.

Lors de l'écriture d'un nouveau code, il est fortement recommandé d'utiliser la dernière et la plus grande on() au lieu de delegate() et la version dépréciée live() . Cependant, je ne pense pas que le soutien à live() ne sera pas abandonné de sitôt (si jamais il l'est), car de nombreux scripts en dépendent. De plus, il n'y a pas de réel inconvénient à utiliser la fonction live() sur on() comme dans la source jQuery elle-même. live() est défini comme suit :

live: function( types, data, fn ) {
    jQuery( this.context ).on( types, this.selector, data, fn );
    return this;
}

Answer 3

Il y a deux problèmes principaux avec le live méthode :

1. Il attache tous les gestionnaires d'événements au niveau du document, de sorte que tout événement qui surgit dans le document doit être mis en correspondance avec les types d'événements et les sélecteurs de tous les événements en direct. Si vous avez beaucoup d'événements, la page sera lente. Vous devez utiliser delegate o on pour limiter la portée de l'endroit où vous vérifiez les événements.

2. L'utilisation de la méthode n'est pas typique de la façon dont les sélecteurs sont utilisés avec les autres méthodes de la bibliothèque. Vous ne pouvez l'utiliser que sur les objets jQuery qui sont créés à l'aide d'un sélecteur. Le site delegate y on rend cela naturel puisque vous fournissez le sélecteur à la méthode.

Answer 4

Je suis presque sûr que c'est dû à la nature de l'opération. .live() . C'est pratique et tout, mais c'est une mauvaise pratique à utiliser car cela oblige votre navigateur à rechercher dans la plupart des cas plus d'événements que nécessaire.

Au lieu de rechercher par défaut un événement donné dans l'ensemble des documents, il est plus efficace de rechercher un conteneur spécifique.

live() En effet, il était pratique à utiliser, et la plupart des os uf n'ont jamais remarqué aucun défaut en l'utilisant. C'était en fait une version améliorée de bind() dans mes yeux.

Mais dans de nombreux cas, nous devons nous adapter et être plus clairs avec notre code sur ce qui doit être exécuté.

C'est comme si vous vous demandiez pourquoi vous devez importer des choses, et pourquoi tout n'est pas importé au départ.

Answer 5

live() attache les gestionnaires au document, ce qui revient essentiellement à intercepter todos des événements du type donné, en supportant le coût d'une recherche d'éléments correspondant au sélecteur. avec delegate() y on() il est recommandé de s'attacher plus près des cibles attendues (dans leur parent direct, si possible), réduisant ainsi le nombre d'événements traités et les recherches de cibles correspondantes.