React v19 - TanStack Form

React v19+ — TanStack Form

0:00 Formulare sind die undankbarste Disziplin der Oberflächenentwicklung. Sie sehen simpel aus — ein paar Felder, eine Schaltfläche — und enthalten in Wahrheit die gesamte Komplexität einer Anwendung im Kleinen: Zustände, Prüfregeln, Serverkommunikation, Fehlerbehandlung. Deshalb gibt es dafür seit Jahren Bibliotheken, und deshalb ist keine davon unumstritten.

0:20 Was TanStack Form auszeichnet, ist ein Versprechen, das man erst schätzt, wenn man das Gegenteil erlebt hat: Vom Feldnamen über den Wert bis zur Fehlermeldung ist alles typisiert verbunden — ohne dass Sie einen einzigen Typparameter von Hand schreiben.

Typsichere Formulare mit TanStack Form

0:35 Der Weg führt vom ersten angebundenen Feld bis zu einem Formular, das man guten Gewissens in Produktion nehmen würde. Dazwischen liegen die vier Themen, an denen Formulare in der Praxis kranken: Prüfregeln, die zu spät oder zu oft laufen; Oberflächen, die bei jedem Tastendruck komplett neu zeichnen; endlos wiederholter Code für jedes Feld; und Serverfehler, die irgendwo als Hinweisfenster landen statt an dem Feld, um das es geht.

0:59 Die mittlere Frage trifft die beiden Schmerzpunkte, um die es heute geht. Wer mit einer älteren Bibliothek gearbeitet hat, kennt vermutlich mindestens einen davon: entweder das mühsame Nachziehen von Typen, damit der Editor bei Feldnamen nicht im Dunkeln tappt — oder das Formular mit dreißig Feldern, das bei jedem Buchstaben spürbar zäh wird.

1:18 Sagen Sie ruhig, welche Bibliothek bei Ihnen im Einsatz ist; die Vergleiche mache ich dann passend dazu.

Einführung & Grundkonzepte

1:24 Fangen wir mit dem Grundgerüst an. Zwei Dinge muss man verstanden haben: wie ein Formular angelegt wird und wie ein einzelnes Feld daran andockt. Alles Weitere sind Verfeinerungen dieser beiden Bausteine. Der Einstieg ist bewusst schlicht gehalten — er wirkt beim ersten Blick fast zu einfach für das, was später daraus wird.

1:43 Der Trick mit der Typisierung ist elegant und lohnt eine Erklärung. Sie geben beim Anlegen die Startwerte an — eine E-Mail als leerer Text, ein Alter als Null. Daraus weiß TypeScript alles Weitere: welche Feldnamen es gibt, welchen Typ jedes davon hat, was der Absendevorgang bekommt. Sie schreiben also keine Typen, Sie schreiben Beispieldaten, und die Typen entstehen daraus.

2:05 Der praktische Unterschied im Alltag: Ein vertippter Feldname ist keine stille Fehlfunktion mehr, sondern eine rote Unterringelung im Editor. Der dritte Punkt ist der, den man körperlich merkt. In vielen Formularlösungen löst jeder Tastendruck ein Neuzeichnen des gesamten Formulars aus. Bei fünf Feldern ist das egal, bei fünfzig wird das Tippen spürbar zäh — man sieht seinen eigenen Buchstaben verzögert erscheinen.

2:31 Hier ist die Zustandsverwaltung so gebaut, dass nur das Feld betroffen ist, in dem tatsächlich etwas passiert. Nichts davon müssen Sie einstellen; es ist das Grundverhalten. Man merkt es erst, wenn man es vermisst. Fünf Schritte, die zusammen ein lauffähiges Formular ergeben. Der vierte enthält eine Kleinigkeit, die gern untergeht: Neben der Änderungsbehandlung gibt es auch eine für das Verlassen des Feldes.

