React v19 - Form Handling

React v19+ — Form Handling

0:00 Formulare sind das ungeliebte Brot-und-Butter-Geschäft der Frontend-Entwicklung. Kaum jemand baut sie gern, aber fast jede Anwendung braucht sie — Anmeldung, Bestellung, Profil bearbeiten. Und man merkt sofort, ob sich jemand Mühe gegeben hat: Ein gutes Formular fühlt sich leicht an, sagt früh, was fehlt, und verliert keine Eingaben.

0:19 Die Arbeit dahinter steckt in zwei Dingen, die man von außen nicht sieht — Validierung und Zustandsverwaltung. Heute schauen wir uns an, wie React Hook Form beides deutlich angenehmer macht, als es mit Bordmitteln wäre.

Formulare mit React Hook Form

0:32 Der rote Faden führt vom ersten angebundenen Feld bis zum fertigen Bearbeiten-Formular. Zuerst die Grundlagen: Wie kommt ein Eingabefeld überhaupt in die Bibliothek hinein, und was passiert beim Absenden? Dann die Validierung — Regeln definieren, Fehler anzeigen, den richtigen Zeitpunkt wählen. Und zum Schluss der Fall, der in der Praxis am häufigsten Ärger macht: ein Formular mit bestehenden Daten füllen, die erst nachträglich eintreffen.

0:58 Drei Kapitel, jedes mit einer Übung. Kurz zu Ihnen, bevor wir loslegen. Beim Thema Formulare gibt es zwei Lager: die einen bauen alles selbst mit einem `useState` je Feld, die anderen greifen zu einer Bibliothek. Beides ist verbreitet, und beides hat seine Momente. Die zweite Frage zielt auf die typischen Schmerzpunkte — Validierungsregeln, die über die halbe Komponente verteilt sind, oder ein großes Formular, das bei jedem Tastendruck spürbar träge wird.

1:26 Wer das kennt, weiß, warum es dieses Kapitel gibt. Und sagen Sie mir gern, was heute konkret hängenbleiben soll.

React Hook Form — Integration

1:33 Fangen wir mit der Anbindung an. React Hook Form geht einen Weg, der sich von dem unterscheidet, was man aus React-Tutorials kennt — und genau daraus zieht die Bibliothek ihren Vorteil. Schauen wir uns an, was dahintersteckt. Der übliche React-Weg ist controlled: Jeder Tastendruck aktualisiert den State, jeder State-Wechsel rendert neu. Bei zwanzig Feldern und einem längeren Text merkt man das.

1:57 React Hook Form dreht das um und arbeitet überwiegend uncontrolled — die Eingabefelder verwalten ihre Werte selbst im Browser, so wie klassisches HTML es immer getan hat. Die Bibliothek merkt sich nur, wo die Felder sind, und liest die Werte erst beim Absenden ein. Wie ein Kellner, der nicht nach jedem Satz zur Küche läuft, sondern die ganze Bestellung aufnimmt und dann geht. Weniger Wege, dasselbe Ergebnis.

2:20 Der Performance-Punkt ist der bekannteste, aber ich halte ihn nicht für den wichtigsten. Interessanter ist, wie viel Code wegfällt. Ein controlled Formular mit zehn Feldern bedeutet zehn State-Zeilen und zehn Änderungshandler — das ist viel Zeremoniell für wenig Inhalt. Hier bleibt eine Zeile je Feld. Dazu kommt, dass Validierung und Fehlerzustände schon mitgeliefert sind; Sie müssen sich nicht überlegen, wo Fehlermeldungen leben und wann sie zurückgesetzt werden.

2:47 Und `handleSubmit` bündelt zwei Dinge, die ohnehin zusammengehören: erst prüfen, dann absenden. Fällt die Prüfung durch, kommt Ihr Code gar nicht erst dran. Fünf Schritte, und die Hälfte davon ist Installation und Aufruf. Sie holen sich aus `useForm` zwei Werkzeuge — `register` zum Anbinden der Felder und `handleSubmit` fürs Absenden.

3:07 Jedes Eingabefeld bekommt dann die Rückgabe von `register` mit einem Namen, und dieser Name ist zugleich der Schlüssel, unter dem der Wert später auftaucht. Das Formular-Element selbst bekommt `handleSubmit` mit Ihrer eigenen Funktion darin. Und in dieser Funktion liegt dann ein fertiges Objekt mit allen Werten. Kein Einsammeln, kein Auslesen aus dem Event — das ist bereits erledigt.

