DEV Community: Fabian - angular-freelancer.de

QDA in der Praxis: Wie Du mit Quality-Driven Architecture robuste Angular-Anwendungen entwickelst

Fabian - angular-freelancer.de — Tue, 17 Jun 2025 15:14:50 +0000

Ob in eigenen Projekten, den Medien oder Erfahrungsberichten anderer Software Engineers und -Architect:innen habe ich eines immer wieder gesehen: Ideen scheitern nicht an der Funktionalität, sondern an einer vernachlässigten Architektur.
Eine Anwendung, die heute funktioniert, aber kein solides Fundament aufweist, wird morgen zur Last. Sie wird langsam, fehleranfällig und kaum noch wartbar. Nicht selten endet das in einem Rewrite (der im Zweifel wieder in derselben Sackgasse landet) und dem Verlust der Mitarbeiter, die man nun am ehesten bräuchte, da diese immer wieder darauf hingewiesen haben.

Deshalb möchte ich heute das Thema Quality-Driven Architecture besprechen.

Es ist ein relativ leicht anzuwendendes Vorgehen. Wenn man so will, eine Art Kompass um Software und somit auch Angular-Anwendungen zu bauen, die nicht nur heute funktionieren, sondern auch in Zukunft stabil, schnell und erweiterbar bleiben.

Was heißt „qualitätsgetrieben“? Eine Analogie

Stell euch vor, ihr baut ein Haus. Die funktionalen Anforderungen sind klar: Es braucht ein Dach, Wände, eine Küche, ein Bad und eine Garage. Das ist das „Was“. Aber jetzt kommen die entscheidenden Fragen, die Qualitätsfragen – das „Wie gut“:

Wie gut soll das Haus gedämmt sein, damit die Heizkosten niedrig bleiben? (Performance & Effizienz)
Wie sicher sollen die Schlösser sein? (Sicherheit)
Wie einfach soll es sein, später einen Wintergarten anzubauen? (Wartbarkeit & Erweiterbarkeit)
etc.

Genau das Gleiche tun wir in der qualitätsgetriebenen Softwarearchitektur. Wir definieren von Anfang an, welche Qualitätsmerkmale für unser Projekt relevant sind. Diese Ziele leiten dann jede unserer Entscheidungen. Das Schöne daran: Diese Ziele sind meist schon deutlich vor den konkreten, funktionalen Anforderungen definierbar und mit den Stakeholdern verhältnismäßig schnell zu ermitteln.

Essenziell für ein Qualitätsziel ist, dass es Messbar ist. Denn nur was messbar ist, kann man monitoren, erreichen oder verbessern.

Ein wichtiger Werkzeugkoffer: Die Qualitätsziele von arc42

Um diese Ziele greifbar zu machen, orientieren wir uns am praxiserprobten Modell von arc42. Es hilft uns, Klarheit zu schaffen und im Team die gleiche Sprache zu sprechen. Außerdem können wir uns an weit über 100 Zielen und Beispielen abarbeiten oder sie durchsuchen und Szenarien hierfür durchdenken. Es beinhaltet auch die Qualitäten aus ISO-25010.

1. Laufzeitqualität: Was der Benutzer erlebt

Hier geht es um alles, was während der Ausführung der Anwendung spürbar und gleichzeitig messbar ist.

🚀 Performance & Effizienz: Die Geschwindigkeit ist oft der erste und wichtigste Eindruck und sie kostet im Zweifel Umsatz.
- Messbares Ziel-Szenario: "Die Produktdetailseite muss bei einer simulierten 'Fast 3G'-Netzwerkverbindung einen Largest Contentful Paint (LCP) von unter 2,5 Sekunden erreichen, gemessen mit Lighthouse-Tools im CI/CD-Prozess."
- ➡️ Architektonische Antwort in Angular:
- Lazy Loading: Wir laden nicht die gesamte App auf einmal, sondern nur die Teile, die der Nutzer gerade braucht. Bei einem E-Book beispielsweise laden wir nicht den gesamten Inhalt, stattdessen laden wir nur die aktuelle Seite oder ggf. ein Kapitel. Dies ist mit den modernen Standalone Components und weiteren Mitteln wie Lazy-Routing und @defer in Angular ein Kinderspiel.
- NgOptimizedImage: Bilder sind oft die größten Performance-Fresser. Diese spezielle Direktive ist wie ein intelligenter Assistent, der sicherstellt, dass Bilder erst geladen werden, wenn sie sichtbar werden, und das in der optimalen Größe.
🔐 Sicherheit (Security): Das Vertrauen unserer Nutzer ist ein hohes Gut.
- Messbares Ziel-Szenario: "Bei einem automatisierten Security-Scan mit OWASP ZAP als Teil des Nightly-Builds dürfen keine neuen 'High'- oder 'Medium'-Alerts für Cross-Site Scripting (XSS) oder Cross-Site Request Forgery (CSRF) im Frontend-Scope auftreten."
- ➡️ Architektonische Antwort in Angular:
- Angulars eingebauter Schutz: Das Framework ist hier Ihr stärkster Verbündeter. Es bereinigt standardmäßig alle Eingaben, bevor sie auf der Seite angezeigt werden und schützt so automatisch vor gängigen Angriffen wie Cross-Site Scripting (XSS).
🤝 Zuverlässigkeit (Reliability): Die Anwendung muss auch dann stabil bleiben, wenn mal etwas schiefgeht.
- Messbares Ziel-Szenario: "Antwortet der API-Endpunkt für Produktempfehlungen mit einem Error HTTP-Status 503 (Service Unavailable), muss die Seite ohne JavaScript-Fehler weiterlaufen und die definierte Fallback-Komponente ('Empfehlungen konnten nicht geladen werden') wird innerhalb von 500ms angezeigt."
- ➡️ Architektonische Antwort in Angular:
- Fehlerbehandlung in Services: Wir fangen Fehler dort ab, wo sie entstehen – meist bei der Kommunikation mit dem Server (Backend). Mit dem RxJS-Operator catchError können wir einen Fehler beispielsweise elegant abfangen und einen stabilen Zustand (z.B. eine leere Liste) an die Komponente weitergeben, damit die UI nicht in einen Error-State gelangt.

2. Entwicklungsqualität: Unser Alltag als Entwickler

Diese Ziele sorgen dafür, dass die Arbeit an der Codebasis effizient und möglichst frustfrei bleibt.

⚙️ Wartbarkeit (Maintainability): Der Code muss auch in sechs Monaten noch verständlich und einfach zu ändern sein. Das ist vielleicht das wichtigste Ziel für die Langlebigkeit eines Projekts.
- Messbares Ziel-Szenario: "Die zyklomatische Komplexität jeder Methode innerhalb von Angular-Services und -Komponenten, gemessen durch Tools wie SonarQube, darf den Wert 10 nicht überschreiten. Neue Pull Requests, die diesen Schwellenwert verletzen, werden automatisch blockiert."
- ➡️ Architektonische Antwort in Angular:
- Organisation nach Features: Wir gruppieren Code nicht nach Typ (alle Services in einem Ordner), sondern nach fachlicher Zuständigkeit (alles zum Thema „User“ in einem Ordner). So ist alles, was zusammengehört, auch beisammen.
- Trennung in „Smart“- und „Dumb“-Komponenten: Dieses Muster ist Gold wert.
  - Smart: Die Komponente, die weiß, was zu tun ist. Sie spricht mit den Services und holt Daten.
  - Dumb: Eine dumme, aber hübsche Komponente, die nur Daten entgegennimmt und anzeigt. Sie ist wiederverwendbar und einfach zu verstehen.