2:55 Die brauchen Sie für den Zustand "der Nutzer war schon einmal hier". Und genau der entscheidet darüber, ob eine Fehlermeldung angezeigt wird oder nicht — ein leeres Pflichtfeld sollte nicht rot leuchten, bevor jemand es überhaupt gesehen hat. Ohne diese Anbindung bleibt der Zustand für immer auf falsch. Was hier auffällt, ist die Schreibweise mit der Funktion als Inhalt.

3:17 Das Feld sagt Ihnen nicht, wie Ihr Eingabefeld auszusehen hat — es reicht Ihnen den Zustand und die Handgriffe herein, und Sie entscheiden, was Sie damit zeichnen. Das ist der headless Gedanke in seiner reinsten Form. Bemerkenswert ist, was nicht dasteht: kein Typparameter, keine Angabe, was für ein Wert das ist. Der Feldname genügt, weil die Startwerte oben alles Nötige verraten haben.

3:41 Fangen wir klein an. Binden Sie ein Feld an und senden Sie das Formular ab. Machen Sie dabei einen Test, der viel zeigt: Vertippen Sie sich absichtlich beim Feldnamen und schauen Sie, was der Editor sagt. Bei einer nicht typisierten Lösung würden Sie an dieser Stelle ein stummes Feld bekommen, das einfach nie einen Wert hat. Hier bekommen Sie sofort eine Meldung.

4:02 Als Ergänzung dann ein zweites Feld mit Anzeige des Berührt-Zustands — dafür brauchen Sie die Anbindung aus Schritt vier. Der erste Punkt ist der grundlegendste: Ohne Startwerte gibt es nichts, woraus sich Typen ableiten ließen — die ganze Typisierung fällt in sich zusammen und Sie arbeiten wieder mit beliebigen Werten.

4:20 Der letzte Punkt ist der, den ich in Migrationen am häufigsten sehe: Man behält aus Gewohnheit noch eigene Zustandsvariablen nebenher. Damit haben Sie zwei Quellen der Wahrheit, die irgendwann auseinanderlaufen — meist beim Zurücksetzen des Formulars, wo das eine zurückgeht und das andere nicht.

Validierung

4:37 Kommen wir zu den Prüfregeln. Interessant sind hier zwei Fragen: Wann wird geprüft — und woher kommen die Regeln? Bei der zweiten hat sich in den letzten Jahren etwas Erfreuliches getan, das Adapterpakete überflüssig macht. Und wir klären eine Frage, die über die Zufriedenheit Ihrer Nutzer mehr entscheidet als jede Bibliothekswahl: Wann ist eine Fehlermeldung hilfreich und wann bevormundend?

5:00 Der Zeitpunkt der Prüfung ist eine unterschätzte Entscheidung über die Nutzerfreundlichkeit. Prüfen Sie bei jedem Tastendruck, meckert das Formular schon beim dritten Buchstaben einer E-Mail-Adresse — das fühlt sich vorwurfsvoll an. Prüfen Sie erst beim Absenden, erfährt jemand von allen Fehlern auf einmal, nachdem er fertig zu sein glaubte.

5:19 Die bewährte Mischung: beim Verlassen des Feldes zum ersten Mal prüfen, danach bei jeder Änderung. So kommt der Hinweis, wenn er nützlich ist, und die Korrektur wird sofort bestätigt. Der zweite Punkt verdient eine Einordnung, weil er eine echte Vereinfachung ist. Früher brauchte jede Kombination aus Formularbibliothek und Prüfbibliothek ein eigenes Verbindungspaket — mit eigenen Versionen und eigenen Fehlern.

5:43 Inzwischen gibt es dafür eine gemeinsame Schnittstelle, auf die sich die verbreiteten Prüfbibliotheken geeinigt haben. Sie übergeben Ihr Schema einfach direkt. Weniger Abhängigkeiten, weniger Versionsprobleme — und Sie können die Prüfbibliothek wechseln, ohne die Formularseite anzufassen. Schritt vier verdient eine Warnung, weil er ohne Sorgfalt echten Schaden anrichtet.