3:30 Zehn Zeilen, ein vollständiges Formular — und keine einzige Zeile State. Achten Sie auf die drei Punkte vor `register`, den Spread-Operator. Die Funktion gibt nämlich mehrere Eigenschaften auf einmal zurück, unter anderem eine Referenz auf das DOM-Element, und die müssen alle ans Input weitergereicht werden. Der Name in den Klammern ist Ihr Schlüssel: Genau unter diesem Namen finden Sie den Wert später im Datenobjekt wieder.

3:55 Und in `onSubmit` steht dann alles gesammelt bereit, geprüft und fertig. Vergleichen Sie das gedanklich mit der controlled Variante — dort bräuchten Sie für dasselbe gut die doppelte Zeilenzahl. Jetzt bauen Sie das selbst. Das Lernziel ist die Verdrahtung — `register` für die Felder, `handleSubmit` fürs Absenden. Das Erfolgskriterium ist angenehm konkret: Beim Abschicken liegen alle Feldwerte gesammelt in einem Objekt vor, und Sie können es einfach ausgeben.

4:22 Schauen Sie sich dieses Objekt genau an, dann verstehen Sie sofort, was der Name in `register` bewirkt. Als Erweiterung ergänzen Sie ein zweites Feld — und werden feststellen, dass es genau eine zusätzliche Zeile kostet. Genau diese Skalierbarkeit ist der Punkt der Bibliothek. Die ersten beiden Punkte führen zum selben verwirrenden Ergebnis: Das Feld sieht normal aus, funktioniert im Browser, aber der Wert fehlt im Datenobjekt.

4:48 Entweder wurde `register` gar nicht aufgerufen oder die Rückgabe nicht gespreadet — die drei Punkte sind leicht zu übersehen. Ohne `handleSubmit` greift das Standardverhalten des Browsers, und die Seite lädt komplett neu; Ihre Anwendung startet von vorn. Und der letzte Punkt ist der konzeptionelle: Wer zusätzlich noch eigenen State je Feld pflegt, hat zwei Wahrheiten für denselben Wert. Die laufen früher oder später auseinander.

Validierung in React-Formularen

5:12 Ein Formular, das jede Eingabe klaglos annimmt, ist nur die halbe Miete. Jetzt geht es darum, falsche Eingaben früh abzufangen und dem Nutzer verständlich zu sagen, was fehlt. Und um die Frage, wo diese Regeln am besten leben. Validierung ist die Türsteher-Funktion Ihres Formulars: Sie prüft, bevor weitergereicht wird. In React Hook Form haben Sie dafür zwei Wege.

5:35 Der eine schreibt die Regeln direkt zum Feld, in den Aufruf von `register` — das ist schnell und für einfache Fälle völlig in Ordnung. Der andere legt alle Regeln in ein zentrales Schema, etwa mit Zod, und bindet es über einen Resolver an. Was in beiden Fällen gleich bleibt: Verletzte Regeln landen gesammelt in `formState.errors`, und von dort holen Sie sich die Meldung für die Anzeige.

5:58 Der erste Punkt ist eher Bequemlichkeit als Sicherheit — dazu gleich mehr bei den Stolpersteinen. Wichtiger ist der zweite: Feedback direkt am Feld, im richtigen Moment. Der Unterschied zwischen einer Meldung neben dem Eingabefeld und einer roten Box ganz oben, die alle Fehler auflistet, ist für den Nutzer erheblich. Der dritte Punkt zielt auf Wartbarkeit: Ein Schema bündelt die Regeln an einem Ort, statt sie über zwanzig Felder zu verteilen.

6:24 Und wer TypeScript einsetzt, bekommt aus demselben Schema noch die Typen dazu — eine Quelle, zwei Ergebnisse. Das ist der eigentliche Grund, warum sich Zod so durchgesetzt hat. Die ersten beiden Punkte sind die Alternative, über die Sie entscheiden müssen: Regeln am Feld oder zentral im Schema. Meine Empfehlung — bei zwei, drei Feldern inline, ab da ein Schema, denn dann wird die Verteilung schnell unübersichtlich.