📋 Testbarkeit (Testability): Vertrauen ist gut, testen ist besser.
- Messbares Ziel-Szenario: "Die Code-Abdeckung (Code Coverage) durch Unit-Tests für alle einer neuen Unit muss bei mindestens 85 % liegen und soll innerhalb von 30 Minuten erreicht werden können. Dieser Wert wird bei jedem Commit geprüft und darf nicht sinken."
- ➡️ Architektonische Antwort in Angular:
- Logik in Services auslagern: Eine wichtige Regel für gute Testbarkeit! Komponenten-Code ist schwerer zu testen. Logik, die in einem einfachen TypeScript-Service steckt, kann hingegen leicht mit Unit-Tests überprüft werden. Angulars Dependency Injection hilft uns dabei, diese Services in unseren Tests durch Mocks zu ersetzen.
- Test Driven Development (TDD): Tests schreiben, bevor die eigentliche Logik implementiert wird. So stellt man sicher, dass jede neue Funktionalität von Anfang an abgedeckt ist und erreicht idR. eine gut testbare Struktur und die gewünschte Coverage fast automatisch.

3. Betriebsqualität: Die Anwendung im Live-Betrieb

Wenn die Anwendung live ist, wollen wir wissen, was passiert.

📊 Betrieb & Monitoring (Operations): Blind im Produktivsystem zu agieren, ist wie Autofahren bei Nacht ohne Licht.
- Messbares Ziel-Szenario: "Alle HTTP-Anfragen, die eine Antwortzeit von über 800 ms aufweisen, müssen automatisch ein Event im Monitoring-Tool auslösen, das die genaue URL, die Dauer und die User-ID enthält."
- ➡️ Architektonische Antwort in Angular:
- HttpInterceptor: Dies ist ein mächtiges Werkzeug in Angular. Wir können einen zentralen Interceptor für alle Server-Anfragen bauen. Dieser kann zum Beispiel messen, wie lange jede Anfrage dauert, und diese Information an ein externes Monitoring-Tool (z.B. Sentry, Datadog o.Ä.) senden. So bemerken wir Performance-Probleme, bevor Nutzer sich beschweren.

Fazit

Qualitätsgetriebene Architektur ist kein Hexenwerk. Es ist die bewusste Entscheidung, von Anfang an über das „Wie gut“ nachzudenken. Sprecht mit euren Teams und Auftraggeber:innen über diese Ziele. Priorisiert sie! Ein kleines internes Tool braucht vermutlich nicht die gleiche Ausfallsicherheit wie ein Online-Shop.

Wenn diese Prinzipien verinnerlicht werden, werdet ihr nicht nur bessere Anwendungen bauen. Ihr werdet auch zu besseren Architekt:innen, die vorausschauend planen und Systeme erschaffen, die Freude machen – bei der Nutzung und bei der Weiterentwicklung.
Fangt klein an, wählt zwei oder drei Qualitätsziele für die nächsten Features und wendet ggf. auch welche der oben genannten Muster an. Ihr werdet den Unterschied spüren und bitte auch messen.

Angular & ESBuild: Dein Weg zum perfekten Tree Shaking 🌳🚀

Fabian - angular-freelancer.de — Thu, 05 Jun 2025 16:25:12 +0000

Wir kennen es alle. Wenn man täglich mit großen Angular-Anwendungen arbeitet, weiß man einfach, wie entscheidend Performance für eine gute UX (User Experience) ist. Ein wirklich großer Faktor hierfür ist nicht nur die effiziente Implementierung von Algorithmik oder ähnlichem sonder vor Allem auch die Größe der ausgelieferten JavaScript-Bundles, die aus unserem TypeScript-Code entstehen. Zum Verringern dieser gibt es verschiedene Möglichkeiten. Eine dieser Möglichkeiten möchte ich in diesem Beitrag etwas näher betrachten: Tree Shaking

Wir betrachten Tree Shaking hier vor allem ab Angular v17/v18 mit Standalone Components und ESBuild anstatt Webpack.

Es ist im Übrigen kein Problem, wenn Du noch nicht super viel Erfahrung hast - Tree Shaking ist für alle da. Ich versuche Dich schrittweise mitzunehmen.

Was ist Tree Shaking überhaupt?

Stell dir vor, dein Code ist ein großer, sehr verzweigter Baum. Jede Funktion, jede Klasse und jede Variable die du importierst ist ein Ast oder Blatt an diesem Baum.
Jetzt ist es jedoch so, dass wir sehr häufig Bibliotheken oder Module importieren, die viel Mehr an Funktionen bieten als wir tatsächlich in unseren Anwendungen nutzen.

Tree Shaking ist der Prozess, bei dem ein Bundler (wie früher Webpack oder jetzt ESBuild in Angular) erkennt, welche Teile unseres Codes tatsächlich von unserer Applikation genutzt werden. Alle ungenutzten "Äste" und "Blätter" werden vom Bundler aus den Artefakten, die wir später als Anwendung deployen, entfernt. Das Ergebnis ist ein kleineres, schlankeres und schneller ladbares Bundle, das der Browser des Users herunterladen muss.

Das Problem: Zu viel Code im Bundle

Bevor wir weiter ins Detail gehen, schauen wir uns ein kleines, aber alltägliches Szenario an: Wir nutzen eine Utility-Bibliothek, für diesen Beitrag die fiktive Bibliothek @angstitc/utils, welche diverse Funktionen bereitstellt:

// app.ts
import { formatEnergyAmount, calculateTax, validateEmail } from '@angstitc/utils'
@Component({
  selector: 'app-root',
  template: `
    <h1>Meine Anwendung</h1>
    <p>Preis: {{ formatEnergyAmount(123.45, 'kWh') }}</p>
    `
})
export class AppComponent {
  // ...
  formatEnergyAmount = formatEnergyAmount;
}

// node_modules/@angstitc/utilsindex.ts (vereinfacht)
export function formatEnergyAmount(amount: number, unit: string): string {
  // ... Logik zur Formatierung einer Energiemenge ...
  console.log('formatEnergyAmount aufgerufen!');
  return `${amount.toFixed(2)} ${unit}`;
}

export function calculateTax(amount: number, rate: number): number {
  // ... Logik zur Steuerberechnung ...
  console.log('calculateTax aufgerufen!');
  return amount * rate;
}

export function validateEmail(email: string): boolean {
  // ... Logik zur E-Mail-Validierung ...
  console.log('validateEmail aufgerufen!');
}

In diesem Szenario importieren wir formatEnergyAmount, calculateTax und validateEmail aus @angstitc/utils. Aber in unserer AppComponent nutzen wir nur formatEnergyAmount. Ohne effektives Tree Shaking würden calculateTax und validateEmail trotzdem in unserem finalen Bundle landen! Das ist unnötiger Balast.

Angular 17 und ESBuild: Die Traumhochzeit für Tree Shaking

Die gute Nachricht ist, dass Angular in Kombination mit ESBuild herborragend im Tree Shaking ist. ESBuild ist hierbei nicht nur schneller als Webpack es war, sondern auch noch effizienter.

