Angular-Architektur

Wie eine Angular-Anwendung gegliedert wird: ein kleiner, sofort geladener Kern (Core), wiederverwendbare Bausteine (Shared) und voneinander isolierte, bei Bedarf nachgeladene Features. Die Isolation macht die App schneller beim Start und sicherer bei Änderungen.

Code-Beispiele aus Quelle - Angular Mastery Workshop (Folie 167–169, 344–345), von den Folienbildern abgeschrieben. Routing-Code steht bei Angular-Routing.

Grobaufbau

Laut Quelle - Angular Mastery Workshop (Folie 148, 356–358):

Regeln für Features

• Ein Feature darf Core nutzen, nie umgekehrt.
• Ein Feature importiert nie etwas aus einem benachbarten Feature. Braucht man etwas in zwei Features, gehört es eine Ebene höher (z.B. nach Core).
• Die Isolation garantiert: Wer ein Feature ändert, kann kein anderes brechen.
• Lazy Loading verkleinert das Startpaket. Beim Aufruf von /customers lädt der Browser erst dann customer-module.js nach (Folie 305–308).

Lazy Loading erzwingt diese Isolation sogar technisch: Ein Service, der nur im lazy geladenen Modul angemeldet ist, existiert in anderen Features gar nicht und führt dort sofort zu einem Fehler. Laut Kurs ist das gut, weil der Fehler früh auftritt (Folie 180, 305, siehe Dependency Injection).

NgModules

Im Kurs ist das NgModule die Einheit der Gliederung (Folie 166–170): Eine Komponente muss in einem Modul deklariert sein, um in Templates benutzt zu werden. Andere Module können sie nur nutzen, wenn sie exportiert wird. Nicht exportierte Komponenten bleiben privat.

Ein Feature-Modul deklariert seine Komponenten, importiert das SharedModule und meldet einen Service an (Folie 167–168, 171):

import { NgModule } from '@angular/core';

@NgModule({
    imports: [SharedModule],                  // dessen exportierte Bausteine nutzen, z.B. <spinner>
    declarations: [UserComponent, UserListComponent, UserItemComponent],
    providers: [UserService],                 // bei lazy Loading nur in diesem Modul sichtbar
    exports: [],
})
export class UserModule {}

Nach der Deklaration können sich die Komponenten des Moduls gegenseitig verwenden, z.B. <user-list><user-item></user-item></user-list>. Exportiert das SharedModule eine SpinnerComponent, geht auch <spinner></spinner>. Tipp: Die meisten Services besser mit providedIn: 'root' anmelden, damit beim Lazy Loading keine zweite Instanz entsteht (siehe Dependency Injection).

Das SharedModule implementiert, deklariert und exportiert wiederverwendbare Bausteine. Fremde Module wie MatButtonModule importiert und exportiert es weiter, damit alle Module, die SharedModule importieren, sie nutzen können (Folie 169):

import { NgModule } from '@angular/core';

import { MatButtonModule } from '@angular/material';

@NgModule({
    imports: [MatButtonModule],
    declarations: [SpinnerComponent, LicencePlatePipe, DraggableDirective],
    providers: [],
    exports: [MatButtonModule, SpinnerComponent, LicencePlatePipe, DraggableDirective]
})
export class SharedModule {}

(Auf der Folie steht in exports ein doppeltes Komma.)

Umgebungen und Auslieferung

• Einstellungen pro Umgebung liegen in environment.ts (Standard, Entwicklung) und environment.prod.ts (mit --prod). Beide exportieren dasselbe Objekt mit anderen Werten, z.B. den API-Endpunkt (Folie 344):

// environment.ts
export const environment = {
  production: false,
  API_URL: 'http://localhost:4300/api'
};

// environment.prod.ts
export const environment = {
  production: true,
  API_URL: 'https://my-org.com//api',     // doppelter Schrägstrich so auf der Folie
};

• Das funktioniert, weil die Produktionskonfiguration in angular.json die Datei beim Bauen austauscht. Eigene Konfigurationen lassen sich genauso anlegen und mit --configuration myconfiguration aktivieren (Folie 345):

{
    "build": {
        "configurations": {
            "production": {
                "fileReplacements": [
                    {
                        "replace": "projects/customer-admin-app/src/environments/environment.ts",
                        "with": "projects/customer-admin-app/src/environments/environment.prod.ts"
                    }
                ]
            }
        }
    }
}

• Problem: So braucht jede Stufe (Test, Abnahme, Produktion) einen eigenen Build. Besser ist „einmal bauen, überall ausliefern“: dasselbe Paket durch alle Stufen schieben und die Konfiguration erst bei der Auslieferung einsetzen. Möglich ist das per REST-Abfrage beim Start, als eingebundene Datei oder durch Überschreiben beim Deployment. Was passt, hängt von der Infrastruktur ab (Folie 348–350).

Verwandt

• Angular – die Bausteine, die hier angeordnet werden
• Dependency Injection – Injektoren pro lazy Modul
• State Management – Zustand pro Feature
• Angular CLI – erzeugt Module und Features, Budgets für die Paketgrösse
• Angular-Routing – Lazy Loading im Code
• Microservices – dieselbe Abwägung zwischen Zerlegen und Zusammenhalten im Backend
• Container – Auslieferung als unveränderliches Image