Benannte Element-IDs können als JavaScript-Globals referenziert werden

var el = querySelector("#cool");

  
    window.foo = "bar";
  


  
I won't override window.foo
  
    console.log(window.foo); // Prints "bar"
  

I will be overridden :(

  window.foo = "bar";
  console.log(window.foo); // Prints "bar"

, die andernfalls einen Konflikt erzeugen würde, indem die ungültig gemacht wird alert API. Diese Sicherungstechnik ist möglicherweise der Grund, warum Sie – wenn Sie wie ich sind – zum ersten Mal davon erfahren.

Der Fall gegen Named Globals

Ich habe vorhin gesagt, dass die Verwendung von global benannten Elementen als Referenzen vielleicht nicht die beste Idee ist. Dafür gibt es viele Gründe, die TJ VanToll hat in seinem Blog gut darüber berichtet und ich fasse hier zusammen:

• Wenn sich das DOM ändert, ändert sich auch die Referenz. Das macht einige wirklich „spröde“ (der Begriff der Spezifikation dafür) Code, bei dem die Trennung zwischen HTML und JavaScript zu weit gehen könnte.
• Versehentliche Referenzen sind viel zu einfach. Ein einfacher Tippfehler kann sehr wohl dazu führen, dass auf einen benannten globalen Wert verwiesen wird, und Ihnen unerwartete Ergebnisse liefern.
• Es ist in Browsern unterschiedlich implementiert. Zum Beispiel sollten wir in der Lage sein, mit an auf einen Anker zuzugreifen id - z.B — aber einige Browser (nämlich Safari und Firefox) geben a zurück ReferenceError in der Konsole.
• Es gibt möglicherweise nicht das zurück, was Sie denken. Gemäß der Spezifikation, wenn es mehrere Instanzen desselben benannten Elements im DOM gibt – sagen wir, zwei Instanzen von

  — Der Browser sollte eine zurückgeben HTMLCollection mit einem Array der Instanzen. Firefox gibt jedoch nur die erste Instanz zurück. Dann wieder, die spezifikation sagt wir sollten eine Instanz von an verwenden id sowieso im Baum eines Elements. Dies wird jedoch nicht verhindern, dass eine Seite funktioniert oder ähnliches.

• Vielleicht gibt es Leistungskosten? Ich meine, der Browser muss diese Referenzliste erstellen und pflegen. Ein paar Leute haben Tests durchgeführt in diesem StackOverflow-Thread, wo Named Globals tatsächlich waren leistungsfähiger in einem Test und weniger leistungsfähig in einem neueren Test.

Weitere Überlegungen

Nehmen wir an, wir werfen die Kritik gegen die Verwendung von Named Globals weg und verwenden sie trotzdem. Es ist alles gut. Aber es gibt einige Dinge, die Sie vielleicht berücksichtigen sollten, wenn Sie dies tun.

Füllmaterialien

So grenzwertig es auch klingen mag, diese Arten von globalen Prüfungen sind eine typische Setup-Anforderung für Polyfills. Sehen Sie sich das folgende Beispiel an, in dem wir ein Cookie mit dem new CookieStore API, polyfilling es auf Browsern, die es noch nicht unterstützen:

  
  
    // Polyfill the CookieStore API if not yet implemented.
    // https://developer.mozilla.org/en-US/docs/Web/API/CookieStore
    if (!window.cookieStore) {
      window.cookieStore = myCookieStorePolyfill;
    }
    cookieStore.set("foo", "bar");
  

Dieser Code funktioniert in Chrome einwandfrei, löst aber in Safari den folgenden Fehler aus:

TypeError: cookieStore.set is not a function

Safari hat keine Unterstützung für die CookieStore API zum Zeitpunkt dieses Schreibens. Infolgedessen wird die Füllwatte nicht aufgetragen, da die img Element-ID erstellt eine globale Variable, die mit der kollidiert cookieStore global.

JavaScript-API-Updates

Wir können die Situation umkehren und ein weiteres Problem finden, bei dem Aktualisierungen der JavaScript-Engine des Browsers die globalen Referenzen eines benannten Elements beschädigen können.

Beispielsweise:

  
  
    window.BarcodeDetector.focus();
  

Dieses Skript greift auf einen Verweis auf das Eingabeelement zu und ruft auf focus() darauf. Es funktioniert korrekt. Trotzdem wissen wir nicht wie lange es wird weiter funktionieren.

Sie sehen, die globale Variable, die wir verwenden, um auf das Eingabeelement zu verweisen, wird nicht mehr funktionieren, sobald Browser beginnen, die zu unterstützen BarcodeDetector API. An diesem Punkt ist die window.BarcodeDetector global ist kein Verweis mehr auf das Eingabeelement und .focus() wirft ein „window.BarcodeDetector.focus ist keine Funktion“ Fehler.

Bonus: Nicht alle benannten Elemente erzeugen globale Referenzen

Willst du etwas Lustiges hören? Um das Ganze noch schlimmer zu machen, sind benannte Elemente nur dann als globale Variablen zugänglich, wenn die Namen nur Buchstaben enthalten. Browser erstellen keine globale Referenz für ein Element mit einer ID, die Sonderzeichen und Zahlen enthält, wie z hello-world und item1.

Zusammenfassung

Fassen wir zusammen, wie wir hierher gekommen sind:

• Alle gängigen Browser erstellen automatisch globale Verweise auf jedes DOM-Element mit einem id (oder in manchen Fällen a name Attribut).
• Der Zugriff auf diese Elemente über ihre globalen Referenzen ist unzuverlässig und potenziell gefährlich. Verwenden querySelector or getElementById stattdessen.
• Da globale Verweise automatisch generiert werden, können sie einige Nebenwirkungen auf Ihren Code haben. Das ist ein guter Grund, die Verwendung von zu vermeiden id Attribut, es sei denn, Sie brauchen es wirklich.

Letztendlich ist es wahrscheinlich eine gute Idee, benannte Globals in JavaScript zu vermeiden. Ich habe die Spezifikation zuvor zitiert, wie sie zu „brüchigem“ Code führt, aber hier ist der vollständige Text, um den Punkt zu verdeutlichen:

Wenn Sie sich darauf verlassen, führt dies in der Regel zu sprödem Code. Welche IDs letztendlich dieser API zugeordnet werden, kann im Laufe der Zeit variieren, wenn beispielsweise neue Funktionen zur Webplattform hinzugefügt werden. Verwenden Sie stattdessen document.getElementById() or document.querySelector().

Ich denke, die Tatsache, dass die HTML-Spezifikation selbst empfiehlt, sich von dieser Funktion fernzuhalten, spricht für sich.