Was macht ESBuild darin aber so gut? Die Antwort ist so unspektakulär wie simpel: Es wurde von Anfang an mit dem Fokus auf hohe Performance und Effizienz entwickelt. Hierzu nutzt es moderne JavaScript-Module (ESM - ECMAScript Modules), welche es sehr gut versteht und welche die Grundlage für effektives Tree Shaking bilden.

Wie funktioniert Tree Shaking (unter der Haube)

Damit Tree Shaking sich effektiv auswirkt, müssen einige Voraussetzungen erfüllt sein:

1. ESM-Module: ESM bilden die Basis. Die statischen import- und export-Statements können durch den Bundler vor Ausführung des Codes analysiert werden. Hierdurch wird klar, welche Funktionen und Codeabschnitte wirklich genutzt werden. Mit den dynamischen CommonJS-Imports (require()) wäre dies deutlich schwieriger zu erreichen.

2. Side-Effect-Free Code: Ein Modul gilt als Side-Effect-Free, wenn der Import des Moduls keine globalen Auswirkungen hat. So kann beispielsweise eine Bibliothek in ihrer package.json einen Eintrag in sideEffects haben, der dem Bundler dies klar kommuniziert. Dieser Eintrag kann neben boolschen-Werten auch ein Array von Dateipfaden sein (z.B. globale Stylesheets), anhand derer der Bundler weiß, welche Dateien er im Tree Shaking ignorieren muss.
In unserem oben gezeigten Beispiel erfüllen die genutzten Funktionen dieses Kriterium.

3. Minifier: Nach dem Tree Shaking kommt ein Minifier zum Einsatz. Dieser entfernt ungenutzten Code, der durch den Bundler markiert wurde und optimiert den gesamten Code durch z.B. Kürzung von Variablen-Namen und Unprettify (entfernen von Zeichen die nur der Formatierung dienen etc.).

Unser Beispiel in Aktion

Kehren wir zu unserem Beispiel zurück. Wenn wir unsere App mit der Prod-Configuration (sollte der Default sein) builden...

ng build

...wird ESBuild unsere AppComponent analysieren. Es wird sehen, dass formatEnergyAmount verwendet wird, calculateTax und validateEmail jedoch nicht. Dadurch, dass alle drei Funktionen über einen separaten Export verfügen und die Bibliothek als Side-Effect-Free markiert ist (achtet bei euren Bibliotheken bitte darauf. Gute Util-Bibliotheken sind so gebaut), wird ESBuild die beiden ungenutzten Funktionen nicht in das auszuliefernde Bundle aufnehmen.
Das lässt sich überprüfen, indem man den dist-Folder ein wenig analysiert. Das Bundle wird kleiner sein und bei der Analyse der JS-Dateien (hierbei helfen Source Maps, da der Code minified wurde), stellen wir fest, dass calculateTax und validateEmail nicht im JavaScript-Artefact enthalten sind.
Das bedeutet: Selbst unused Imports wären nicht am Tree Shaking Türsteher vorbeigekommen.

Tipps, um Tree Shaking aktiv zu verbessern

Als Entwickler können wir aktiv dazu beitragen, das Tree Shaking in unseren Angular-Projekten zu verbessern:

Immer spezifisch importieren:
- Importiere nur was du brauchst
- Gut: import { formatEnergyAmount } from '@angstitc/utils'
- Vermeide wo möglich: import * as Utils from '@angstitc/utils'; Utils.formatEnergyAmount(...) - das erschwert die Statische analyse.
Nicht jede Bibliothek schafft es in dein Projekt:
Bevor du eine neue Bibliothek zu deinem Projekt hinzufügst, prüfe, ob sie moderne ESM-Module verwendet und Tree Shaking-freundlich ist. Gute Bibliotheken kennzeichnen dies oft in ihrer Dokumentation oder durch den sideEffects Eintrag in ihrer package.json.
Side-Effects verstehen: Sei dir bewusst, dass Code, der globale Side-Effects hat (z.B. globale CSS-Dateien, die du direkt in TypeScript importierst und die keine Module sind), nicht einfach "weggeschüttelt" werden können. Das ist auch in Ordnung, da sie ja gebraucht werden. Nutze dies jedoch nur wo nötig.
Immer Production-Builds ausliefern: Nur so werden Tree Shaking und Minifications angewandt.

Fazit

Tree Shaking ist keine magische Lösung für alle Performance-Probleme, aber es ist ein grundlegender und mächtiger Optimierungsschritt, der dir dabei hilft, die Größe deines JavaScript-Bundles signifikant zu reduzieren. Mit der nativen Integration von ESBuild ist das Tree Shaking in deinen Anwendungen effizienter und schneller als je zuvor.

Indem du die Prinzipien von Tree Shaking verstehst und bewusste Entscheidungen bei deinen Imports triffst, kannst du sicherstellen, dass deine Angular-Apps schlank, schnell und responsive bleiben. Deine Nutzer*innen werden es dir Danken - und deine Auftraggeber auch!

🚀 Angular v20 ist da 🚀

Fabian - angular-freelancer.de — Thu, 29 May 2025 16:11:30 +0000

Hallo zusammen! 👋

Angular v20 ist da und bringt einige spannende Neuerungen mit sich, die unsere Entwicklerherzen höher schlagen lassen! 🚀

Hier eine kleine Liste der (für mich) wichtigsten Neuerungen:

Mehr Stabilität bei Signals: Die Reaktivität in Angular hat in den letzten Releases einen Paradigmenwechsel durchlebt. Dieser hält an und wird konsequent fortgeführt. So sind effect, linkedSignal und toSignal nun stable und können auch in Projekten mit etwas konservativerem Ansatz genutzt werden.
Zoneless Developer Preview: Ein weiterer großer Schritt in Richtung Zukunft ist getan: Zoneless ist nun in der Developer Preview. Feinere Change Detection, bessere Performance und einfacherer Integration mit anderen Frameworks könnt ihr jetzt also guten Gewissens ausprobieren.
Template Literals: Strings in Templates mit +zusammenbauen oder gar durch mehrere Interpolations gehen ist nun vorbei. Wie auch schon direkt im TypeScript code, könnte ihr Teile eurer Strings im Template dynamisch verändern:
<span>{{ 'Willkommen ${user().name}! Schön dich zu sehen.'}}</span>
Ng-Reflect im DOM fällt weg: Bisher waren im Developer-Mode im DOM die NG-Reflect-Attribute für z.B. RouterLinks zu sehen. Diese fallen nun ALLE weg. Wer sich in Unit Tests hierauf verlassen hat, muss nachbessern.
Überarbeiteter Styleguide: Bye bye .component.<xyz>-Suffix. Ab sofort fallen die Suffixe für Components, Services und Co. weg.
Alle Neuerungen des Styleguides findet ihr hier

Was sind für euch die wichtigsten Änderungen? 👇

Angular & Facades: So entkoppelst du deine Components und machst deinen Code wartbarer

Fabian - angular-freelancer.de — Thu, 08 May 2025 18:11:58 +0000

Sobald eine Angular-Anwendung wächst kann es schnell unübersichtlich werden. Komponenten die beispielsweise direkt auf Backend-APIs zugreifen oder den Application-State manipulieren sind hier aus meiner Erfahrung heraus keine Seltenheit und führen langfristig zu Problemen. Komponenten werden zu groß, die Testbarkeit leidet und das Austauschen von Stores oder APIs wird mühsam und kostspielig.

Ein Lösungsansatz für diese Problematik könnte die Verwendung von Facades sein. Facades sind eine Art von Design-Pattern, das eine vereinfachte Schnittstelle zu einer komplexen API oder einem System bereitstellt. In Angular-Anwendungen können Facades verwendet werden, um den Zugriff auf verschiedene Teile der Anwendung zu abstrahieren und zu vereinheitlichen. Sie fungieren als Vermittler zwischen der UI und den Services, die die Logik und den Zustand der Anwendung verwalten.

Was sind Facades (in Angular)?

Stell dir eine Fernbedienung für ein komplexes Soundsystem vor. Anstatt dich mit den unzähligen Knöpfen und Einstellungen der einzelnen Komponenten (Verstärker, Equalizer, Lautsprecher) auseinandersetzen zu müssen, bietet dir die Fernbedienung eine einfache Möglichkeit, die Lautstärke zu regeln, die Quelle auszuwählen oder das System ein- und auszuschalten. Genau diese Rolle übernimmt eine Facade in Angular.

Eine Angular Facade ist ein Service, der als vereinfachte Schnittstelle zu einem komplexeren Subsystem dient. Dieses Subsystem kann Backend-APIs, State-Management-Lösungen oder andere komplexe Dienste umfassen. Die Facade kapselt die zugrunde liegende Komplexität und bietet den Komponenten eine intuitive und leicht verständliche API.

Ein einfaches Beispiel: Angenommen, du möchtest Benutzerdaten abrufen. Ohne Facade könnte deine Komponente direkt den HttpClient und einen spezifischen API-Service nutzen. Mit einer Facade sieht das Ganze so aus:


// The actual API service
@Injectable({
  providedIn: 'root',
})
export class UserService {
  readonly #httpClient = inject(HttpClient);

  getUsers() {
    return this.#httpClient.get<User[]>(
      'https://jsonplaceholder.typicode.com/users'
    );
  }
}

// The facade to abstract the Access to the API
@Injectable({
  providedIn: 'root',
})
export class UserDataFacade {
  readonly #userService = inject(UserService);

  getUsers(): Observable<User[]> {
    return this.#userService.getUsers();
  }
}

