Eine hohe Performance und die Sicherheit von Webapplikationen ist für jeden Entwickler ein Dauerthema. Unter JavaScript ist es möglich, für eine hohe Performance nur die gerade benötigten oder wegen der Sicherheit nur die erlaubten Teile der Applikation zu laden.
Diese Artikelserie wird zeigen, wie das Angular-Framework dieses Feature auf einfach Weise zur Verfügung stellt. Ich werde die zwei unterschiedlichen Wege erläutern, mit denen im Fall einer Nutzeraktion in Angular eine Modulfunktionalität asynchron nachgeladen werden kann. Für beide Fälle werden die damit verbundenen Vor- und Nachteile besprochen.
Artikelserie
Die Modularisierung mobiler Anwendungen spielt in vielen Angular-Projekten eine zunehmend größere Rolle. Die Erfahrung zeigt, dass eine gut durchdachte Kapselung der Modulfunktionalität der Anwendung vorteilhaft ist. Die Hauptanwendung bleibt schlank, während weitere Bestandteile der Anwendung optional angeboten und dynamisch bereitgestellt werden können. Dieses Vorgehen ermöglicht sowohl die Optimierung der initialen Ladezeit der Anwendung, als auch die Freigabe oder Anzeige einzelner Module in Abhängigkeit von den jeweiligen Rechten des Nutzers.
Die am häufigsten verbreiteten Anwendungsfälle für das dynamische Nachladen von Funktionalität zur Laufzeit sind die Bereitstellung dieser auf Grundlage von Nutzerrechten oder die allgemeine Verwendungshäufigkeit von Modulen.
Ein Modul kapselt eine bestimmte, definierte Funktionalität in der Form, dass sie unabhängig voneinander und austauschbar umgesetzt ist. Das Modul enthält dabei alles was für die Ausführung der Logik notwendig ist. In Angular unterscheiden wir zwei Arten von Modulen:
Root Module
, das meistens App Modul genannt wird. Es wird als erstes Modul einer Anwendung geladen und initialisiert.Feature Module
, die Components, Services und andere notwendige Dateien referenzieren, die für ein bestimmtes Feature relevant sind.Die im Schaubild gezeigte Beispielanwendung besteht aus drei Modulen: Dem Core
-Modul (Home
), einem Reporting
- und einem Settings
-Modul. Der Quellcode der Demoanwendungen ist hier zu finden: https://github.com/thinktecture/angular-lazy-loading-modules-different-server
Die drei eingebundenen Module spiegeln die zu Beginn des Artikels angesprochenen Anwendungsszenarien wider:
Core
-Modul ist ein Feature Module, das im Root Module importiert wird. Es ist nach dem Start der Anwendung initialisiert und direkt verfügbar.Reporting
-Modul ist ein Feature Module in einem Web Component Bundle. Es steht nur Nutzern mit entsprechenden Rechten zur Verfügung und wird erst auf Bedarf (Lazy Module) und auf Basis einer Prüfung dieser Rechte über eine eigene Lösung geladen.Settings
-Modul ist ein Feature Module, das erst bei Bedarf (als Lazy Module) durch den Router geladen wird.Die Information über Nutzerrechte wird allgemein nicht beim Client verwaltet. Ein Server mit einer HTTP API (siehe Demo Repository) stellt für das aktuelle Beispiel folgende weitere Informationen bereit:
Neben den Meta-Informationen stellt die API auch die einzelnen Dateien eines Module-Bundles über die einzelnen Modulendpunkte bereit
http://.../module/reporting/main.js
oder http://.../module/reporting/assets/logo.svg
/modules
liefert alle Module /module/reporting/*
liefert modulbezogene Files[
{
"url": "/dashboard",
"name": "Dashboard"
},
{
"url": "/module/reporting",
"name": "Reporting",
"id": "reporting",
"preload": true,
"selector": "labs-reporting",
"files": [
"styles-es2015.js?v=1572447551716",
"runtime-es2015.js?v=1572447551716",
"main-es2015.js?v=1572447551716"
]
},
{
"url": "/settings",
"name": "Settings"
}
]
Im zweiten Teil der Artikelserie wird das Nachladen von Angular-Modulen mit Angular Router gezeigt.