Formulare: Signal Forms und Reactive Forms

Signal Forms und Reactive Forms

0:00 Zwei Formularmodelle nebeneinander — das klingt nach einem Versäumnis und ist in Wahrheit ein Übergang. Die Frage ist nur, wie lange er dauern soll. Signal Forms sind seit Angular 22 stabil und die Empfehlung für Neues. Reactive Forms bleiben unterstützt und laufen in Tausenden von Anwendungen. In diesem Modul bauen wir ein Formular mit dem neuen Modell — und entscheiden für ein bestehendes, ob und wann es migriert wird. Die zweite Aufgabe ist die schwerere.

Navigation, Daten und Formulare

0:28 Das ist das letzte Modul des dritten Tages. Navigation und Daten stehen, jetzt kommt der Teil, an dem der Benutzer selbst etwas eingibt — und damit auch der Teil, an dem fachliche Regeln zum ersten Mal wirklich sichtbar werden.

Signal Forms — Modell und Feldzustand

0:42 Fangen wir mit dem neuen Modell an. Der Gedanke dahinter ist derselbe wie bei Signals überhaupt: Nicht der Zustand folgt der Oberfläche, sondern die Oberfläche dem Zustand. Der Ausgangspunkt ist ein Signal mit Ihren Daten — ein gewöhnliches Objekt, keine spezielle Struktur. Daraus entsteht ein Formular, und eine Direktive bindet einzelne Felder an Eingabeelemente. Modell und Oberfläche bleiben selbsttätig synchron.

1:07 Jedes Feld führt seine Zustände als Signals: berührt, geändert, ungültig, mit seinen Fehlern. Der Unterschied zum bisherigen Modell ist grundsätzlich: Dort haben Sie einen Steuerbaum gebaut und die Werte daraus gelesen. Hier haben Sie Ihre Daten, und das Formular hängt sich daran. Zwei Teile, und der zweite ist der ungewohnte. Oben das Modell — ein ganz normales Signal mit einem Objekt. Unten die Schema-Funktion, die die Regeln je Feldpfad beschreibt.

1:36 Diese Funktion läuft beim Anlegen des Formulars, nicht bei jeder Änderung. Worauf es ankommt: Es gibt keine zweite Datenhaltung. Bei Reactive Forms hatten Sie das Modell und den Steuerbaum, und zwischen beiden musste synchronisiert werden. Hier ist das Modell das Formular, und die Regeln stehen daneben statt darin. Drei Zeilen, und die mittlere ist die wichtigste. Die Bindung selbst ist unspektakulär.

2:02 Aber die Bedingung darunter prüft zwei Dinge: ob das Feld berührt wurde und ob es ungültig ist. Beides zusammen. Ohne die erste Hälfte steht die Meldung „Kennzeichen fehlt" schon da, wenn der Benutzer das Formular gerade erst geöffnet hat — er hat nichts falsch gemacht und wird trotzdem korrigiert. Das ist einer der Punkte, an denen ein Formular unhöflich wirkt, ohne dass jemand sagen könnte, warum.

2:26 Der erste Punkt ist der, den man aus der alten Welt mitbringt: Das Modell wird an zwei Stellen geführt — einmal als Signal, einmal als Kopie im Formular. Dann laufen sie auseinander, und man baut eine Synchronisierung, die es nicht bräuchte. Der zweite ist der eben besprochene: Die Fehlermeldung erscheint sofort, bevor das Feld berührt wurde.

2:45 Und der dritte ist ein Missverständnis über die Schema-Funktion: Sie wird bei jeder Änderung neu erwartet, läuft aber nur einmal beim Anlegen.

Validierung und fachliche Regeln

2:54 Jetzt zum Teil, der in jedem Formular die eigentliche Arbeit macht. Feldprüfung ist einfach — die fachliche Regel über mehrere Felder ist es nicht. Eingebaut sind die üblichen Verdächtigen: Pflichtfeld, E-Mail, Zahlenbereiche, Längen, Muster. Interessanter wird es bei eigenen Regeln: Die geben bei einem Verstoß ein Objekt mit einer Art und einer Meldung zurück.

