Ich glaube, dass jeder Front-End-Ingenieur sein Lieblings-JavaScript-Framework hat, egal ob Emotion oder Glaube. 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, diese so klein wie möglich zu halten. Die Vorteile dieser Vorgehensweise liegen auf der Hand. Yui hat diese Funktionen jedoch in Ebenen und granulare Designs unterteilt und jede kleine Funktion bei Bedarf in eine Datei eingefügt Die in der Yui-Dokumentation angegebenen Demos verwenden diese Methode offensichtlich nicht so benutzerfreundlich wie JQuery, und es ist nicht dumm genug, sie zu verwenden. Um eine kleine Funktion zu implementieren, müssen sogar drei oder vier Js eingeführt werden Datei. 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 dynamisch geladenes 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 Nach dem Zwischenspeichern der dynamisch geladenen Datei kann eine echte HTTP-Anfrage erfolgen. Zweitens kann das dynamische Laden das Laden bei Bedarf realisieren und auf der JS-Datei basieren. Die Deduplizierung und Sortierung von Abhängigkeiten sowie das Laden von JS-Dateien mit handgeschriebenen Tags erfordern, dass Entwickler der Sortierung, Duplizierung usw. von Dateien besondere Aufmerksamkeit schenken. Drittens ist das dynamische Laden der Semantik des Seitencodes förderlich, sodass sich Entwickler nur um „Was“ kümmern müssen „Sie brauchen“ und nicht „wie Sie es bekommen“. Wenn Projekte immer aufgeblähter 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, wird bei der Wiederverwendung des Codes ebenfalls ein Problem darstellen. Ebenso müssen Ingenieure beim Debuggen zwei Fenster öffnen, um sich auf js bzw. html zu 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, einschließlich der typischen HTML-Struktur und der Startlogik js. Wenn er ihn wiederverwenden möchte, kann er einfach den gesamten Block kopieren.
<!–Ein logisches HTML-Codesegment–>
<script src="logicA.js" />
<Skript>
$.onDomReady(function(){
___LogicA.start();
});
</script>
…
<!–B logisches HTML-Codesegment–>
<script src="logicB.js" />
<Skript>
$.onDomReady(function(){
___LogicB.start();
});
</script>