Heim  >  Artikel  >  Web-Frontend  >  Drei Spezifikationen für Frontend-Modularität

Drei Spezifikationen für Frontend-Modularität

php中世界最好的语言
php中世界最好的语言Original
2018-03-19 16:44:001759Durchsuche

Dieses Mal werde ich Ihnen drei Spezifikationen für die Front-End-Modularisierung vorstellen und welche Vorsichtsmaßnahmen für Front-End-Modularisierungsspezifikationen gelten. Hier sind praktische Fälle, werfen wir einen Blick darauf .

Apropos Modularität: Es ist unbestreitbar, dass dies in der Front-End-Entwicklung zu einem Konsens geworden ist, und ich habe das Konzept der Modularität während der Entwicklung nach und nach akzeptiert und die Vorteile der modularen Entwicklung zutiefst erkannt. Warum sagst du das? Schauen wir uns einen einfachen Code an: (ohne Modularisierung)

 

Dies ist ein Phänomen, das oft vor der Verwendung der Modularisierung beobachtet werden kann: eine Menge js unten platzieren des Körpers, aber wussten Sie, dass es bei dieser Methode zwei große Probleme gibt:

1. Die Reihenfolge von root.js, tree.js und leaf.js von oben nach unten kann nicht durcheinander gebracht werden. , da das Blatt vom Baum und der Baum von der Wurzel abhängt, funktioniert es nicht, wenn die Reihenfolge geändert wird

 2. Wenn ich ein Neuling oder ein Nachfolger bin, weiß ich das, wenn ich leaf.js bekomme es hängt von tree.js ab, aber weiß ich, dass tree.js tatsächlich von root.js abhängt? Vielleicht muss sich root.js auf andere js verlassen, um ausgeführt zu werden?

 Zu diesem Zeitpunkt erschien die Modularisierung, genau um die unsicheren Abhängigkeiten zwischen js-Dateien zu speichern.

AMD-Spezifikation

Apropos diese Spezifikation, Leute, die sie verwenden Jetzt ist es sehr selten, dass Sie zuerst eine require.js in die HTML-Datei einfügen müssen, genau wie wenn Sie die Syntax von jQuery verwenden Zuerst muss jQuery.js auf die gleiche Weise geladen werden. Nach der Einführung dieses lästigen require.js wird eine Reihe von js-Dateien in drei Kategorien unterteilt:

Die erste Kategorie: einfach define(), weil In require. js, Verweise auf Ressourcen (d. h. als Parameter übergebene Ressourcen) müssen zuerst definiert werden, und dann ist dieser Typ für die reine Definition verantwortlich 🎜> Die zweite Kategorie: define(["andere definierte js"]) In dieser Kategorie wird auf andere definierte js verwiesen, und gleichzeitig definieren Sie selbst eine andere Sache, was eine doppelte Verantwortung darstellt 🎜>

Die dritte Kategorie: einfach require(["andere definierte js1", "andere definierte js2",... ]), in dieser Kategorie brauchen Sie nur Sie müssen sich auf das Zitieren von Ressourcen konzentrieren, und Sie können viele Ressourcen zitieren.

Wie wäre es damit? Finden Sie, dass es problematisch ist? Es ist notwendig, die Funktion

global zu definieren und festzulegen, worauf require.js verwiesen werden soll, also geben Sie es verärgert auf.  CMD-Spezifikation

Tatsächlich gibt es keinen wesentlichen Unterschied zwischen CMD- und AMD-Spezifikationen Der Unterschied besteht darin, dass sie den Ausführungszeitpunkt abhängiger Module unterschiedlich behandeln .

Obwohl beide Module asynchron laden, verlässt sich AMD auf Front-End und Js, um leicht zu erkennen, wer die abhängigen Module sind. Wenn Sie sich auf Js verlassen möchten, laden Sie diese zuerst. Sie müssen zuerst warten. Wir werden es besprechen, nachdem ich die Ressourcen geladen habe. CMD ist eine nahegelegene Abhängigkeit, und wenn ich dieses abhängige Modul verwenden muss, werde ich es laden und verwenden.

Wie ist das? Es ist, als würde ich mir heute Abend fünf Episoden „Romance of the Three Kingdoms“ ansehen. AMD öffnet zuerst fünf Fenster, nämlich die Episoden 1 bis 5, und puffert sie alle. Später schaue ich mir jede Episode an und warte, bis ich mit dem Ansehen der ersten Episode fertig bin Wenn Sie die zweite Folge sehen möchten, springen Sie einfach zur zweiten Folge.

CommonJS-Spezifikation

Im Allgemeinen gilt das Obige auch nicht Eine davon ist mein Ding. Die derzeit am häufigsten verwendete und von allen als gute modulare Spezifikation anerkannte Spezifikation ist CommonJS.

Um eine JS-Datei zu exportieren, verwenden Sie einfach module.export={xxx: den Inhalt, den Sie ausgeben möchten}, und was möchten Sie in einem anderen JS zitieren? Verweisen Sie einfach über var xxxx=require("xxxx") darauf. Dieses Ding lädt das Modul nicht asynchron, sondern synchron auf einmal. Ich persönlich finde, dass dieser Standard einigermaßen gut ist, und selbst die Verwendung von „666“ zur Beschreibung ist keineswegs falsch. Ich empfehle jedem, diesen Standard zu verwenden.

Ich glaube, dass Sie die Methode beherrschen, nachdem Sie den Fall in diesem Artikel gelesen haben. Weitere spannende Informationen finden Sie in anderen verwandten Artikeln auf der chinesischen PHP-Website!

Empfohlene Lektüre:

Vue.js-Formulareingabebindung

Welche Regeln gelten für die Konvertierung von JS-Typwerten in boolesche Typen

Das obige ist der detaillierte Inhalt vonDrei Spezifikationen für Frontend-Modularität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn