Expression has changed after it was checked: So besiegen Sie den Fehler in Angular

„Expression has changed after it was checked“ – warum passiert das und wie lebt man damit?

Wenn Sie jemals eine Anwendung mit Angular geschrieben haben, sind Sie sicherlich auf diese unheilvolle Meldung in der Konsole gestoßen:

ERROR Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'false'. Current value: 'true'.

Dieser Fehler ist eine wahre „Geißel“ für Entwickler. Tausende Fragen auf Stack Overflow, hunderte Stunden Debugging, dutzende Nervenzusammenbrüche. Aber die gute Nachricht: Man kann ihn nicht nur beheben, sondern auch verstehen, warum er auftritt. In diesem Artikel analysieren wir die Top-Ursachen des Fehlers Expression has changed after it was checked, schreiben Beispiele in TypeScript und geben konkrete Lösungen. Los geht‘s!

Was bedeutet dieser Fehler überhaupt?

Angular arbeitet in zwei Modi: Entwicklung (dev mode) und Produktion. Im Dev-Modus führt das Framework eine zusätzliche Prüfung durch – nach jedem Change-Detection-Zyklus startet es einen zweiten Durchlauf, um sicherzustellen, dass sich die Daten nicht „im laufenden Betrieb“ geändert haben. Wenn sich der Wert zwischen dem ersten und zweiten Durchlauf ändert, bricht Angular mit dem Fehler ExpressionChangedAfterItHasBeenCheckedError ab.

Einfach ausgedrückt: Sie haben Angular gesagt „das sind die Daten“, es hat sie überprüft, und dann haben Sie sie geändert. Angular ist beleidigt und schreit.

Top 3 Ursachen des Fehlers

1. Datenänderung in Lebenszyklus-Hooks nach ngAfterViewInit

Die häufigste Ursache ist der Versuch, eine Eigenschaft einer Komponente im Hook ngAfterViewInit, ngAfterContentInit oder ngAfterViewChecked zu ändern. In diesem Moment hat Angular die Überprüfung der Ansicht bereits abgeschlossen, und jede Änderung verursacht den Fehler.

Beispiel in TypeScript:

import { Component, AfterViewInit } from '@angular/core';\n\n@Component({\n  selector: 'app-example',\n  template: '<p>{{ message }}</p>'\n})\nexport class ExampleComponent implements AfterViewInit {\n  message = 'Anfangswert';\n\n  ngAfterViewInit(): void {\n    // Fehler! Eigenschaft nach der Ansichtsprüfung ändern\n    this.message = 'Geänderter Wert';\n  }\n}

Hier überprüft Angular zuerst message (Wert „Anfangswert“), ruft dann ngAfterViewInit auf, wo Sie ihn auf „Geänderter Wert“ ändern. Bei der erneuten Überprüfung sieht Angular die Abweichung und wirft den Fehler.

2. Asynchrone Operationen innerhalb des Lebenszyklus

Wenn Sie asynchronen Code (setTimeout, Promise, Observable) innerhalb eines Hooks ausführen, erfolgt die Datenaktualisierung außerhalb des Kontrollbereichs von Angular.

Beispiel:

import { Component, OnInit } from '@angular/core';\n\n@Component({\n  selector: 'app-async',\n  template: '<p>{{ data }}</p>'\n})\nexport class AsyncComponent implements OnInit {\n  data = 'Start';\n\n  ngOnInit(): void {\n    setTimeout(() => {\n      this.data = 'Neuer Wert';\n    }, 0);\n  }\n}

Obwohl setTimeout mit einer Verzögerung von 0 ms fast sofort ausgeführt wird, hat Angular die Überprüfung bereits abgeschlossen. Im Dev-Modus führt dies zum Fehler.

3. Verschachtelte Komponenten und Datenübergabe über Input

Wenn die Elternkomponente Daten über @Input an die Kindkomponente übergibt und die Kindkomponente versucht, diese Daten in ihrem eigenen Lebenszyklus zu ändern, entsteht ein Konflikt.

Beispiel:

// Elternkomponente\n@Component({\n  selector: 'app-parent',\n  template: '<app-child [value]="parentValue"></app-child>'\n})\nexport class ParentComponent {\n  parentValue = 'Ursprünglich';\n}\n\n// Kindkomponente\n@Component({\n  selector: 'app-child',\n  template: '<p>{{ value }}</p>'\n})\nexport class ChildComponent implements AfterViewInit {\n  @Input() value: string = '';\n\n  ngAfterViewInit(): void {\n    this.value = 'Geändert in der