// The component that uses the facade
@Component({
  selector: 'app-user-profile',
  imports: [AsyncPipe],
  template: `@for (user of users$ | async; track user.id) {
    <div class="user">
      <h2>{{ user.name }}</h2>
      <p>Email: {{ user.email }}</p>
      <p>Phone: {{ user.phone }}</p>
      <p>Website: {{ user.website }}</p>
    </div>
    }`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class UserListComponent {
  readonly #userDataFacade = inject(UserDataFacade);
  protected readonly users$ = this.#userDataFacade.getUsers();
}

In dem hier zu sehenden Beispiel delegiert die UserDataFacade den Zugriff auf den UserService und stellt eine vereinfachte API bereit, die von der Komponente verwendet werden kann. Dadurch wird die Komplexität des zugrunde liegenden Systems verborgen und die Testbarkeit sowie Wartbarkeit der Anwendung verbessert. Angenommen die User-Daten würden durch 50 andere Komponenten verwendet, dann würde es genügen die Facade zu ändern und nicht alle 50 Komponenten. Das ist einer der großen Vorteile von Facades.

Die Tests für die Facade sind ebenfalls einfacher, da du nur die Facade selbst testen musst, anstatt alle Komponenten, die den Service verwenden. Du kannst Mock-Implementierungen der Facade verwenden, um sicherzustellen, dass die Komponenten korrekt mit der Facade interagieren, was folgendes Beispiel zeigt:

describe('UserListComponent', () => {
  let component: UserListComponent;
  let fixture: ComponentFixture<UserListComponent>;

  let mockUserFacade: Partial<UserDataFacade>;

  beforeEach(async () => {
    mockUserFacade = {
      getUsers: jest.fn().mockRejectedValue(
        of([
          {
            id: 1,
            name: 'Leanne Graham',
            username: 'Bret',
            email: 'Sincere@april.biz',
            address: {
              street: 'Kulas Light',
              suite: 'Apt. 556',
              city: 'Gwenborough',
              zipcode: '92998-3874',
              geo: {
                lat: '-37.3159',
                lng: '81.1496',
              },
            },
            phone: '1-770-736-8031 x56442',
            website: 'hildegard.org',
            company: {
              name: 'Romaguera-Crona',
              catchPhrase: 'Multi-layered client-server neural-net',
              bs: 'harness real-time e-markets',
            },
          },
        ])
      ),
    };

    await TestBed.configureTestingModule({
      imports: [UserListComponent],
      providers: [{ provide: UserDataFacade, useValue: mockUserFacade }],
    }).compileComponents();

    fixture = TestBed.createComponent(UserListComponent);
    component = fixture.componentInstance;

    fixture.detectChanges();
    await fixture.whenStable();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });

  it('should call getUsers on init', () => {
    expect(mockUserFacade.getUsers).toHaveBeenCalledTimes(1);
  });

  // ... more tests
});

Best Practices bei der Verwendung von Facades

Granularität: Halte die Facade granular und spezifisch für einen bestimmten Anwendungsfall oder eine bestimmte Funktionalität. Vermeide es, eine große Facade zu erstellen, die viele verschiedene Funktionen abdeckt. Genauso ist es nicht sinnvoll eine Facade für jede Komponente zu erstellen. Eine Facade sollte immer mehrere Komponenten bedienen können. Die Balance zwischen Granularität und Wiederverwendbarkeit ist hier entscheidend.
Verwende Dependency Injection: Nutze Angulars Dependency Injection, um Abhängigkeiten in der Facade zu verwalten. Dadurch wird die Testbarkeit und Wartbarkeit verbessert.
Vermeide direkte Abhängigkeiten: Vermeide direkte Abhängigkeiten zwischen der Facade und den Komponenten. Verwende stattdessen Observable oder andere Mechanismen, um die Kommunikation zu ermöglichen.
Vermeide zu viel Logik: Halte die Logik in der Facade minimal. Die Facade sollte hauptsächlich als Vermittler fungieren und nicht zu viel Geschäftslogik enthalten. Diese sollte in den genutzten Services liegen.

Vorteile von Facades

Abstraktion: Facades abstrahieren die Komplexität des zugrunde liegenden Systems und bieten eine vereinfachte API.
Testbarkeit: Facades erleichtern das Testen von Komponenten, da sie eine klare Schnittstelle bieten und die zugrunde liegende Implementierung verbergen.
Wartbarkeit: Änderungen am zugrunde liegenden System erfordern keine Änderungen an den Komponenten, die die Facade verwenden.
Konsistenz: Facades fördern eine konsistente API für den Zugriff auf verschiedene Teile der Anwendung, was die Lesbarkeit und Wartbarkeit des Codes verbessert.
Flexibilität: Facades ermöglichen es, verschiedene Implementierungen oder Strategien auszutauschen, ohne dass die Komponenten davon betroffen sind.
Entkopplung: Facades entkoppeln die Komponenten von den spezifischen Implementierungen der Dienste, was die Modularität und Wiederverwendbarkeit des Codes erhöht.
Zentralisierung: Facades bieten einen zentralen Ort für die Verwaltung von Abhängigkeiten und Konfigurationen, was die Übersichtlichkeit und Wartbarkeit des Codes verbessert.
Erweiterbarkeit: Facades ermöglichen es, neue Funktionen oder Dienste hinzuzufügen, ohne dass die bestehenden Komponenten geändert werden müssen.
Fehlerbehandlung: Facades können eine zentrale Stelle für die Fehlerbehandlung bieten, was die Konsistenz und Wartbarkeit des Codes verbessert.
Performance: Facades können Optimierungen wie Caching oder Lazy Loading implementieren, um die Leistung der Anwendung zu verbessern.
Dokumentation: Facades bieten eine klare und konsistente API, die die Dokumentation und das Verständnis der Anwendung erleichtert.
Best Practices: Facades fördern bewährte Praktiken wie Separation of Concerns und Single Responsibility Principle, was zu einem saubereren und wartbareren Code führt.

Nachteile von Facades

Zusätzliche Komplexität: Facades können zusätzliche Komplexität in die Anwendung einführen, insbesondere wenn sie nicht gut strukturiert sind.
Überabstraktion: Facades können zu einer Überabstraktion führen, wenn sie zu viele Funktionen oder Abstraktionen bieten, die nicht benötigt werden.
Leistungsprobleme: Facades können in einigen Fällen die Leistung beeinträchtigen, insbesondere wenn sie nicht effizient implementiert sind.
Wartungsaufwand: Facades erfordern zusätzlichen Wartungsaufwand, insbesondere wenn sich die zugrunde liegenden Systeme ändern.
Testaufwand: Facades erfordern zusätzliche Tests, um sicherzustellen, dass sie korrekt funktionieren und die zugrunde liegenden Systeme korrekt abstrahieren.

Fazit

Angular Facades sind ein mächtiges Werkzeug, um die Architektur deiner Anwendung zu verbessern. Durch die Entkopplung von Komponenten von komplexen Abhängigkeiten wie Backend-APIs und State-Management-Lösungen schaffst du eine sauberere, wartbarere und testbarere Codebasis. Wenn du in größeren Angular-Projekten arbeitest, solltest du den Einsatz von Facades unbedingt in Betracht ziehen, um langfristig die Qualität und Flexibilität deiner Anwendung zu gewährleisten.

Lass mich gerne wissen, wie du Facades in deinen Projekten einsetzt oder ob du noch weitere Fragen zu diesem Thema hast. Ich freue mich auf den Austausch mit dir!

Für jeden, der sich in letzter Zeit weniger mit den fundamentalen Änderungen in Angular auseinandergesetzt hat oder neu im Angular-Kosmos unterwegs ist

Fabian - angular-freelancer.de — Sun, 27 Apr 2025 15:20:50 +0000

Fabian - angular-freelancer.de

Apr 27 '25

Angular 17+ Control Flow: Bye Bye `ngIf`& `ngFor`- Hallo `@if`& `@for

#angular #webdev #typescript #controlflow

Comments

3 min read

Angular 17+ Control Flow: Bye Bye `ngIf`& `ngFor`- Hallo `@if`& `@for

Fabian - angular-freelancer.de — Sun, 27 Apr 2025 15:19:03 +0000

Seit Angular 17 hat sich die Art, mit der wir Logik in unseren Templates steuern, grundlegend geändert. Die altbekannten strukturellen Direktiven wie *ngIf, *ngFor und *ngSwitch bekommen Konkurrenz durch eine neue, den Standard definierende Control Flow Syntax: @if, @for und @switch. Aber warum ganze? Ist es nur syntactic Sugar oder steckt mehr dahinter? TLDR;: Es ist mehr!

In diesem Beitrag tauchen wir tief in die neue Syntax ein, vergleichen sie mit den alten Direktiven und beleuchten die Vorteile, die weit über die reine Optik hinausgehen.

Warum ein neuer Control Flow?

Das Angular-Team verfolgt mit dieser Änderung mehrere Ziele:

Bessere Performance: Die neue Syntax ist direkt in den Compiler integriert und benötigt keine Direktiven-Imports, was zu kleineren Bundles und potenziell schnellerer Ausführung führen kann (insbesondere in Kombination mit zukünftigen Zoneless-Strategien).
Verbesserte Developer Experience (DX): Eine intuitivere, klarere Syntax, die weniger fehleranfällig ist und schon beim visuellen Scannen des Codes ersichtlich ist.
Striktere Typisierung: Insbesondere @switch profitiert von besserer Type Narrowing.

Im Detail: `@if`, `@else if`, `@else`

Die neue Bedingungslogik ist sichtlich einfach:

@if (userLoggedIn()) {
  <p>Willkommen zurück, {{ userName() }}!</p>
  <button (click)="logout()">Logout</button>
} @else if (isLoading()) {
  <p>Lade Benutzerdaten...</p>
} @else {
  <p>Bitte einloggen.</p>
  <button (click)="login()">Login</button>
}

Im vergleich zu *ngIf:

Kein thenoder else mit Template-Referenzen mehr nötig - deutlich erhöhte Lesbarkeit.
Klar definierte Blöcke

Im Detail `@for` und `@empty`

Das Iterieren über Listen wurde ebenfalls angepasst, wie in folgendem Beispiel zu erkennen ist:

<ul>
  @for (user of users(); track user.id) {
    <li [class.first]="$first" [class.last]="$last" [class.even]="$event" [class.odd]="$odd">
      {{ i + 1 }}/{{ $count }}: {{ user.name }} (ID: {{ user.id }})
    </li>
  } @empty {
    <li>Keine Benutzer gefunden.</li>
  }
</ul>

Zu beachten bei @for:

track ist nun Pflicht: Das führt dazu, dass eine Funktion bzw. ein Parameter angegeben werden muss, anhand dessen das Tracking der Listeneinträge durch Angular geschieht. Dies verbessert die Performance des Renderings eklatant, da Angular erkennt, welches Element bei Änderungen neu gerendert werden muss, anstatt die ganze Liste neu darzustellen. Dies war vorher optional und wurde entsprechend oft vergessen ohne den Impact zu kennen.
empty-Block: Das Anzeigen von Empty-States wird hiermit out of the Box durch Angular unterstützt und spart mühsame IF-Abfragen.
Implizite Variablen: Variablen, die früher im Schleifen-Kopf expliziert definiert werden mussten, stehen nun direkt zu Verfügung. Diese sind $index, $first, $last, $even, $odd und $count.

Im Detail: `@switch`, `@case` und `@default`

Zustandsabhängige Darstellungen sind nun deutlich mehr straight-forward zu lösen.

Im vergleich zu *ngSwitch:

Bessere Typprüfung innerhalb der @case-Blöcke (Type Narrowing)
Klarere Syntax und deutlich getrenntere Blöcke ohne *ngSwitchCase-Directiven

@switch (accessLevel()) {
  @case ('admin') {
    <app-admin-dashboard />
  }
  @case ('moderator') {
    <app-moderator-tools />
  }
  @default {
    <app-user-profile />
  }
}

Vorteile zusammengefasst:

Performance: Potenziell kleinere Bundles und effizientere Change Detection (insbesondere in Zukunft). track bei @for ist ein direkter Performance-Gewinn.
Developer Experience: Intuitiver, weniger Boilerplate, besser lesbar.
Typsicherheit: Vor allem bei @switch verbessert.
Keine Imports: Die neue Syntax ist eingebaut, keine Notwendigkeit, CommonModule oder NgIf/NgFor etc. zu importieren (gerade bei Standalone Components, welche der neue Standard sind, sehr von Vorteil).

Migration

Die Migration ist, wie man es aus dem Angular-Ecosystem mittlerweile gewohnt ist, sehr einfach und Komfortabel durchzuführen. Das Angular Team bietet hierfür eine Schematic an, mit welcher existierender Code automatisch migriert und auf Wunsch auch formatiert wird:

ng generate @angular/core:control-flow

Fazit

Der neue Control Flow ab Angular Version 17 ist weit mehr als nur eine kosmetische Änderung. Er verbessert die Performance, die Developer Experience und die Typsicherheit. Die Pflicht zum track-Keyword bei @for allein ist ein riesiger Schritt für effizientere Listen-Updates. Es gibt keinen Grund, mit der alten Syntax zu arbeiten, wenn man mit Angular 17+ arbeitet!

Angular 19: Die neue ResourceAPI

Fabian - angular-freelancer.de — Sun, 01 Dec 2024 10:55:39 +0000

Mit Angular 19 führt das Framework eine neue und spannende Funktion ein: die ResourceAPI. Diese API ist darauf ausgelegt, die Arbeit mit HTTP-Anfragen einfacher, strukturierter und effizienter zu gestalten. Aber vor allem hebt es diese in die Welt der Signals. Hiermit geht das Angular-Team einen weiteren und essentiellen Schritt, Angular komplett auf Signals umzustellen.

In diesem Blogbeitrag werfen wir einen Blick darauf, was die Resource API ist, welche Vorteile sie bietet und wie sie verwendet werden kann.

Was ist neu?

Mit Angular 19 kommt die ResourceAPI. Diese vereinfacht das asynchrone Laden von Daten erheblich und bietet eine reaktive Schnittstelle für die Arbeit mit Ressourcen.

Achtung, die ResourceAPI ist noch Experimental. Von einem produktiven Einsatz rate ich dringend ab.

Was versprechen wir uns davon?

Vereinfachte Datenabholung - Weniger Boilerplate und bessere Lesbarkeit
Reaktivität - Mit Signals anstatt RxJS
Bessere Kontrolle - Effizienteres verfolgen des Status von Anfragen und verwalten von Fehlern, Reloads und Responses

Wie nutzt man die API?

Als beispielhaftes Backend nutze ich in folgenden Beispielen die API von restful-api.dev.

Folgend erstellen wir eine Component in einem Angular 19 Projekt, mit inline Template und Styles.

ng g c ApiResourceDemoComponent --inline-style=true --inline-template=true --change-detection=OnPush --skip-tests=true

In dieser Component möchten wir einen Datensatz laden, Fehler- und Loading-State darstellen sowie nach erfolgreichem abholen der Daten diese darstellen.

Hierzu nutzen wir die neue ResourceAPI.

import { JsonPipe } from '@angular/common';
import { ChangeDetectionStrategy, Component, resource, signal } from '@angular/core';


@Component({
  selector: 'app-api-resource-demo',
  imports: [JsonPipe],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <div>
      @if(dataResource.isLoading()) {
        <span>Loading...</span>
      }
      @if(dataResource.error()) {
        <span>Error while loading data </span>
      }
      @if(!dataResource.isLoading() && dataResource.hasValue()) {
        <pre>{{ dataResource.value() | json }}</pre>
      }
      <br>
      <hr>
      <button (click)="onReload()" [disabled]="dataResource.isLoading()">Reload data</button>
    </div>
  `,
})
export class ApiResourceDemoComponent {
    protected readonly id = signal(1);
    protected readonly dataResource = resource({
      request: () => ({id: this.id()}),
      loader: async ({request, abortSignal}) => await (await fetch(`https://api.restful-api.dev/objects/${request.id}`, { signal: abortSignal })).json()
    });


    protected onReload() {
      this.dataResource.reload();
    }
}

Das ID Signal steht hier exemplarisch für eine in irgend einer Art von außen gesetzte Variable.
Die dataResource wird aus dem Request und dem Loader zusammengesetzt. Der Request ist hier eher ein Parameter, das Angular Team ist sich hier im Naming selbst noch nicht 100% sicher.
Der Loader bildet den wirklichen HTTP Request ab, der hier via fetch gelöst wird. Das Abort-Signal ermöglicht es, den Request vorzeitig abzubrechen.

Die Resource ermöglicht es, abzufragen ob der Request noch in Gange ist (isLoading), ob ein Fehler aufgetreten ist (error) und ob der Request mit Daten beantwortet wurde (hasValue und value).
Weiterhin ermöglicht sie es auf einfachstem Wege ein Reload durchzuführen.

Fazit

Die ResourceAPI ist ein leistungsstarkes Werkzeug, das die Entwicklung von Angular-Anwendungen vereinfacht, wenn man asynchrone Daten in Ihrer Anwendung verwaltet. Kommen Sie bei Fragen gerne via Kommentare oder direkt über meine Website auf mich zu.

Weitere Ressourcen

Offizielle Dokumentationen
Ausführlichere Beispiele von den Angular-Architects

Angular Reactive Forms: Automatische Validation-Hints

Fabian - angular-freelancer.de — Thu, 21 Nov 2024 18:59:21 +0000

Die Validierung von Formularfeldern gehört für jeden Angular Developer zum Alltag. Das Anzeigen von Hinweisen in Formularen kann aber schnell zu viel repetetivem Boilerplate-Code führen - und den mag bekanntlich niemand.

Deshalb zeige ich in diesem Beitrag, wie man diesen Boilerplate-Code vermeidet und die Anzeige der Validierungshinweise streamlined - und sogar nachträglich einfach auf bestehenden Reactive Forms anwenden kann.

Setup

Bevor wir mit der Implementierung beginnen, richten wir ein neues Angular-Projekt ein. Ich nutze in diesem Beispiel Angular 18.

Initialisieren des Projekts:

ng new form-autovalidation-demo --style=scss --routing=false

Ins Projektverzeichnis wechseln:

cd form-autovalidation-demo

Nun erstellen wir die Komponenten / Directives die wir für die Demonstration benötigen:

ng generate component components/login-form
ng generate component components/form-validation-hint
ng generate directive directives/form-auto-validation-hint
ng generate directive directives/form-auto-validation-hint-location

Jetzt haben wir unser Grundgerüst:

Eine LoginFormComponent, die Repräsentativ für alle weiteren Formulare steht.
Eine FormValidationHinComponent, welche die Darstellung der Validiation-Hints übernimmt.
Eine FormAutoValidationHintDirective sowie eine FormAutoValidationHintLocationDirective, welche die Automatisierung der Anzeige übernehmen und es ermöglichen, Fehler an einer spezifischen Stelle und nicht nur Direct am FormControl anzuzeigen.

Ein kleiner Hinweis: Fürs Aussehen habe ich Tailwind mittels dieser Zeile in der index.html inkludiert:

<script src="https://cdn.tailwindcss.com"></script>

Für das richtige Einbinden in produktive Applikationen bitte entsprechend das NPM-Package nutzen.
Das Design der Login Form habe ich von TailwindUI übernommen.

Das Login-Formular

In der LoginFormComponent erstellen wir ein einfaches Formular mit Reactive Forms, welches die Eingabe von E-Mail und Passwort ermöglicht und die Eingaben validiert:

login-form.component.ts

@Component({
  selector: 'app-login-form',
  standalone: true,
  imports: [ReactiveFormsModule],
  templateUrl: './login-form.component.html',
  styleUrl: './login-form.component.scss'
})
export class LoginFormComponent {
  readonly #fb: FormBuilder = inject(FormBuilder);
  protected readonly form: FormGroup;

  constructor() {
    this.form = this.#fb.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required, Validators.minLength(6), Validators.maxLength(32)]],
    });
  }

  protected onSubmit(): void {
    if (this.form.valid) {
      console.log('Form Submitted:', this.form.value);
    } else {
      this.form.markAllAsTouched();
    }
  }
}