3:17 Für Regeln über mehrere Felder gibt es eine eigene Variante, und für serverseitige Prüfungen eine, die eine Anfrage stellt — mit einem Signal, das anzeigt, dass gerade geprüft wird. Letzteres ist wichtiger, als es klingt: Eine Prüfung ohne sichtbaren Zwischenzustand wirkt wie eine hängende Oberfläche. Das ist die Regel, um die sich unsere Übung dreht: Wer einen Auftrag als dringend markiert, muss begründen, warum.

3:42 Worauf es ankommt, ist der Zugriff auf ein anderes Feld — die Regel hängt an der Notiz, liest aber die Dringlichkeit. Und beachten Sie die Rückgabe: eine Art und eine Meldung, nicht einfach „falsch". Die Art brauchen Sie, wenn Sie später unterscheiden wollen, die Meldung sieht der Benutzer. In der Fußzeile steht der zweite wichtige Punkt: Serverseitige Befunde gehören ebenfalls ans Feld, nicht in eine Sammelbox.

4:07 Vier Punkte, und sie klingen banal, bis man ein Formular benutzt, das sie verletzt. Sie steht am Feld, nicht am Seitenkopf — sonst sucht der Benutzer. Sie sagt, was zu tun ist, nicht nur, was falsch ist: „Bitte begründen, warum der Auftrag dringend ist" statt „Ungültige Eingabe". Sie erscheint, wenn das Feld berührt wurde.

4:26 Und sie ist über eine passende Rolle auch ohne Blick auffindbar — was für Benutzer mit Screenreader den Unterschied zwischen benutzbar und unbenutzbar ausmacht. Darauf kommen wir in Modul fünfzehn zurück. Der erste Punkt ist der, den wir in der Übung ausdrücklich vermeiden: Fachliche Regeln werden im Speichern geprüft statt im Formular.

4:47 Dann füllt der Benutzer alles aus, klickt, und erfährt erst dann, dass es so nicht geht. Der zweite: Ein Serverbefund landet in einer Box statt am verursachenden Feld — und der Benutzer muss raten, welches gemeint ist. Und der dritte ist der, der eine Oberfläche kaputt aussehen lässt: Die asynchrone Prüfung läuft ohne sichtbaren Zwischenzustand.

Reactive Forms im Bestand

5:07 Kommen wir zum Bestand. Und ich möchte gleich klarstellen: Reactive Forms sind kein Altlastenthema. Sie sind für bestehende Anwendungen weiterhin eine gute Wahl. Reactive Forms bleiben unterstützt. Die Angular-Dokumentation empfiehlt Signal Forms vor allem für neue, signalbasierte Anwendungen — das ist eine bewusste Einschränkung und keine Höflichkeit.

5:29 Beide Modelle dürfen in einer Anwendung nebeneinander bestehen. Sinnvollerweise getrennt nach Formular: Dieses Formular nutzt das eine, jenes das andere. Nicht innerhalb eines Formulars. Die Mischung in einem Formular ist die Variante, bei der es unübersichtlich wird und niemand mehr sagen kann, wo der Zustand eigentlich liegt.

5:49 Die interessanteste Zeile ist die dritte: Validatoren am Steuerelement gegen Regeln im Schema. Das ist der strukturelle Unterschied. Bei Reactive Forms gehört die Regel zum Feld und wandert mit ihm. Bei Signal Forms stehen alle Regeln an einer Stelle beieinander — man liest sie wie eine Spezifikation. Bei einem Formular mit drei Feldern ist das egal. Bei einem mit fünfzehn und feldübergreifenden Abhängigkeiten ist es der Unterschied zwischen nachvollziehbar und nicht.

6:17 Der erste Punkt ist die Grenze, die ich eben gezogen habe: Beide Modelle werden innerhalb eines Formulars gemischt. Der zweite ist der, der Zeit ohne Gegenwert verbrennt: Ein bestehendes Formular wird ohne Anlass migriert, weil das neue Modell schöner ist. Und der dritte ist ein technischer, der bei der Umstellung auf zoneless auffällt und den wir in Modul sechs schon gesehen haben: Der Zustand eines Reactive Form meldet sich nicht von selbst.

6:42 Die Ansicht bleibt stehen, und die Ursache sitzt tiefer, als man zuerst denkt.

Auswahl und Migrationsweg