6:05 Eine Prüfung gegen den Server — etwa ob ein Benutzername noch frei ist — darf nicht bei jedem Tastendruck laufen. Sonst erzeugt ein zwölfstelliger Name zwölf Anfragen, von denen elf sinnlos sind. Mit einer kurzen Wartezeit nach dem letzten Tastendruck wird daraus eine. Und der Wartezustand gehört sichtbar gemacht: Eine Sekunde ohne Rückmeldung wirkt wie ein Fehler, mit einem kleinen Drehsymbol wirkt sie wie Arbeit.

6:30 Kompakter geht es kaum. Sie hängen ein Prüfschema an ein Ereignis, und das war es. Der Gewinn liegt darin, dass die Prüfregel dort steht, wo sie hingehört — neben dem Feld, für das sie gilt. Verschiebt jemand das Feld, wandert die Regel mit. Der Kontrast dazu ist ein zentrales Schema für das ganze Formular, in dem man erst suchen muss.

6:50 Beides ist möglich und beides hat seine Berechtigung; für feldspezifische Regeln ist der kurze Weg der bessere. Diese Übung enthält alle drei Prüfarten in einem realistischen Fall. Bei der Passwortbestätigung werden Sie über ein interessantes Problem stolpern: Das zweite Feld muss neu geprüft werden, wenn sich das erste ändert — sonst bleibt eine Fehlermeldung stehen, obwohl der Nutzer sie längst behoben hat.

7:14 Genau dafür gibt es die Verknüpfung von Feldern. Und beim Verfügbarkeitscheck achten Sie bitte auf beides: die Verzögerung und die sichtbare Rückmeldung. Die ersten beiden Punkte gehören zusammen und sind das, was den Unterschied zwischen einem funktionierenden und einem angenehmen Formular ausmacht. Der letzte ist der grundsätzliche Fehler: Wer nur beim Absenden prüft, konfrontiert jemanden mit sieben roten Feldern auf einmal, nachdem er fertig war.

7:40 Das ist gerade bei langen Formularen der Punkt, an dem Leute abbrechen. Prüfen Sie unterwegs, dann bleibt am Ende nichts übrig.

Performance & reaktives Rendering

7:48 Jetzt zu dem Thema, das bei großen Formularen über Wohl und Wehe entscheidet. Die Frage lautet: Wie sorgt man dafür, dass ein Tastendruck in Feld drei nicht die anderen neunundvierzig Felder neu zeichnet? Die Antwort ist ein Muster, das man einmal verstanden haben muss. Wer es einmal verstanden hat, wendet es überall an — und merkt nebenbei, dass es dasselbe Prinzip ist, das auch anderswo im Ökosystem trägt.

8:13 Das Prinzip lässt sich mit einem Zeitungsabonnement erklären. Sie bekommen nicht die gesamte Presse ins Haus, sondern genau die Zeitung, die Sie bestellt haben — und Sie werden nur benachrichtigt, wenn eine neue Ausgabe davon kommt. Genauso sagt ein Abschnitt Ihrer Oberfläche: Ich interessiere mich nur dafür, ob das Formular abschickbar ist.

8:32 Ändert sich irgendein Feldwert, ohne dass sich diese Frage anders beantwortet, passiert nichts. Der Rest der Oberfläche bleibt unberührt. Der zweite Punkt ist das Standardbeispiel und zugleich der häufigste Fall. Ein Absende-Knopf muss wissen, ob er aktiv sein darf und ob gerade gesendet wird — zwei Angaben, sonst nichts.

8:51 Wenn er sich nur dafür anmeldet, zeichnet er sich nur neu, wenn sich genau diese ändern. Der klassische Gegenentwurf, das ganze Formular an die Oberfläche zu hängen, funktioniert bei zehn Feldern und wird bei hundert zum Problem — und dann ist der Umbau aufwendig. Bei den Punkten vier und fünf geht es um dynamische Listen — Rechnungspositionen, Teilnehmer, Adressen.