login-form.component.html

<div class="flex min-h-full flex-col justify-center px-6 py-12 lg:px-8">
  <div class="sm:mx-auto sm:w-full sm:max-w-sm">
    <h2 class="mt-10 text-center text-2xl/9 font-bold tracking-tight text-gray-900">Login</h2>
  </div>
  <div class="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">

    <form class="space-y-6" [formGroup]="form" (ngSubmit)="onSubmit()">
      <div>
        <label for="email" class="block text-sm/6 font-medium text-gray-900">Email address</label>
        <div class="mt-2">
          <input id="email" name="email" type="email" formControlName="email" autocomplete="email" required class="block w-full rounded-md border-0 py-1.5 text-gray-900 shadow-sm ring-1 ring-inset ring-gray-300 placeholder:text-gray-400 focus:ring-2 focus:ring-inset focus:ring-indigo-600 sm:text-sm/6">
        </div>
      </div>

      <div>
        <div class="flex items-center justify-between">
          <label for="password" class="block text-sm/6 font-medium text-gray-900">Password</label>
        </div>
        <div class="mt-2">
          <input id="password" name="password" type="password" formControlName="password" autocomplete="current-password" required class="block w-full rounded-md border-0 py-1.5 text-gray-900 shadow-sm ring-1 ring-inset ring-gray-300 placeholder:text-gray-400 focus:ring-2 focus:ring-inset focus:ring-indigo-600 sm:text-sm/6">
        </div>
      </div>

      <div>
        <button type="submit" class="flex w-full justify-center rounded-md bg-indigo-600 px-3 py-1.5 text-sm/6 font-semibold text-white shadow-sm hover:bg-indigo-500 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-indigo-600" [disabled]="form.invalid">Sign in</button>
      </div>
    </form>

  </div>