6:49 Die Fehler lesen Sie aus `formState.errors` und zeigen sie unmittelbar beim betroffenen Feld an. Und Punkt fünf ist der, den man leicht übersieht: Der `mode` steuert, wann geprüft wird. Standardmäßig erst beim Absenden, was oft zu spät wirkt. Prüfung beim Verlassen des Feldes ist meist der beste Kompromiss — bei jedem Tastendruck fühlt sich schnell nörgelig an.

7:11 Zwei Neuerungen gegenüber dem ersten Beispiel. Aus `useForm` holen Sie sich zusätzlich die Fehler aus dem `formState`, und in `register` steht jetzt neben dem Namen ein Objekt mit den Regeln — hier die einfachste denkbare, eine Pflichtangabe. Interessant ist die Zeile darunter. Die Fehler sind nach Feldnamen abgelegt, und das logische Und rendert die Meldung nur dann, wenn tatsächlich ein Eintrag existiert.

7:33 Sie müssen sich also nirgends merken, ob ein Fehler noch gilt — die Bibliothek räumt selbst auf, sobald der Nutzer korrigiert. In der Praxis würde statt des festen Textes die Meldung aus dem Fehlerobjekt kommen. In dieser Übung geben Sie einem Feld eine Regel und zeigen die Meldung feldnah an. Das Erfolgskriterium beschreibt beide Richtungen: Leeres Absenden zeigt eine Meldung, eine gültige Eingabe lässt das Formular durch.

7:58 Prüfen Sie unbedingt auch den zweiten Fall — ein Formular, das nie durchlässt, ist ein beliebter Fehler. Achten Sie außerdem darauf, wann die Meldung erscheint und wann sie wieder verschwindet. Als Erweiterung lagern Sie die Regeln in ein Zod-Schema aus und binden es per Resolver an. Das ist der Schritt, den Sie in echten Projekten fast immer gehen werden.

8:19 Der erste Punkt ist der wichtigste dieser Folie, und er gilt unabhängig von jeder Bibliothek: Clientseitige Validierung ist Bedienkomfort, keine Sicherheit. Alles im Browser lässt sich umgehen — das Backend muss dieselben Regeln noch einmal prüfen, verbindlich. Der zweite Punkt ist tückisch in der Praxis: Wenn Sie die Fehler nicht anzeigen, blockiert die Bibliothek das Absenden trotzdem.

8:41 Der Nutzer klickt, und nichts passiert, ohne jede Erklärung. Verstreute Regeln rächen sich beim ersten Ändern. Und ein unpassender Prüfzeitpunkt macht ein technisch korrektes Formular unangenehm — meckernd beim Tippen oder stumm bis zum Schluss.

Vorbefüllte Formulare

8:55 Bisher haben wir Formulare gebaut, die leer starten. Der häufigere Fall in echten Anwendungen ist aber das Bearbeiten: Es gibt schon Daten, und die sollen drinstehen. Klingt einfach — hat aber eine Tücke, die fast jeden einmal erwischt. Beim Bearbeiten eines Datensatzes soll das Formular den bestehenden Stand zeigen. Sind die Werte schon da, geben Sie sie einfach als `defaultValues` mit — fertig.

9:20 Die Tücke liegt im Wort "schon". In der Praxis kommen die Daten nämlich meist aus dem Netz und treffen erst ein, wenn das Formular längst gerendert ist. Und `defaultValues` heißt wörtlich, was es sagt: Startwerte. Sie gelten beim ersten Rendern, danach schaut die Bibliothek nicht mehr hin. Für den Nachschlag gibt es `reset` — es füllt das gesamte Formular neu, sobald die Daten da sind. Diesen Unterschied zu kennen erspart eine frustrierende halbe Stunde.

9:48 Der Nutzen liegt auf der Hand: Wer etwas bearbeitet, will den aktuellen Stand sehen und nicht alles neu eintippen. Interessanter ist der Weg dorthin. `defaultValues` und `reset` arbeiten auf dem ganzen Formular — ein Aufruf, alle Felder. Die Alternative wäre, jeden Wert einzeln per `setValue` zu setzen, und das ist nicht nur mehr Code, sondern auch fehleranfälliger: Ein vergessenes Feld fällt niemandem auf, bis ein Nutzer sich wundert, warum seine Telefonnummer verschwunden ist.