6:47 Damit zur eigentlichen Frage dieses Kapitels: Wann migriert man, und wann lässt man es? Neue Formulare entstehen mit Signal Forms — das ist unstrittig. Für bestehende schlage ich eine Regel vor, die sich in Projekten bewährt: migrieren, wenn sie ohnehin fachlich angefasst werden. Nicht als eigenes Projekt. Die Kriterien sind die Häufigkeit der Änderung, die Komplexität der Regeln und die Frage, ob das umgebende Feature bereits auf Signals steht.

7:14 Ein Formular, das seit zwei Jahren niemand angefasst hat, bringt Ihnen durch die Migration genau nichts — außer Risiko. Fünf Schritte, und der letzte ist der, der die Sache rettet: die Entscheidung je Formular notieren, nicht pauschal fällen. Die ersten drei sammeln Fakten — wie oft geändert, wie viele Regeln, wie ist die Umgebung.

7:34 Der vierte hat drei Ausgänge, und der mittlere ist der wichtigste: „bei nächster Änderung migrieren". Das ist die Antwort, die am häufigsten richtig ist und die man selten aufschreibt, weil sie nach Aufschieben klingt. Sie ist aber etwas anderes — sie bindet die Migration an einen Anlass. Der erste Punkt ist der, den ich in mehreren Projekten gesehen habe: Die Migration wird als eigenes Projekt geplant und nie fertig.

7:59 Sie bekommt einen Namen, ein Ticket, einen Fortschrittsbalken — und wird nach vierzig Prozent von der nächsten Priorität überholt. Der zweite ist eine falsche Reihenfolge: Ein selten geändertes Formular wird zuerst migriert, weil es einfach aussieht. Es bringt nur nichts. Und der dritte: Die Entscheidung wird pauschal getroffen und passt dann nirgends richtig.

Übung

8:20 Zwei Aufgaben in einer: ein Formular bauen und eine Migrationsentscheidung treffen. Die zweite dauert zehn Minuten und ist die anspruchsvollere. Die Bearbeitung eines Auftrags erfasst Kennzeichen, Standort, Dringlichkeit und Notiz. Fachlich gilt: Ein als dringend markierter Auftrag braucht eine Begründung. Das ist eine echte Regel bei Falkenhorst — sie entstand, weil irgendwann jeder zweite Auftrag als dringend markiert war und die Werkstatt die Priorisierung aufgegeben hat.

8:49 Daneben liegt im Bestand ein Reactive Form für die Ersatzteilbestellung, das Sie bewerten sollen. Das Lernziel nennt beide Teile: zwischen Feldvalidierung und fachlicher Regel unterscheiden, und eine Modellwahl für ein Bestandsformular begründen. Das Erfolgskriterium ist entsprechend zweiteilig — das Formular verhindert das Speichern und meldet den Grund am Feld, und für das Altformular liegt eine begründete Entscheidung vor.

9:14 Begründet heißt: mit einem Anlass, nicht mit einer Vorliebe. Wer früh fertig ist, ergänzt eine serverseitige Prüfung des Kennzeichens mit sichtbarem Zwischenzustand. Die ersten beiden Schritte sind schnell erledigt. Schritt drei ist der fachliche Kern: die Regel über Dringlichkeit und Notiz. Schritt vier ist der, an dem sich die Qualität entscheidet — Fehlermeldungen am Feld, erst nach Berührung. Und Schritt fünf ist die Bewertung des Altformulars.

9:40 Nehmen Sie sich die wirklich vor, auch wenn das Formular vorher fertig ist. Die Fähigkeit, eine Migration zu begründen oder begründet zu unterlassen, brauchen Sie in Ihrem eigenen Projekt häufiger als die, ein Formular zu bauen. Der erste Punkt ist der, den wir ausdrücklich vermeiden wollten: Die fachliche Regel landet im Speichern statt im Formular.

10:01 Der zweite ist der Umgangston: Die Meldung erscheint beim Öffnen, weil die Berührung nicht geprüft wird. Und der dritte betrifft die Bewertung: Sie endet in „migrieren", ohne einen Anlass zu nennen — und damit ist es keine Entscheidung, sondern ein Wunsch. Damit endet der dritte Tag. Morgen geht es um Qualität: Tests, Barrierefreiheit und die Frage, was eigentlich geprüft werden muss.