</div>

Implementierung der FormValidationHintComponent

Die FormValidationHintComponent zeigt später die Validierungshinweise eines FormControl basierend auf dessen Validierungsstatus an.

form-validation-hint.component.ts

@Component({
  selector: 'app-form-hint',
  standalone: true,
  imports: [],
  template: `
    @if (hints().length > 0) {
      <div class="flex flex-column gap-4 my-2">
        @for (hint of hints(); track $index) {
            <span class="text-red-600 text-sm leading-4">{{ hint }}</span>
        }
      </div>
  }
  `,
})
export class FormHintComponent {
  readonly hints = input<string[]>([]);
}

Implementierung der Directives

Folgend werden die Directives implementiert, die später die automatisierte Anzeige der Validierungsnachrichten ermöglicht.

FormAutoValidationHintLocationDirective

Diese Directive dient als Helfer für die noch zu implementiertende FormAutoValidationHintDirective. Sie markiert ausschließlich den Container, an welchen der Validierungshinweis angehangen werden soll.

form-auto-validation-hint-location.directive.ts

@Directive({
  selector: '[appFormAutoValidationHintLocation]',
  standalone: true,
  exportAs: 'hintLocation'
})
export class FormAutoValidationHintLocationDirective {
  readonly hintLocationContainerRef = inject(ViewContainerRef);
}

Die Directive kann durch das exportAs in Templates referenziert werden und stellt die ViewContainerRef nach außen zu Verfügung. Diese wird später dann durch die FormAutoValidationHintDirective genutzt.

FormAutoValidationHintDirective

Diese Directive übernimmt die hauptsächliche Arbeit und ist dafür zuständig, Validierungsfehler eines FormControls in lesbare Hinweise zu verwandeln und diese mittels der bereits definierten FormValidationHintComponent anzuzeigen.

form-auto-validation-hint.directive.ts

const VALIDATION_HINTS:  { [key: string]: string } = {
    required: 'Dieses Feld ist erforderlich.',
    email: 'Bitte geben Sie eine gültige E-Mail-Adresse ein.',
    minlength: 'Das Feld muss mindestens {requiredLength} Zeichen lang sein.',
    maxlength: 'Das Feld darf maximal {requiredLength} Zeichen lang sein.',
  };


@Directive({
  selector: '[appFormAutoValidationHint]',
  standalone: true
})
export class FormAutoValidationHintDirective implements OnInit {
  readonly #control = inject(NgControl);
  readonly #viewContainerRef = inject(ViewContainerRef);
  readonly #injector = inject(Injector);

  #valueChanges: Signal<any> | undefined;
  #statusChanges: Signal<FormControlStatus | undefined> | undefined;
  #formControl: FormControl | undefined;
  #hintRef: ComponentRef<FormHintComponent> | undefined;

  readonly location = input<FormAutoValidationHintLocationDirective | undefined>(undefined);