9:13 Dass es dafür eigene Handgriffe zum Hinzufügen, Entfernen und Verschieben gibt, ist wichtiger, als es klingt. Wer solche Listen mit gewöhnlichen Zustandsvariablen verwaltet, muss die Prüfregeln, die Berührt-Zustände und die Fehler von Hand mitverschieben. Das ist die Sorte Code, die beim Löschen der dritten von fünf Zeilen subtil danebengeht.

9:33 Fünf Zeilen, die das Prinzip zeigen. Die eine Zeile mit der Auswahl ist der Kern: Sie beschreibt, woran dieser Bereich hängt. Alles außerhalb dieses Abschnitts bleibt vom Tippen unberührt. Ein praktischer Hinweis für die Übung: Wählen Sie so schmal wie möglich aus. Wer den gesamten Zustand nimmt und sich erst innen das Nötige herauspickt, hat sich die Anmeldung gespart und wieder alles abonniert — der Aufruf sieht dann richtig aus und wirkt nicht.

10:00 Diese Übung ist das perfekte Beispiel, weil eine Live-Summe verführerisch ist: Sie hängt ja tatsächlich von allen Positionen ab. Der Punkt ist, dass nur die Summenzeile neu gezeichnet werden soll, nicht die Positionsliste darüber. Achten Sie beim Bauen auf einen Klassiker, der auf der nächsten Folie wiederkommt: Der Schlüssel für die Listeneinträge darf nicht die laufende Nummer sein.

10:20 Löschen Sie die zweite von vier Zeilen und schauen Sie zu, was mit den Eingaben passiert, wenn Sie es doch tun. Der zweite Punkt ist genau der eben angesprochene und einer der ärgerlichsten Fehler überhaupt: Bei laufenden Nummern als Schlüssel rutschen nach dem Löschen alle Werte eine Zeile nach oben, während die Eingaben stehenbleiben — der Nutzer sieht Daten in falschen Zeilen.

10:41 Der letzte Punkt ist subtiler: Eine Auswahl, die bei jedem Durchlauf ein neues Objekt erzeugt, gilt jedes Mal als verändert. Damit ist die Anmeldung wirkungslos, obwohl sie richtig aussieht.

Form Composition: der Production-Ansatz

10:52 Bis hierhin haben wir mit den Grundbausteinen gearbeitet, und die sind ausführlich. Das ist beim Lernen richtig und im Alltag mühsam. Schauen wir uns an, wie man daraus eine eigene, schlanke Formularsprache für die ganze Anwendung macht. Es ist der Schritt von den Lernbeispielen zu dem, was Sie tatsächlich in ein Projekt schreiben würden.

11:12 Der Gedanke ist derselbe wie bei einem Setzkasten in der Werkstatt: Die Grundwerkzeuge kann man jedes Mal einzeln herausholen — oder man legt sich einmal eine Zusammenstellung zurecht, die genau zu der Arbeit passt, die man ständig macht. Hier heißt das: ein Texteingabefeld mit Beschriftung und Fehleranzeige, einmal gebaut, danach überall verwendet. Der Aufrufcode schrumpft von fünfzehn Zeilen pro Feld auf zwei.

11:35 Bemerkenswert ist, dass die Bibliothek selbst diesen Weg als den empfohlenen für ernsthafte Projekte ausweist. Zur Notiz auf der Folie eine wichtige Klarstellung: Diese Zusammenstellung lohnt sich nicht, weil ein Formular groß ist, sondern weil sich Felder wiederholen. Ein einziges riesiges Formular mit lauter unterschiedlichen Feldern gewinnt wenig. Zehn kleine Formulare, in denen überall dasselbe Texteingabefeld vorkommt, gewinnen viel.

