AngularJS implementiert das bedarfsgesteuerte asynchrone Laden der Instanz code_AngularJS

AngularJS unterstützt Multi-View-Anwendungen durch Routing und kann die erforderlichen Ansichten basierend auf dem Routing dynamisch laden. Dies wird ausführlich in der AngularJS-Dokumentation beschrieben, und es gibt viele Tutorials im Internet, sodass es nicht erforderlich ist, es vorzustellen!

Da die Anzahl der Ansichten weiter zunimmt, wird es immer mehr JS-Dateien geben, und AngularJS muss standardmäßig alle JS auf einmal laden, was sehr unpraktisch ist. Daher wird die Nachfrage nach dem Laden von Modulen bei Bedarf steigen wird immer stärker. AngularJS implementiert jedoch kein On-Demand-Laden.

Ich bin an die asynchrone Lademethode von Seajs gewöhnt und dachte auch, dass Angular auch asynchrones Laden verwenden kann, aber die Tatsache ist nicht das, was ich will.

Angularjs verwendet wie requirejs eine Vorlademethode zum Organisieren von Modulen (was genau das Gegenteil des verzögerten Ladens von Seajs ist. Wenn eine einzelne Seitenanwendung immer mehr Module enthält, bedeutet dies, dass die Module vorhanden sein müssen). Vorgespannte werden ebenfalls zunehmen, was auch zeigen kann, dass Winkel besser für die Entwicklung leichter Anwendungen geeignet sind.

Offiziell beginnt

Ich habe Angular-UI-Router für das Routing verwendet und der Modullader ist requirejs

//路由
{
 state : 'login',
 templateUrl : 'login/login.html',
 controller : 'loginCtrl',
 resolve: {
  realCtrl : function ($q) {
   var def = $q.defer();
   require(['/features/login/login.js'], function (loginCtrl) {
    def.resolve(loginCtrl)
   });
   return def.promise;
  }
 }
},

// 获得$controllerProvider
app.config(function($controllerProvider) {
 app.registerController = $controllerProvider.register;
 // ...
})

// loginControler
app.registerController('loginCtrl', function ($scope) {
 // do something
});

So implementieren Sie das Laden bei Bedarf für Angular-Anwendungen

Wir haben ein mit Angular entwickeltes System, bei dem es sich um eine Einzelseitenanwendung handelt. Bei der Iteration des Systems ist der erste Bildschirmcode zu groß geworden, sodass das System transformiert werden muss.

Wir stehen hauptsächlich vor 3 Problemen

1. Ist ein Modullade-Framework erforderlich?

2. Wie registriere ich die asynchron geladenen Seitenkomponenten?

3. Wann sollten Seitenkomponenten geladen werden?

In Bezug auf die erste Frage: Da Angular selbst bereits über eine Reihe modularer Lösungen verfügt, ist die Einführung eines Modullade-Frameworks etwas überflüssig und der Gesamttransformationsumfang ist relativ groß, sodass dies nicht berücksichtigt wird.

Implementieren Sie also einfach eine Loadscript-Methode, um Komponenten zu laden. Dem seriellen und parallelen Laden mehrerer Dateien muss ein wenig Aufmerksamkeit geschenkt werden und ein wiederholtes Laden bei wiederholtem Seitenwechsel vermieden werden.

Die zweite Frage ist ärgerlicher. „Startup“ tritt nach dem Laden von Domcontent auf und alle in das Hauptmodul eingefügten Abhängigkeiten werden kompiliert.

Wenn Sie nach dem Start den Controller, deraktive und andere APIs verwenden möchten, wird direkt ein Fehler gemeldet

Derzeit gibt es nur eine Möglichkeit, dieses Problem zu lösen, nämlich den Anbieter des Hauptmoduls zu verwenden, um den Controller aktiv zu registrieren. Da der Anbieter jedoch nicht direkt verwendet werden kann, speichern wir ihn unter dem Hauptmodul.

Mit der gespeicherten Methode können asynchron geladene Seitenkomponenten registriert werden. Der Nachteil besteht darin, dass alle Unterseiten unter dem Hauptmodul hängen.
Bezüglich der dritten Frage: Da es sich bei der Betriebsplattform um eine Single-Page-Anwendung handelt, sollte die beste Ladezeit sein, wenn das Routing die Hash-Änderung überwacht. Da es sich bei unserem Routing jedoch um eine fest codierte statische Konfiguration handelt, haben wir keine gute Lösung gefunden am Anfang.
Später entdeckte ich eine solche API

Wahrscheinlich können wir vor $routeChangeSuccess etwas tun, und es ist am besten, die Ladezeit hier anzugeben
Die spezifische Implementierung ist wahrscheinlich so

Zu diesem Zeitpunkt wurde der Plan genehmigt. Welche Arbeiten bleiben noch übrig?
1. Organisieren Sie den Code, um ihn allgemeiner zu gestalten. Wenn wir in Zukunft neue Seiten entwickeln, müssen wir dies nur in die Routing-Konfiguration schreiben

2. Da es zuvor kein On-Demand-Laden gab, müssen wir bei der Entwicklung neuer Seiten darauf achten, dass Dienste gemeinsam genutzt werden Verschiedene Seiten werden am besten in den Komponenten unten platziert

3. Ändern Sie den Build und ersetzen Sie die js-Referenz in der Route durch den CDN-Pfad.