  ngOnInit(): void {
      if(!this.#control) {
      throw Error("Es konnte kein FormControl identifiziert werden, für welches Validierungs-Hints angezeigt werden sollen. Bitte sicherstellen, dass die Directive nur an FormControls eingesetzt wird.")
    }

    // Value Changes und Status Changes sind im Constructor noch nicht verfügbar, deshalb müssen wir im ngOnInit arbeiten
    this.#formControl = this.#control as unknown as FormControl;
    runInInjectionContext(this.#injector, () => {
      if(this.#formControl) {
        this.#valueChanges = toSignal(this.#formControl.valueChanges);
        this.#statusChanges = toSignal(this.#formControl.statusChanges)
      }

      effect(() => {
        // Bei Statusänderung und Wertänderung müssen die Hinweise aktualisiert werden
        if(this.#valueChanges) this.#valueChanges();
        let valid = false;
        if(this.#statusChanges) valid = this.#statusChanges() === "VALID";
        this.updateHints(valid);
      });
    });
  }

  private updateHints(valid: boolean): void {
    if(!this.#hintRef) {
        this.#hintRef = (this.location()?.hintLocationContainerRef ?? this.#viewContainerRef).createComponent(FormHintComponent);
    }

    if(valid) {
      this.#hintRef.setInput("hints", []);
    } else {
      const hints = this.evaluateCurrentHints();
      this.#hintRef.setInput("hints", hints);
    }
  } 

  private evaluateCurrentHints(): string[] {
    const errors = this.#formControl?.errors
    if(!errors) {
      return [];
    }

    return Object.keys(errors).map(ek => {
      const messageTemplate = VALIDATION_HINTS[ek];
      const params = errors[ek];
      return messageTemplate ? this.replaceParamPlaceholder(messageTemplate, params) : `Bitte überprüfen Sie ihre Eingaben. Unbekannter Fehler: ${ek}`;      
    });

  }

  private replaceParamPlaceholder(template: string, params?: {[key: string]: any}): string {
    return template.replace(/\{(\w+)\}/g, (_, key) => params ? (params[key] ?? '') : '');
  }
}

Die Directive greift via Injection auf das Form Control zu und reagiert auf Status- und Value-Änderungen. Hierbei greift Sie auf die Errors des Controls zu und nutzt die Namen der Errors um die Fehlertexte (in VALIDATION_HINTS definiert, können später erweitert oder von Außen definiert werden, je nachdem was die individuellen Anforderungen verlangen) zu identifizieren. Sollten die Fehlertexte Platzhalter enthalten, werden diese mit den Werten aus den Error-Details ersetzt, sofern diese Dort vorhanden sind.

Beispiel:

Das Passwort muss 6-32 Zeichen lang sein. Die Eingabe "Pa55W" führt zum folgenden Validierungsfehler:

{
  "minlength": {
    "requiredLength": 6,
    "actualLength": 1
  }
}

Die Information der requiredLength wird somit aus dem Error-Object in den Text eingesetzt.

Nutzung der Directiven

Folgend nutzen wir die implementierten Directives im Login Formular, um die Validierungen der Formulare sichtbar zu machen.

Anzeige direkt am FormControl

Um die Validierungshinweise direkt an einem FormControl anzuzeigen, muss diese nur an dem FormControl angebracht werden. Folgend am Beispiel der E-Mail im Login-Formular:

login-form.component.html

<!-- ... -->
<input appFormAutoValidationHint id="email" name="email" type="email" formControlName="email" autocomplete="email" required class="block w-full rounded-md border-0 py-1.5 text-gray-900 shadow-sm ring-1 ring-inset ring-gray-300 placeholder:text-gray-400 focus:ring-2 focus:ring-inset focus:ring-indigo-600 sm:text-sm/6">
<!-- ... -->

Anzeige an beliebiger Stelle

Um die Validierungshinweise an anderer Stelle anzuzeigen, müssen wir der FormAutoValidationHintDirective sagen, an welcher Stelle der Hinweis angezeigt werden soll. Hierzu nutzen wir die FormAutoValidationHintLocationDirective und weißen die Referenz auf diese der FormAutoValidationHintDirective zu. Folgend am Beispiel des Passworts im Login-Formular:

login-form.component.html

<!-- ... -->
      <div>
        <div class="flex items-center justify-between">
          <label for="password" class="block text-sm/6 font-medium text-gray-900">Password</label>
        </div>
        <div class="mt-2">
          <input appFormAutoValidationHint [location]="loc" type="password" name="password" type="password" formControlName="password" autocomplete="current-password" required class="block w-full rounded-md border-0 py-1.5 text-gray-900 shadow-sm ring-1 ring-inset ring-gray-300 placeholder:text-gray-400 focus:ring-2 focus:ring-inset focus:ring-indigo-600 sm:text-sm/6">
        </div>
      </div>

      <div appFormAutoValidationHintLocation #loc="hintLocation">
        <button type="submit" class="flex w-full justify-center rounded-md bg-indigo-600 px-3 py-1.5 text-sm/6 font-semibold text-white shadow-sm enabled:hover:bg-indigo-500 enabled:focus-visible:outline enabled:focus-visible:outline-2 enabled:focus-visible:outline-offset-2 enabled:focus-visible:outline-indigo-600 disabled:opacity-75" [disabled]="form.invalid">Sign in</button>
      </div>

<!-- ... -->

Die Validierungshinweise des Passworts werden nun unterhalb des Buttons angezeigt.

Halbautomatisch auf bestehende Formulare applizieren

Wenn Ihre Applikation bereits über Formulare verfügt, die noch keine Hinweise enthält, Sie diese aber konsistent und einfach verteilen möchten, können Sie das relativ einfach erreichen. Hierzu müssen wir die FormAutoValidationHintDirective um zwei Selector erweitern.

form-auto-validation-hint.directive.ts

@Directive({
  selector: '[appFormAutoValidationHint], [formControl], [formControlName]',
  standalone: true
})

Durch die Selektoren formControl und formControlName wird die Directive automatisch überall dort angewandt, wo FormControls via Reactive Forms genutzt werden. Die Directive muss nun nur in den einzelnen Components oder der Globalen Configuration als Provider angegeben werden. Nun werden die Hinweise in jedem Formular angezeigt. Ggf. muss Ihr Styling jedoch noch angepasst werden.

Fazit

Mit dieser Anpassung werden Validierungsfehler direkt am jeweiligen Eingabeelement angezeigt, ohne dass zusätzlicher Template-Code notwendig ist. Der Ansatz kombiniert die Stärken von Angular-Direktiven und Reactive Forms, um sowohl Entwicklerfreundlichkeit als auch Wartbarkeit zu maximieren.

Probieren Sie es aus und passen Sie die Logik bei Bedarf an Ihre spezifischen Anforderungen an!

Brauchen Sie Unterstützung? Kommen Sie gerne auf mich zu!

DEV Community: Fabian - angular-freelancer.de

QDA in der Praxis: Wie Du mit Quality-Driven Architecture robuste Angular-Anwendungen entwickelst

Was heißt „qualitätsgetrieben“? Eine Analogie

Ein wichtiger Werkzeugkoffer: Die Qualitätsziele von arc42

1. Laufzeitqualität: Was der Benutzer erlebt

2. Entwicklungsqualität: Unser Alltag als Entwickler

3. Betriebsqualität: Die Anwendung im Live-Betrieb

Fazit

Angular & ESBuild: Dein Weg zum perfekten Tree Shaking 🌳🚀

Was ist Tree Shaking überhaupt?

Das Problem: Zu viel Code im Bundle

Angular 17 und ESBuild: Die Traumhochzeit für Tree Shaking

Wie funktioniert Tree Shaking (unter der Haube)

Unser Beispiel in Aktion

Tipps, um Tree Shaking aktiv zu verbessern

Fazit

🚀 Angular v20 ist da 🚀

Angular & Facades: So entkoppelst du deine Components und machst deinen Code wartbarer

Was sind Facades (in Angular)?

Best Practices bei der Verwendung von Facades

Vorteile von Facades

Nachteile von Facades

Fazit

Für jeden, der sich in letzter Zeit weniger mit den fundamentalen Änderungen in Angular auseinandergesetzt hat oder neu im Angular-Kosmos unterwegs ist

Angular 17+ Control Flow: Bye Bye `*ngIf`& `*ngFor`- Hallo `@if`& `@for

Angular 17+ Control Flow: Bye Bye `*ngIf`& `*ngFor`- Hallo `@if`& `@for

Warum ein neuer Control Flow?

Im Detail: @if, @else if, @else

Im Detail @for und @empty

Im Detail: @switch, @case und @default

Vorteile zusammengefasst:

Migration

Fazit

Angular 19: Die neue ResourceAPI

Was ist neu?

Was versprechen wir uns davon?

Wie nutzt man die API?

Fazit

Weitere Ressourcen

Angular Reactive Forms: Automatische Validation-Hints

Setup

Das Login-Formular

Implementierung der FormValidationHintComponent

Implementierung der Directives

FormAutoValidationHintLocationDirective

FormAutoValidationHintDirective

Nutzung der Directiven

Anzeige direkt am FormControl

Anzeige an beliebiger Stelle

Halbautomatisch auf bestehende Formulare applizieren

Fazit

Angular 17+ Control Flow: Bye Bye `ngIf`& `ngFor`- Hallo `@if`& `@for

Angular 17+ Control Flow: Bye Bye `ngIf`& `ngFor`- Hallo `@if`& `@for

Im Detail: `@if`, `@else if`, `@else`

Im Detail `@for` und `@empty`

Im Detail: `@switch`, `@case` und `@default`