Was ist falsch an der jQuery Live-Methode?

Question

Die live()-Methode wurde in jQuery 1.7 nicht weiter unterstützt. Die jQuery-Dokumentation wird jetzt empfohlen

Verwenden Sie .on() zum Anhängen von Ereignishandlern. Benutzer älterer Versionen von jQuery sollten .delegate() anstelle von .live() verwenden.

Ich verstehe, wie on und delegate Arbeit, aber ich verstehe nicht, warum sie besser sind. live() ist einfacher und einfacher zu bedienen.

Gibt es einen Grund, warum live veraltet war? Wie sind die anderen Methoden besser? Wird etwas schlimmes passieren, wenn ich weiterhin live verwende?

Answer 1

hier einige der Erklärungen Siehe:

http://www.ultimatewebtips.com/why-jquery-live-is-a-bad-option-to-use/ (Website erscheint unten zu sein)

Zitat:

1. Sie können nicht .live() verwenden für wiederverwendbare Widgets.

2. .stopPropagation() funktioniert nicht mit Live.

3. .live() ist langsamer.

4. .live() ist nicht verkettbar.

Weitere Schönheit .on() ist, dass es alle Ereignisse ganz gut rationalisiert: http://api.jquery.com/on/

D'uh Sie über die api Link kennen und sehen, wie .on() Werke :)

Zitat:

Die .on() -Methode hängt Ereignishandler an s an die aktuell ausgewählte Menge von Elementen im jQuery-Objekt. Ab jQuery 1.7 bietet die .on() -Methode alle Funktionen, die zum Anhängen von Ereignishandlern erforderlich sind. Informationen zur Hilfe bei der Konvertierung von älteren jQuery-Ereignismethoden finden Sie unter .bind(), .delegate() und .live(). Informationen zum Entfernen von Ereignissen, die mit .on() verbunden sind, finden Sie unter .off(). Um ein Ereignis zu befestigen, die nur einmal ausgeführt wird und entfernt dann selbst siehe .one()

Answer 2

Ich bin ziemlich sicher, dass dies aufgrund der Natur .live() ist. Es ist praktisch und alles, aber es ist eine schlechte Übung zu verwenden, da es Ihren Browser zwingt, in den meisten Fällen nach mehr Ereignissen zu suchen, als erforderlich.

Anstatt standardmäßig die gesamten Dokumente nach einem bestimmten Ereignis zu durchsuchen, ist es effizienter, einen bestimmten Container zu durchsuchen.

live() war in der Tat bequem zu bedienen, und die meisten haben nie irgendwelche Mängel bei der Verwendung bemerkt. Es war grundlegend eine verbesserte bind() in meinen Augen.

Aber in vielen Zeiten müssen wir anpassen und klarer zu unserem Code auf, was ausgeführt werden muss.

Es ist, als ob Sie sich fragen, warum Sie Dinge importieren müssen, und warum nicht alles zu Beginn importiert wird.

Answer 3

live() legt die Handler auf das Dokument, das im Grunde führt das Abfangen alle Ereignisse der gegebenen Art, entstehen die Kosten Suchen nach Elementen, die mit dem Selektor übereinstimmen. Mit delegate() und on() empfiehlt es sich, die erwarteten Ziele (in ihren direkten Eltern, wenn möglich) näher bei sich zu bringen, um die Anzahl der behandelten Ereignisse zu verringern bzw. nach übereinstimmenden Zielen zu suchen.

Answer 4

Hier ist eine detaillierte article by Paul Irish über Live() Leistung und Grenzen.

Wenn Sie weiterhin live verwenden, konnte Ihr Code bald oder später nicht mehr funktionieren, wenn Sie die jQuery-Bibliothek in Ihren Projekten aktualisieren.

Answer 5

$('some selector').live(' ... ', handler)

ist die gleiche wie

$(document).on(' ... ', 'some selector', handler)

Also, wenn Sie verwenden live Sie tatsächlich alle Handler an der Wurzel Ihres DOM-Baum zuweisen. Dafür gibt es zwei Nachteile:

1. Das Hinzufügen von Handlern zu DOM root erhöht den Pfad, den das Ereignis beim Hochfahren durchlaufen muss. Das würde die Leistung schlecht beeinflussen.
2. Es besteht ein erhöhtes Risiko, dass ein anderer Handler mit return false am Ende verhindert, dass live Handler ausgelöst wird.

Answer 6

live() ist aus zwei Gründen ineffizient:

• In dem Konstrukt $('selector').live(), jQuery hat zunächst alle Elemente auszuwählen. Beim Aufruf von live() benötigt es jedoch nur den Selektor des jQuery-Objekts (gespeichert in .selector) und verwendet keines der ausgewählten Elemente. Daher ist es eine Verschwendung, zuerst alle übereinstimmenden Elemente auszuwählen und sie dann nicht zu verwenden.on() und delegate() nehmen Sie den Zielselektor als Parameter was bedeutet, dass keine Zielelemente im Voraus ausgewählt werden und der Test nur auftritt, wenn das Ereignis ausgelöst wird.
• live() ist standardmäßig auf der Ebene document gebunden, so dass alle Ereignisse durch das gesamte DOM aufsteigen müssen. Sie können Sie eingrenzen, indem Sie einen Kontext mit $(selector, context).live() angeben, aber es ist besser, on() oder delegate() dafür zu verwenden.

Wenn neuen Code zu schreiben, wird dringend die neueste und größten on() statt delegate() und die veralteten live() zu verwenden empfohlen. Ich glaube jedoch nicht, dass die Unterstützung für live() bald (wenn überhaupt) fallen wird, da sich so viele Skripte darauf verlassen. Auch gibt es keinen wirklichen Nachteil live() über on() verwenden, wie sie in der jQuery Quelle selbst live() ist definiert als:

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

Answer 7

Es gibt zwei Hauptprobleme mit der live Methode:

1. Er misst alle Event-Handler auf Dokumentebene, so dass jedes Ereignis, das sich im Dokument ansammelt, mit den Ereignistypen und Selektoren für alle Live-Ereignisse verglichen werden muss. Wenn Sie viele Ereignisse haben, wird die Seite träge sein. Sie sollten delegate oder on verwenden, um den Bereich zu begrenzen, in dem Sie die Ereignisse überprüfen.

2. Die Verwendung der Methode ist nicht typisch für die Verwendung von Selektoren mit anderen Methoden in der Bibliothek. Sie können sie nur für jQuery-Objekte verwenden, die mit einem Selektor erstellt wurden. Die Methoden delegate und on machen dies natürlich, wenn Sie den Selektor an die Methode übergeben.