Allgemeine Gründe, sich nicht mit dem Prototyp von Documents und Elements zu befassen

Question

Gibt es allgemeine Gründe, sich nicht mit dem Prototyp von Documents und Elements zu befassen?

Ich mag mein eigenes kleines Framework zu erstellen, weil mein aktuelles Projekt nicht die Masse der Features der vorhandenen Frameworks benötigt.

Ich brauche keine Browser zu unterstützen, die Element/Document-Konstruktor nicht unterstützen und auch keine Skripte ausführen, die nicht unter meiner Kontrolle stehen.

Also würden Sie empfehlen, den Prototyp zu erweitern, oder sollte ich den üblichen Weg gehen und eigene Objekte aus Element/Document erstellen?

Answer 1

Haben Sie vor, Standard-DOM-Elemente zu erweitern? Wenn ja, bitte nicht. Juriy Zaytsev (aka Kangax) beschreibt deutlich, warum nicht in What’s wrong with extending the DOM.

Answer 2

Ja, leider. Es wäre schön, Funktionalität hinzufügen zu können, indem man an den DOM-Prototypen fummelt, aber in der Praxis ist es angesichts der heutigen Technologie einfach nicht zuverlässig.

Document, Element und andere usw. können "Host-Objekte" vom Browser implementiert werden, ohne die Möglichkeit, mit ihren Prototypen herumzuhantieren. Host-Objekte können möglicherweise viele andere seltsame Verhaltensweisen aufweisen, die ein natives JavaScript-Objekt nicht hätte. DOM-Knoten sind Hostobjekte in IE6-7 und vielen älteren Nischen- und mobilen Browsern.

Auch wenn sie als native-JavaScript-Objekte implementiert sind, gibt es (noch) keinen Standard, in dem die Konstruktorfunktion für sie zu finden ist, so dass Sie in der .prototype fischen gehen können. Document, Element usw. sind nur W3-DOM-Schnittstellennamen, sie sagen nichts darüber aus, wie die Implementierungsobjekte zu finden sind.

Es kommt vor, dass moderne Browser (IE8 nativer Modus und aktuelle Versionen von Firefox, Opera und WebKit) Konstruktorfunktionen verfügbar machen, so dass Sie Methoden zu Document oder HTMLElement hinzufügen können. Aber selbst dann gibt es Unterschiede zwischen den freigelegten Objekten, da nicht jeder Browser die DOM-Schnittstellen mit Implementierungen unter den gleichen Namen versorgt. (Die Subschnittstellen/Implementierungen von NodeList sind besonders problematisch.)

Sie können sehen, wie DOM-Prototyping in der Praxis gearbeitet hat, indem Sie sich das Prototype.js-Framework angesehen haben. Wenn es funktioniert, ist es super glatt. Aber weil Sie nicht überall prototypieren können, haben Sie am Ende einige extrem hässliche Sachen, wo das Framework mit Orten umgehen muss. Prototyping funktioniert nicht, indem Methoden in jede Instanz eines Nodes kopiert werden. Und dann hast du die Situation, in der dein Code vergessen könnte, dass er diese "Augmentation" erzwingt und es funktioniert oder nicht funktioniert, abhängig davon, ob eine andere Funktion den selben Knoten vorher vergrößert hat. Dies führt zu wirklich schrecklichen browserspezifischen, interaktionsreihenspezifischen, race-conditions-anfälligem Debugging-Schmerz.

Wenn Sie Ihre Prototyping-Arbeit auf einige gut unterstützte Schnittstellen beschränken und alle außer den neuesten Browsern aufgeben können, werden Sie wahrscheinlich damit durchkommen.