Ich glaube, dass jeder Front-End-Ingenieur sein Lieblings-JavaScript-Framework hat, egal ob es sich um Emotion oder Glaube handelt. Das JavaScript-Framework bringt nicht nur eine bequeme Entwicklung, sondern auch eine reine logische Schönheit, sei es die anmutige Einfachheit von JQuery oder Yuis Magie Sandbox, sie alle geben uns grenzenlose Fantasie. Das js-Framework ist jedoch zwangsläufig nicht in der Lage, eine umfassende Perfektion zu erreichen. Beispielsweise vermitteln die Zugeständnisse von jquery in OO und die Opfer von yui bei der Leistung den Menschen eine Art unvollkommene Schönheit und einen idealen Realismus. Werfen wir heute einen Blick auf diese Opfer und Zugeständnisse, die yui3 beim Framework-Design gemacht hat, damit wir das Gesamtbild von yui3 besser verstehen und seine Vorteile maximieren können.
1. Ein Schritt oder Granulierung der Samen
Das sogenannte One-Step-Seeding bedeutet, dass Sie nur ein Skript-Tag einer Seed-Datei auf der Seite einführen müssen, z. B. „prototyp“ und „jquery“, und nur „prototyp.js“ oder „jquery.js“ einführen müssen. Sie kapseln DOM-Operationen und Speichern Sie Ereignisse usw. in einer Datei und versuchen Sie, sie so klein wie möglich zu halten. Die Vorteile dieser Vorgehensweise liegen auf der Hand. Yui hat diese Funktionen jedoch in hierarchische und granulare Designs unterteilt und dabei „Kern“, „Werkzeuge“ und „Komponenten“ konzeptionell abstrahiert. Jede kleine Funktion wird in einer Datei abgelegt und muss bei Bedarf einzeln referenziert werden Dieses in der Yui-Dokumentation angegebene Design ist offensichtlich nicht so benutzerfreundlich wie JQuery und nicht dumm genug, um eine kleine Funktion zu implementieren. Dafür gibt es zwei Gründe: Erstens ist Yui zu groß und es ist etwas unzuverlässig, alle Funktionen in einer Datei zusammenzufassen. Zweitens ebnet es den Weg für sein dynamisches Lade-Framework-Design.
2. Manuelle Einführung oder dynamisches Laden
Die traditionelle Methode zum Schreiben von js in die Seite besteht darin, die js-Datei direkt als Skript-Tag-Pfad in die Seite zu schreiben. Sie können die Seite auch auf diese Weise mit yui einführen, yui empfiehlt jedoch die Verwendung des Loaders zum dynamischen Laden. Der Ursprung dynamisch geladener Skripte ist derzeit sehr kompliziert. Erstens belegen die handgeschriebenen js-Tags auf der Seite ohnehin eine 304-Anfrage Um eine echte HTTP-Anfrage nach dem Zwischenspeichern zu initiieren, kann das dynamische Laden das Laden bei Bedarf realisieren und die Abhängigkeiten zwischen js-Dateien deduplizieren und sortieren. Das Laden von js-Dateien mit handgeschriebenen Tags erfordert besondere Aufmerksamkeit Das Sortieren, Duplizieren usw. von Dateien ist drittens förderlich für die Semantik des Seitencodes, sodass sich Entwickler nur um das kümmern können, „was benötigt wird“, ohne sich Gedanken darüber machen zu müssen, „wie man es erhält“. Wenn Projekte immer umfangreicher werden und die Wartungskosten immer höher werden, werden diese kleinen und mittleren Techniken von großem Nutzen sein.
3. Einzelner Eingang oder Sandbox für logischen Start
Wenn wir eine js-Logik auf einer Seite starten, fügen wir sie normalerweise in eine Methode wie onDomReady ein. Was ist, wenn die Seite mehrere Logiken enthält? Beispielsweise implementiert a die Logik A und der Seitencode sieht so aus
<script src="logicA.js" />
<Skript>
$.onDomReady(function(){
___LogicA.start();
});
</script>
Dieser Code wird normalerweise am Ende der Seite geschrieben. Zu diesem Zeitpunkt muss b die Logik B zur Seite hinzufügen end, und ändern Sie es dann so, dass es wie folgt aussieht:
<script src="logicA.js" />
<script src="logicB.js" />
<Skript>
$.onDomReady(function(){
___LogicA.start();
___LogicB.start();
});
</script>
Ebenso ist der HTML-Code, der die B-Logik begleitet, irgendwo auf der Seite vergraben. Es scheint, dass die JS-Logik und der zugehörige HTML-Code so getrennt sind, dass beim Löschen der Funktion oft der HTML-Code gelöscht wird, der JS jedoch vergessen wird . oder das Löschen von js und das Vergessen, HTML zu löschen, führt ebenfalls zu Problemen bei der Wiederverwendung von Code. Ebenso müssen Ingenieure beim Debuggen zwei Fenster öffnen und sich auf js bzw. html konzentrieren, selbst wenn sich die beiden Codeteile in derselben Datei befinden. In diesem Fall ist es besser, den Code so zu schreiben:
Diese Codierungsmethode ist genau das, was Yui befürwortet, nämlich die sogenannte Sandbox. Jede Logik ist in einer Sandbox enthalten und jede macht ihre eigene Sache, ohne sich gegenseitig zu stören. Wenn ein Dritter den Code durchsucht, erkennt er sofort, dass es sich um einen unabhängigen Funktionsblock handelt, der eine typische HTML-Struktur und Startlogik enthält. Wenn er ihn wiederverwenden möchte, kann er einfach den gesamten Block kopieren.
<!–Ein logisches HTML-Code-Snippet–>
<script src="logicA.js" />
<Skript>
$.onDomReady(function(){
___LogicA.start();
});
</script>
…
<!–B logisches HTML-Code-Snippet–>
<script src="logicB.js" />
<Skript>
$.onDomReady(function(){
___LogicB.start();
});
</script>