Gibt es Fälle, in denen Sie das Frühbindungs- / Inline-Ereignisattribut in HTML / JavaScript verwenden müssen?

Question

In meiner Antwort auf die folgende SO-Frage: Was bedeutet Ereignisbindung? machte ich eine vorübergehende Bemerkung, dass dieDie Verwendung von Inline-JavaScript / Early-Binding zum Binden von JavaScript-Ereignissen war "oft falsch"

Zum Beispiel:

<input id="MyButton" type="button" value="clickme" onlick="Somefunction()" />

Ich habe mich für den "Late-Binding" -Ansatz ausgesprochen, bei dem im Markup kein JavaScript referenziert ist, was meines Erachtens als bewährte Methode gilt.Die Kommentatoren behaupteten jedoch, dass es Gelegenheiten gab, die ihre Verwendung erforderlich machten, und ich fragte mich, was dies sein könnte.

Ohne eine Diskussion über die relativen Vorzüge von beidem zu führen, kann sich jemand irgendwelche Umstände vorstellen, die vorschreiben, dass Sie das Attribut (z. B.) onclick über einen spätbindenden Ansatz verwenden.

Vielen Dank

Answer 1

Ich denke, viele Entwickler werden dies entweder aufgrund von Unwissenheit oder mangelndem Wissen tun (was natürlich häufig vorkommt), und die übrigen Entwickler werden es tun, weil es einfach bequemer ist, HTML-JS-Attribute zu verwenden als spätes Binden, wenn Sie wissen, dass bestimmte Objekte und Funktionen immer auf jeder Seite geladen werden und einfach "da" sind.

Ich denke, dies ist besonders wahr, wenn der HTML-Code aus einem AJAX-Rückruf stammt. Nehmen Sie ein Beispiel, in dem eine AJAX-Anfrage mit einer HTML-Antwort zurückkommt und dieser HTML-Code in die Seite eingefügt wird. Jetzt würde der naive Entwickler in diese Richtung denken:

• Ich habe keine Ahnung, welche Elemente in diesem Antwort-HTML enthalten sind, daher weiß ich nicht, welche späten Bindungen ich hinzufügen muss.
• Vielleicht muss ich sie alle hinzufügen, nur für den Fall! Oder schreiben Sie ein Parsing-Skript, das Elemente erkennt und an die von mir gefundenen bindet?
• Aber was ist, wenn ich mich an etwas binden muss, das es noch nicht gibt? Zeit, etwas langes Inline-JavaScript zu schreiben!

  All dies kann durch die Verwendung einer allgegenwärtigen Bindung beseitigt werden, die für alle aktuellen und zukünftigen Elemente auf der Seite gilt. In jQuery lautet das Äquivalent live() . Anstatt zu schreiben:

  $('.foo').click(function(){...});
  

  Sie könnten schreiben:

  $('.foo').live('click', function(){...});
  

  Jetzt führen alle Elemente mit dem Klassennamen 'foo' die Funktion aus, wenn Sie darauf klicken, einschließlich der Elemente, die derzeit nicht vorhanden sind . Sehr nützlich für dynamische AJAX-Schnittstellen.

  Das wissen Sie vielleicht schon, aber ich möchte nur darauf hinweisen, dass alles, was JS-Attribute können, reines JS besser kann, und ich würde diese bewährte Methode in Betracht ziehen.

Answer 2

Kommentatoren behaupteten, dass es Gelegenheiten gab, die seine Verwendung erforderlich machten

Ich bin wohl einer dieser Kommentatoren. Was ich tatsächlich sagte, war, dass Inline-Listener " unter bestimmten Umständen eine vernünftige Option sind ". Ich glaube nicht, dass es Fälle gibt, in denen dies "notwendig" ist (was ich in diesem Zusammenhang als erforderlich verstehe).

Das Hinzufügen von Inline-Listenern wendet einfach dieselbe Logik auf dem Server an, um Listener hinzuzufügen, die auf dem Client angewendet werden würde, und hat folgende Vorteile:

1. Markups können erstellt und zwischengespeichert oder als statische Seiten verwendet werden. Listener werden nicht von jedem Client immer wieder hinzugefügt, wenn Seiten heruntergeladen werden.
2. Probleme im Zusammenhang mit der Verzögerung zwischen dem verfügbaren Element und dem Hinzufügen des Listeners durch DOMReady- oder Onload-Funktionen oder "Bottom-Skripte" werden vollständig entfernt
3. Die Unklarheiten verschiedener "browserübergreifender" DOMReady-Funktionen mit Onload-Fallback werden entfernt. Es besteht keine Möglichkeit, dass solche Funktionen keine Listener hinzufügen, wenn sie nicht verwendet werden.

   Natürlich bedeutet dies nicht, dass alle Hörer inline hinzugefügt werden sollten und dass das dynamische Hinzufügen von Hörern Unsinn ist. Ich möchte nur darauf hinweisen, dass dies eine praktikable Methode ist, die bestimmte Probleme löst und in vielen Fällen eine absolut vernünftige Lösung darstellt Fälle.

   Wenn Sie der Meinung sind, dass eine "frühe Bindung" der Hörer gut ist, machen Sie es so früh wie möglich - setzen Sie sie inline. :-)

   PS. Ich glaube auch, dass ich die Verwendung von "Binding" in diesem Zusammenhang nicht mochte, da die Hörer nicht wirklich an Elemente gebunden sind. Sie sind einfach Funktionen, die aufgerufen werden, wenn ein Element ein verwandtes Ereignis empfängt. Die einzige Art der Bindung besteht darin, dass das Schlüsselwort this des Listeners so festgelegt werden kann, dass es auf das zugehörige Element verweist (was in allen Browsern für Inline-Listener konsistent ist, jedoch nicht unbedingt für die später hinzugefügten).

Answer 3

Gründe, warum onclick-Attribute schlecht sind:

onclick="foo()"

• Sie übergeben eine Code-Zeichenfolge, die zur Laufzeit abgerufen wird, wenn auf das Element geklickt wird.Dies ist ineffizient und nutzt die Schrecken des eval
• Sie sind gezwungen, die Funktion foo im globalen Bereich zu speichern, wodurch der globale Bereich mit Ihrer gesamten Ereignisbehandlungslogik verschmutzt wird.