10:15 Und `reset` kann noch mehr, als nur zu füllen — es setzt auch den Zustand des Formulars zurück, also etwa die Markierung, dass etwas geändert wurde. Der Ablauf hängt daran, wann die Daten verfügbar sind. Was Sie schon beim Rendern wissen, geben Sie als `defaultValues` mit. Was später kommt, übergeben Sie an `reset`, sobald es da ist — typischerweise in einem Effekt, dessen Abhängigkeit genau diese Daten sind.

10:40 Punkt vier ist eine elegante Alternative, die viele nicht kennen: die `values`-Eigenschaft. Sie hält das Formular fortlaufend synchron, ohne dass Sie selbst einen Effekt schreiben. Und Punkt fünf ist der Abschluss, den man gern vergisst — nach erfolgreichem Speichern ein `reset` auf den neuen Stand. Sonst gilt das Formular weiterhin als ungespeichert geändert.

11:01 Hier stehen beide Wege direkt untereinander. Oben die Startwerte für den Moment, in dem noch nichts geladen ist — wichtig, damit die Felder nicht als undefined starten. Und unten der Effekt, der zuschlägt, sobald die Daten eintreffen: Wenn ein Nutzer da ist, fülle das Formular damit. Achten Sie auf zwei Details. Die Prüfung davor ist nötig, sonst würden Sie beim ersten Durchlauf mit leeren Daten zurücksetzen.

11:26 Und im Abhängigkeitsarray stehen beide verwendeten Werte — die Daten und `reset` selbst. Das ist genau die Regel aus dem Hooks-Kapitel, hier in ihrer nützlichsten Form. Diese Übung ist die praxisnächste des Tages, denn so sieht das echte Leben aus. Das Lernziel ist, ein Formular mit vorhandenen Daten korrekt zu füllen — ausdrücklich auch mit welchen, die asynchron eintreffen.

11:48 Der Erfolg: Nach dem Laden zeigen die Felder die bestehenden Werte und lassen sich ganz normal ändern. Bauen Sie ruhig eine künstliche Verzögerung ein, damit Sie den Ablauf beobachten können. Als Erweiterung bringen Sie das Formular nach dem Speichern per `reset` auf den neuen Stand — der Schritt aus dem Vorgehen, der in der Praxis am häufigsten fehlt.

12:09 Die ersten beiden Punkte hängen zusammen und sind die eigentliche Falle dieses Kapitels: `defaultValues` gelten nur beim ersten Rendern. Wer die Daten später hineinreicht und sich wundert, dass nichts passiert, sucht oft lange am falschen Ende — die Lösung heißt `reset`. Werte einzeln per `setValue` zu setzen funktioniert zwar, ist aber unnötig fehleranfällig.

12:29 Der dritte Punkt ist subtil: Ein `value` am Input macht das Feld controlled und hebelt damit den ganzen Ansatz der Bibliothek aus. Und eine vergessene Abhängigkeit im Effekt bedeutet schlicht, dass der Reset nie ausgelöst wird — das Formular bleibt leer. Ziehen wir die Linie. Felder werden uncontrolled per `register` angebunden, und `handleSubmit` bündelt Prüfen und Absenden — das spart Zeilen und Renderläufe zugleich.

12:54 Validierung läuft entweder inline am Feld oder zentral über ein Schema, und die Fehler holen Sie aus `formState.errors`, um sie feldnah anzuzeigen. Vorbefüllen geschieht über `defaultValues`, und sobald Daten asynchron kommen, ist `reset` das Werkzeug der Wahl. Und der Satz, der über allem steht: Was im Browser geprüft wird, ist Bedienkomfort — verbindlich prüft das Backend.

13:16 Vom ersten registrierten Feld bis zum vorbefüllten Bearbeiten-Formular.

Fragen & Weiterarbeiten

13:21 Damit sind wir durch. Alle Beispiele und Formulare liegen in der Freigabe — schauen Sie sich gerade den Fall mit den asynchron geladenen Daten noch einmal in Ruhe an, der begegnet Ihnen in jedem zweiten Projekt. Für alles Weitere ist react-hook-form.com die richtige Adresse, die Dokumentation ist ungewöhnlich gut mit lauffähigen Beispielen.

13:41 Und auf react.dev finden Sie die Gegenrichtung: die nativen Form-Actions von Version 19, die für einfache Fälle ganz ohne Bibliothek auskommen — einen Blick wert, bevor Sie beim nächsten Mal automatisch installieren. Bei Fragen erreichen Sie uns unter der Adresse auf der Folie. Vielen Dank.