12:00 Diese Unterscheidung ist der Unterschied zwischen einer Abstraktion, die Arbeit spart, und einer, die nur eine Ebene mehr zum Verstehen hinzufügt. Fünf Schritte, von denen die ersten drei einmalig sind — danach steht Ihre Formularsprache. Die Punkte vier und fünf betreffen große Formulare, und der Gedanke dahinter ist Arbeitsteilung: Eine Adressgruppe kann man als Einheit kapseln und in Bestellung, Profil und Rechnungsdaten gleichermaßen einsetzen.

12:27 Das ist mehr als Ordnung im Code — es bedeutet, dass eine Änderung an der Adresslogik an einer Stelle passiert. Wichtig ist Schritt eins: Die Kontexte legen Sie einmal zentral an, nicht pro Formular. Vergleichen Sie das mit dem Codebeispiel aus Kapitel eins — dort fünfzehn Zeilen für ein Feld, hier zwei. Die Ausführlichkeit ist nicht verschwunden, sie ist in Ihre Feldkomponente gewandert, wo sie einmal steht.

12:51 Interessant ist der untere Teil: Auch die Absende-Schaltfläche ist vorgebunden und bringt die Anmeldung aus dem letzten Kapitel schon mit. Damit wird richtiges Verhalten zur Voreinstellung statt zu etwas, an das man denken muss — das ist der eigentliche Wert einer solchen Schicht. Bauen Sie jetzt Ihre eigene Formularsprache und stellen Sie das Formular aus Übung eins darauf um.

13:12 Der Aha-Moment kommt beim Vergleich der beiden Fassungen nebeneinander — die zweite ist typischerweise ein Drittel so lang und deutlich besser lesbar. Achten Sie bei den Feldkomponenten darauf, Beschriftung und Fehleranzeige gleich mit einzubauen. Wenn das drin ist, kann man ein zugängliches Feld gar nicht mehr vergessen, weil es keinen anderen Weg gibt.

13:32 Der erste Punkt ist die Klarstellung von vorhin: Wiederverwendung ist das Kriterium, nicht Größe. Der dritte ist ein praktischer Hinweis zum Umfang der ausgelieferten Dateien — wenn Ihre Formularsprache zwanzig Feldtypen umfasst, sollten nicht alle zwanzig auf jeder Seite mitgeladen werden. Und der letzte ist ein Einrichtungsfehler mit verwirrendem Symptom: Mehrfach angelegte Kontexte führen dazu, dass Komponenten in den falschen greifen und Werte schlicht nicht ankommen.

Integration, Submission & Ökosystem

13:58 Zum Abschluss der Weg nach außen. Ein Formular endet nicht beim Klick auf Speichern — dann fängt der interessante Teil erst an: Was passiert bei einem Fehler vom Server, was mit der Liste, aus der die Daten kamen, und wer prüft eigentlich, ob die Daten wirklich in Ordnung sind? Diese Fragen entscheiden darüber, ob ein Formular sich fertig anfühlt oder nur funktioniert.

14:19 Der wichtigste Gedanke steckt im letzten Satz: dasselbe Prüfschema auf beiden Seiten. Das ist mehr als Bequemlichkeit. Wenn Client und Server verschiedene Regeln haben, driften sie auseinander — jemand ändert die Mindestlänge vorne und vergisst hinten, und plötzlich lehnt der Server ab, was die Oberfläche eben noch als gültig markiert hat.

14:39 Ein geteiltes Schema macht das unmöglich. Und die Prüfung im Browser bleibt, was sie ist: Komfort, keine Sicherheit. Verbindlich ist nur, was der Server sagt. Der erste Punkt ist der, der die Nutzererfahrung am stärksten verbessert. Ein Serverfehler wie "diese E-Mail ist bereits registriert" gehört an das E-Mail-Feld, nicht in ein Hinweisfenster in der Ecke.

