Dieser Artikel teilt Ihnen die Analyse der dynamischen Lademodule von Webpack Import () mit. Der Inhalt ist sehr gut. Ich hoffe, er kann allen helfen.
import
webpack implementiert die import()-Methode für dynamisches Laden gemäß der ES2015-Loader-Spezifikation.
Diese Funktion kann unseren Code bei Bedarf laden und verwendet einen Callback im Promise-Stil, um das geladene Paket abzurufen.
Alle Module, die im Code import() sind, werden in ein separates Paket gepackt und in dem Verzeichnis abgelegt, in dem der Block gespeichert ist. Wenn der Browser diese Codezeile ausführt, fordert er diese Ressource automatisch an und implementiert das asynchrone Laden.
Hier ist eine einfache Demo.
import('lodash').then(_ => {
// Do something with lodash (a.k.a '_')...
})Wie Sie sehen können, ist die Syntax von import() sehr einfach. Diese Funktion akzeptiert nur einen Parameter, nämlich die Adresse des Referenzpakets. Diese Adresse ist genau die gleiche wie die Adresse, die vom Import von es6 und der erforderlichen Syntax von CommonJS verwendet wird. Es kann ein nahtloser Wechsel erreicht werden [Schreiben Sie einen regulären Ausdruck, um Meizizi zu ersetzen].
Und es nutzt die Promise-Kapselung, was die Entwicklung sehr angenehm macht. [Das Einschließen einer asynchronen Funktion macht noch mehr Spaß]
Das Obige ist jedoch nur ein Schein.
Es ist nur ein Schein.
Während der Entwicklung ist ein Problem aufgetreten. Das Szenario sieht folgendermaßen aus: Ein Objekt speichert Routing-Informationen auf allen Ebenen und die entsprechenden Seitenkomponenten. Um die Größe des Hauptpakets zu reduzieren, möchten wir diese Seiten dynamisch laden.
Gleichzeitig wird React-Loadable verwendet, um das Lazy-Loading-Verpacken von Komponenten zu vereinfachen. Der Code wird unten angezeigt.
function lazyLoad(path) {
return Loadable({
loader: () => import(path),
loading: Spin,
});
}Dann habe ich voller Freude angefangen, lazyLoad('./pages/xxx') in den Code zu schreiben. Tatsächlich ist es gestorben. Der Browser sagte, dass es keine Fischbällchen oder dicken Nudeln gäbe, und ich wusste nicht, wo dieses dumme Modul war.
Also habe ich die offiziellen Unterlagen überprüft und einen gelben Balken gefunden.
emmm, es scheint, dass hier das Problem liegt.
Dieses Phänomen hängt tatsächlich stark mit der Implementierung von Webpack Import() zusammen. Da Webpack alle import()-Module separat packen muss, sammelt Webpack während der Projektverpackungsphase Abhängigkeiten.
Zu diesem Zeitpunkt findet Webpack alle import()-Aufrufe und verarbeitet die eingehenden Parameter in einem regelmäßigen Muster, wie zum Beispiel:
import('./app'+path+'/util') => /^\.\/app.*\/util$/
Mit anderen Worten, alle Variablen in den Importparametern werden verwendet durch [.*] ersetzt, und Webpack verwendet diese reguläre Regel, um alle Pakete zu finden, die die Bedingungen erfüllen, und sie als Pakete zu verpacken.
Wenn wir also eine Variable direkt übergeben, packt Webpack (das gesamte Computerpaket [kein Problem]) und denkt, dass Sie ihn veräppeln, und gibt eine WARNUNG aus: Critical dependency: the request of a dependency is an expression。
Die richtige Körperhaltung sollte also 尽可能静态化表达包所处的路径，最小化变量控制的区域 sein.
Wenn wir auf eine Reihe von Seitenkomponenten verweisen möchten, können wir import('./pages/'+ComponentName) verwenden, damit wir die Verweise kapseln und das Packen redundanter Inhalte vermeiden können.
Ein weiterer Punkt, der sich auf die Funktionskapselung auswirkt, ist das 相对路径 in import(), bei dem es sich um den relativen Pfad der Datei handelt, in der sich die Importanweisung befindet. Daher kann es bei der weiteren Kapselung des Imports zu Problemen kommen.
Da der Pfad in der Importanweisung nach der Kompilierung in einen relativen Pfad zum Webpack-Befehlsausführungsverzeichnis verarbeitet wird
Verwandte Empfehlungen:
Verwendung Tokens in der Vue-Aktualisierungsverarbeitung
Das obige ist der detaillierte Inhalt vonAnalyse dynamisch geladener Module durch Webpack import(). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