15:00 Der Unterschied ist handfest: Im einen Fall weiß der Nutzer sofort, was zu tun ist, im anderen sucht er in einem Formular mit zwölf Feldern nach der gemeinten Stelle. Es gibt einen vorgesehenen Weg, Serverfehler an das jeweilige Feld zurückzugeben — nutzen Sie ihn. Punkt vier verdient eine Überlegung, denn es gibt keine allgemeingültige Antwort.

15:21 Nach dem Anlegen eines neuen Eintrags will man das Formular meist leeren — der Nutzer legt vielleicht gleich den nächsten an. Nach dem Bearbeiten eines bestehenden Eintrags will man die Werte stehen lassen, denn ein geleertes Formular sähe aus, als wäre etwas verlorengegangen. Legen Sie das bewusst fest statt es dem Zufall zu überlassen; es ist eine der Kleinigkeiten, die den Eindruck von Sorgfalt ausmachen.

15:44 Hier laufen die Fäden zusammen: Der Absendevorgang ruft die Speicheroperation und erklärt danach die betroffene Liste für veraltet. Zwei Zeilen für etwas, das von Hand deutlich mehr wäre — Ladezustand, Fehlerbehandlung, Nachladen der Liste. Beachten Sie, dass die Werte hier vollständig typisiert ankommen. Sie können sie direkt weitergeben, ohne sie zurechtzubiegen. Das ist die Auszahlung des Versprechens vom Anfang: Die Typen laufen von den Startwerten bis in den Serveraufruf durch.

16:13 In der letzten Übung schließen Sie den Kreis. Erzeugen Sie dabei absichtlich einen Serverfehler — etwa eine bereits vergebene E-Mail — und sorgen Sie dafür, dass die Meldung am richtigen Feld erscheint. Das ist der Teil, der in echten Projekten am häufigsten fehlt. Und wer die Zusatzaufgabe angeht, prüft dasselbe Schema noch einmal auf der Serverseite und erlebt den eigentlichen Gewinn eines geteilten Schemas: eine Regel, zwei Prüfstellen, kein Auseinanderdriften.

16:40 Der dritte Punkt ist ein handfestes Problem, das man in echten Anwendungen regelmäßig antrifft: Ohne Sperre während des Absendens erzeugt ein Doppelklick zwei Bestellungen. Der Zustand dafür ist vorhanden, man muss ihn nur anbinden. Der letzte Punkt ist der wichtigste: Eine Prüfung, die nur im Browser stattfindet, ist keine Prüfung.

16:59 Wer die Adresse der Schnittstelle kennt, kann sie mit beliebigen Daten aufrufen — und das ist keine theoretische Möglichkeit. Fassen wir zusammen. Die Typisierung entsteht aus Ihren Startwerten und trägt bis in den Serveraufruf — ohne einen einzigen Typparameter von Hand. Prüfregeln kommen als Schema direkt aus der Prüfbibliothek, Serverabfragen laufen verzögert und mit sichtbarem Wartezustand.

17:22 Die Anmeldung auf schmale Ausschnitte hält große Formulare flüssig. Und Ihre eigene Formularsprache macht aus fünfzehn Zeilen pro Feld zwei — und aus richtigem Verhalten die Voreinstellung. Am Ende steht ein Absendevorgang, bei dem Serverfehler dort landen, wo sie hingehören.

Fragen & Weiterarbeiten

17:39 Alle Formulare und Übungslösungen liegen in der Freigabe — nehmen Sie sich besonders Ihre eigene Formularsprache aus Übung drei mit, das ist der Teil, der sich im eigenen Projekt am schnellsten auszahlt. Die offizielle Dokumentation ist gut, und das Beispiel-Repository ist noch nützlicher: Dort finden Sie für fast jeden Sonderfall eine lauffähige Vorlage.

17:59 Wenn bei Ihnen ein Formularproblem auftaucht, das wir heute nicht besprochen haben, schreiben Sie uns. Vielen Dank für Ihre Aufmerksamkeit.