React v19 - Zod

React v19+ — Zod

0:00 TypeScript hat unserer Arbeit viel Sicherheit gegeben — und gleichzeitig eine gefährliche Bequemlichkeit. Man schreibt hin, dass eine Antwort eine Liste von Nutzern ist, sieht die Felder im Editor vorgeschlagen und fühlt sich abgesichert. Doch dieser Typ ist eine Behauptung, keine Prüfung. Beim Übersetzen verschwindet er restlos; zur Laufzeit ist da nur, was der Server tatsächlich geschickt hat.

0:23 Genau an dieser Nahtstelle setzt Zod an. Der Satz auf der Folie bringt es auf den Punkt: Typen sagen, was gelten soll — Zod prüft, dass es auch stimmt.

Schema-Validierung mit Zod

0:33 Der rote Faden führt vom ersten Schema bis zu einer Anwendung, in der jede Systemgrenze geprüft ist — Schnittstellen, Formulare, sogar die Umgebungsvariablen beim Start. Unterwegs geht es um Dinge, die den Alltag angenehmer machen: Fehlermeldungen, die beim richtigen Feld landen und auf Deutsch verständlich sind, und Umwandlungen zwischen der Form, in der Daten übertragen werden, und der, in der man mit ihnen arbeiten möchte.

0:56 Die zweite Frage bringt erfahrungsgemäß die besten Geschichten hervor — meist solche, die mit "und dann war das Feld plötzlich null" beginnen. Es sind die klassischen Fälle: Ein Feld, das laut Dokumentation immer da ist, fehlt in drei Prozent der Datensätze. Ein Datum kommt mal als Zeichenkette, mal als Zahl. Wenn Sie so etwas kennen, haben Sie bereits erlebt, wofür der heutige Tag die Antwort ist. Und sagen Sie ruhig, ob Sie schon mit einer anderen Prüfbibliothek gearbeitet haben.

Grundlagen & Einordnung

1:25 Beginnen wir mit der Einordnung, denn hier sitzt die entscheidende Einsicht. TypeScript und Zod sind keine Konkurrenten, sondern arbeiten in verschiedenen Zeiträumen. Wer versteht, wo der eine aufhört und der andere anfängt, hat das Wichtigste dieses Tages begriffen. Es ist die Art von Einsicht, die man nicht mehr los wird — danach sieht man Systemgrenzen überall.

1:47 Stellen Sie sich TypeScript als Bauplanprüfung vor: Bevor gebaut wird, schaut jemand die Zeichnungen durch und meldet Widersprüche. Was er nicht prüfen kann, ist, ob der Zulieferer später die richtigen Ziegel bringt. Genau das übernimmt Zod — es schaut sich die tatsächliche Lieferung an. Und der elegante Teil ist die Verbindung: Sie beschreiben Ihre Daten einmal, und daraus entstehen beide Dinge, die Laufzeitprüfung und der statische Typ.

2:12 Kein doppeltes Pflegen, kein Auseinanderdriften. Der erste Punkt nennt die vier Stellen, an denen es zählt, und ich möchte eine davon hervorheben, weil sie oft vergessen wird: der lokale Speicher des Browsers. Dort liegen Daten, die Ihre eigene Anwendung vor drei Versionen geschrieben hat — in einem Format, das es inzwischen nicht mehr gibt.

2:32 Sie lesen sie mit dem aktuellen Typ und wundern sich. Alles, was Ihre Anwendung verlässt und zurückkommt, ist eine Grenze. Auch wenn es nur der eigene Browser war. Der dritte Schritt ist eine Architekturentscheidung, die Sie am Anfang treffen sollten: Die Schemas liegen an einem Ort und sind die Wahrheit über Ihre Daten.

2:50 Alles andere leitet sich daraus ab. Wenn Sie das konsequent durchhalten, gibt es in Ihrem Projekt keine Stelle mehr, an der jemand einen Datentyp von Hand beschreibt — und damit auch keine Stelle, an der er veralten kann. Der letzte Schritt zeigt, wie das technisch geht: ein Aufruf, und der Typ ist da. Schauen Sie sich die letzte Zeile genau an, denn sie ist der Kern der ganzen Sache. Der Typ wird nicht geschrieben, sondern aus dem Schema abgeleitet.

3:16 Wenn Sie morgen ein Feld ergänzen, ist es im Typ automatisch enthalten — und jede Stelle, die es hätte berücksichtigen müssen, meldet sich beim Übersetzen. Der übliche Gegenentwurf, ein Interface neben dem Schema, sieht auf den ersten Blick genauso aus und hat einen entscheidenden Nachteil: Es gibt nichts, was die beiden zusammenhält.

3:35 Machen wir den Einstieg praktisch. Definieren Sie ein Schema und leiten Sie den Typ ab. Und dann machen Sie den lehrreichen Test: Geben Sie dem Schema absichtlich kaputte Daten — eine E-Mail ohne At-Zeichen, ein fehlendes Feld — und schauen Sie sich an, was zurückkommt. Sie werden sehen, dass die Fehlermeldung sehr genau ist: Sie sagt nicht nur, dass etwas nicht stimmt, sondern welches Feld und warum.

3:58 Das ist die Grundlage für alles, was wir im Kapitel über Fehlerbehandlung machen. Der erste Punkt ist das Missverständnis, um das sich der ganze Tag dreht — ein TypeScript-Typ ist kein Beweis über die tatsächlichen Daten. Der dritte ist die Doppelpflege von eben, die im ersten Monat funktioniert und danach schleichend auseinanderläuft.

4:17 Und der zweite ist eine praktische Voraussetzung: Ohne den strengen Modus im Compiler wird die Typableitung unzuverlässig, weil dann plötzlich alles auch null sein könnte. Diese Einstellung sollte ohnehin an sein.

Schemas definieren

4:29 Jetzt zum Handwerk. Wir schauen uns an, wie man Daten beschreibt — von einfachen Werten über Objekte bis zu den interessanten Fällen, in denen eine Antwort verschiedene Formen haben kann. Und wir sehen, wie man vermeidet, dieselben Felder fünfmal aufzuschreiben. Ein sauber geschnittenes Datenmodell zahlt sich hier besonders schnell aus, weil alles Weitere daraus abgeleitet wird.

4:51 Zwei Dinge sind hier hervorzuheben. Erstens die Schreibweise für Formate: In der aktuellen Fassung stehen E-Mail, Kennung und Adresse direkt zur Verfügung, statt als Kette an eine Zeichenkette angehängt zu werden. Wenn Sie ältere Beispiele finden, ist das der Unterschied. Zweitens die unterschiedene Vereinigung — der Fachbegriff für etwas sehr Alltägliches: eine Antwort, die entweder Erfolg mit Daten oder Fehler mit Meldung bedeutet.

5:15 Genau dafür ist sie gemacht, und sie ist für Schnittstellen-Antworten die empfohlene Form. Der dritte Punkt ist im Alltag der wertvollste. Sie haben ein Schema für einen Nutzer, und jetzt brauchen Sie eines für das Anlegen — dasselbe, nur ohne Kennung, weil die der Server vergibt. Statt alles abzuschreiben, leiten Sie ab: alles außer diesem einen Feld. Und wenn morgen ein Feld dazukommt, ist es in beiden.

5:40 Das ist derselbe Gedanke wie beim Ableiten von Typen, nur eine Ebene höher. Der letzte Punkt betrifft Fälle, in denen Eingangs- und Ausgangsform sich unterscheiden — dazu gleich mehr. Der zweite Punkt enthält eine Unterscheidung, die häufig verwechselt wird und echte Folgen hat. Optional heißt: Das Feld darf fehlen. Nullbar heißt: Es ist da, aber leer.

6:02 Das sind zwei verschiedene Aussagen, und Schnittstellen meinen oft genau eine davon. Wer beides gleichsetzt, lässt entweder ungültige Daten durch oder lehnt gültige ab. Und der Vorgabewert ist die dritte Variante: Das Feld darf fehlen, und wenn es fehlt, setzt Zod einen Wert ein. Danach ist es in Ihrem Code garantiert vorhanden.

6:23 Der Gewinn zeigt sich nach dem Prüfen. Wenn Sie danach abfragen, ob der Status Erfolg bedeutet, weiß TypeScript im Erfolgszweig, dass die Daten vorhanden sind — und im Fehlerzweig, dass es die Meldung gibt. Sie greifen also nie versehentlich auf ein Feld zu, das es in dieser Variante gar nicht gibt. Das unterscheidet diese Form von einer gewöhnlichen Vereinigung, bei der Sie das Eingrenzen selbst schreiben müssten.

6:47 Nebenbei sind die Fehlermeldungen deutlich präziser, weil Zod weiß, welchen Zweig es prüfen muss. In dieser Übung bauen Sie den Grundstock, auf dem der Rest des Tages aufsetzt. Achten Sie beim Zuschnitt auf die Ableitungen: Beginnen Sie mit einem Basis-Schema und leiten Sie die Varianten daraus ab, statt sie nebeneinanderzustellen.

7:06 Der Prüfstein ist streng formuliert und lohnt die Ernstnahme — alle Typen stammen aus Schemas. Suchen Sie also gezielt nach übrig gebliebenen Interfaces. Meist findet sich noch eines, das jemand aus Gewohnheit geschrieben hat. Der zweite Punkt ist eine echte Einschränkung, die man kennen sollte: Sobald ein Schema eigene Prüfregeln über mehrere Felder enthält, lassen sich daraus keine Teilmengen mehr bilden — die Regel könnte sich ja auf ein entferntes Feld beziehen.

7:33 Die Lösung ist, die Ableitungen vor der Zusatzregel zu machen. Der erste Punkt betrifft die veraltete Schreibweise aus der letzten Version, die noch in vielen Beispielen im Netz steht.

Parsen, Transformieren, Codecs

7:43 Jetzt geht es ums Prüfen selbst — und um zwei sehr unterschiedliche Arten, damit umzugehen. Danach schauen wir uns etwas an, das über Prüfen hinausgeht: Umwandlungen in beide Richtungen zwischen der Übertragungsform und der Arbeitsform Ihrer Daten. Beides zusammen macht aus der Prüfung eine echte Grenze statt einer bloßen Kontrolle.

8:03 Der Unterschied zwischen den beiden Prüfvarianten ist eine Stilfrage mit praktischen Folgen. Die eine wirft im Fehlerfall eine Ausnahme, die andere gibt ein Ergebnisobjekt zurück, das Sie abfragen. In React ist die zweite fast immer richtig — denn eine geworfene Ausnahme mitten im Zeichnen einer Komponente führt dazu, dass die Anwendung in die Fehlerbehandlung springt oder abstürzt.

8:24 Ein ungültiges Formularfeld ist aber kein Absturzgrund, es ist ein normaler Zustand, den Sie anzeigen wollen. Der letzte Punkt ist die spannendste Neuerung und verdient ein Bild. Denken Sie an einen Übersetzer, der in beide Richtungen arbeitet. Was über die Leitung kommt, ist eine Zeichenkette mit Datum und Uhrzeit; womit Sie arbeiten wollen, ist ein Datumsobjekt.

8:46 Bisher hätten Sie beim Empfangen umgewandelt und beim Senden wieder zurück — an zwei verschiedenen Stellen, mit zwei Chancen, es unterschiedlich zu tun. Ein Codec beschreibt beide Richtungen an einem Ort. Damit ist der Hin- und Rückweg garantiert konsistent. Der vierte Punkt betrifft einen Alltagsfall, den man ständig hat.

9:05 Alles, was aus der Adresszeile oder einem Formularfeld kommt, ist eine Zeichenkette — auch die Seitenzahl, auch das Häkchen. Die Umwandlung übernimmt eine eigene Variante des Schemas, die vor dem Prüfen konvertiert. Damit ersparen Sie sich das übliche Umwandeln von Hand, das immer an genau der einen Stelle vergessen wird — meist dort, wo aus einer Ziffernfolge stillschweigend ein Textvergleich wird.

9:28 Der obere Teil ist das Muster, das Sie im Schlaf beherrschen sollten: prüfen, Erfolg abfragen, im Fehlerfall früh aussteigen. Ab der nächsten Zeile sind die Daten garantiert schematreu — und TypeScript weiß das auch, weil die Abfrage den Typ eingrenzt. Der untere Teil zeigt den Codec in beiden Richtungen. Beachten Sie die Symmetrie: derselbe Codec, einmal hin, einmal zurück. Bei zwei getrennten Umwandlungsfunktionen wäre das ein Versprechen ohne Absicherung.

9:56 Diese Übung bildet den vollständigen Kreislauf ab: Daten empfangen, umwandeln, damit arbeiten, zurückschicken. Der Begriff im Erfolgskriterium ist der entscheidende — die Grenze soll rundlauf-stabil sein. Prüfen Sie das buchstäblich: Dekodieren und sofort wieder enkodieren muss dasselbe ergeben, mit dem Sie angefangen haben.

10:15 Wenn nicht, verlieren Sie irgendwo Information, typischerweise bei Zeitzonen. Genau solche Verluste sind der Grund für die berüchtigten Fehler, bei denen ein Datum jeden Tag um eine Stunde wandert. Der zweite Punkt ist tückischer, als er klingt. Wenn Sie nach dem Prüfen nicht abfragen, ob es geklappt hat, und trotzdem auf die Daten zugreifen, bekommen Sie im Fehlerfall einen undefinierten Wert — und der Fehler taucht erst drei Zeilen später auf, an einer Stelle, die völlig unschuldig ist.

10:44 TypeScript warnt Sie hier in aller Regel; die Warnung wegzudrücken ist der eigentliche Fehler. Der letzte Punkt ist die Datumsfalle: Ein Datum als Zeichenkette durch die halbe Anwendung zu reichen, führt garantiert dazu, dass irgendwo doch gerechnet wird.

Fehlerbehandlung & UX

10:58 Jetzt kommt der Teil, der über die Qualität einer Anwendung aus Nutzersicht entscheidet. Ein Fehler ist geprüft und erkannt — aber wie kommt er so an den Menschen vor dem Bildschirm, dass der weiß, was zu tun ist? Das ist mehr Arbeit als das Prüfen selbst. Und es ist der Teil, den Nutzer als Einziges von Ihrer ganzen Prüflogik jemals zu Gesicht bekommen.

11:19 Das entscheidende Detail ist der Pfad. Ein Fehler weiß nicht nur, dass etwas falsch ist, sondern auch, wo — bis in verschachtelte Objekte und Listen hinein. Damit können Sie eine Meldung an genau das Feld hängen, um das es geht, statt eine Sammelmeldung über dem Formular anzuzeigen. Der Unterschied ist erheblich: Im einen Fall sieht der Nutzer sofort, wo er nachbessern muss, im anderen sucht er in vierzehn Feldern.

11:42 Und die mitgelieferten Sprachpakete nehmen Ihnen das Übersetzen der Standardmeldungen ab. Der letzte Punkt ist der, der am häufigsten fehlt, obwohl er am wenigsten kostet. Eine rote Umrandung und ein roter Text darunter sind für sehende Nutzer eine klare Aussage — für jemanden mit Vorlesesoftware sind sie unsichtbar, wenn die Verbindung zwischen Feld und Meldung technisch nicht hergestellt ist.

12:06 Zwei Attribute stellen sie her. Und die Ansage ändert sich damit von "Eingabefeld" zu "Eingabefeld, ungültig, Bitte gültige E-Mail eingeben". Das ist der ganze Unterschied zwischen benutzbar und nicht benutzbar. Zum vierten Punkt eine praktische Empfehlung. Die Spracheinstellung setzen Sie einmal beim Start der Anwendung, nicht bei jeder Prüfung — sonst haben Sie zuverlässig irgendwo eine Stelle, an der englische Standardmeldungen durchschlagen.

12:32 Und ein Hinweis zur Erwartung: Die mitgelieferten Meldungen sind korrekt und technisch, aber nicht immer freundlich. Für Felder, bei denen es auf den Ton ankommt, lohnt sich eine eigene Formulierung — dafür gibt es den Fehlerparameter. Drei Zeilen für etwas, das man sonst mühsam von Hand baut. Die Umwandlungsfunktion sortiert alle Fehler nach Feldnamen — und liefert je Feld eine Liste, weil ein Feld durchaus mehrere Probleme haben kann.

12:58 Diese Struktur können Sie direkt an Ihre Eingabefelder binden. Ein praktischer Hinweis für die Anzeige: Zeigen Sie nicht alle Meldungen eines Feldes auf einmal. Die erste genügt; wenn sie behoben ist, kommt die nächste. Alles andere wirkt erdrückend. Setzen Sie die Fehleranzeige um — mit der Verknüpfung für Vorlesesoftware und auf Deutsch.

13:19 Ich empfehle nachdrücklich, das Ergebnis einmal mit eingeschalteter Vorlesefunktion zu prüfen, nur mit der Tastatur. Für die meisten ist das ein Aha-Moment, weil man dabei merkt, wie wenig von der visuellen Klarheit übrig bleibt, wenn die technische Verknüpfung fehlt. Es sind zwei Attribute — aber man muss sie eben setzen, und niemand erinnert einen daran.

13:40 Der zweite Punkt ist der Klassiker, den man in echten Anwendungen leider sieht: Das gesamte Fehlerobjekt landet als technischer Text in einem Hinweisfenster. Der Nutzer sieht dann etwas mit eckigen Klammern und dem Wort "invalid_type" und weiß gar nichts. Die Informationen für eine gute Meldung sind alle da — sie müssen nur zugeordnet werden.

14:00 Der letzte Punkt ist die vergessene Spracheinstellung, die sich als englische Meldungen mitten in einer deutschen Oberfläche zeigt.

Zod in React-Formularen

14:08 Jetzt bringen wir das Ganze in ein Formular. Die gute Nachricht: Die Verbindung zwischen Schema und Formularbibliothek ist ein Einzeiler. Die interessanten Fragen liegen woanders — bei den Feldtypen, bei Regeln über mehrere Felder und bei der Frage, wer eigentlich verbindlich prüft. Sie werden sehen, dass die technische Verbindung fast nebensächlich ist gegenüber den Entscheidungen drumherum.

14:31 Der eigentliche Gewinn steht im letzten Satz: dasselbe Schema auf beiden Seiten. Das ist mehr als gesparte Arbeit — es ist die Garantie, dass Client und Server nicht auseinanderlaufen. Ohne diese Teilung passiert unweigerlich Folgendes: Jemand lockert eine Regel im Formular, vergisst den Server, und plötzlich lehnt der ab, was die Oberfläche eben noch abgesegnet hat.

14:52 Der Nutzer sieht eine Fehlermeldung für etwas, das ihm gerade als gültig angezeigt wurde. Mit einem geteilten Schema kann das nicht passieren. Der erste Punkt hat einen Nebeneffekt, den man erst im Alltag schätzt: Auch die Fehler sind typisiert. Sie können also nicht auf eine Fehlermeldung für ein Feld zugreifen, das es gar nicht gibt — der Editor schlägt Ihnen genau die vorhandenen vor.

15:14 Bei einem Formular mit zwanzig Feldern, das über Monate wächst, ist das der Unterschied zwischen einer Fehleranzeige, die mitwächst, und einer, in der nach dem dritten Umbau zwei Meldungen ins Leere zeigen. Der dritte Punkt ist der praktische Stolperstein bei jedem Formular. Ein Zahlenfeld im Browser liefert trotz seines Typs eine Zeichenkette.

15:34 Wenn Ihr Schema eine Zahl erwartet, scheitert die Prüfung mit einer Meldung, die den Nutzer ratlos zurücklässt — es steht ja eine Zahl drin. Die Umwandlungsvariante löst das. Beim Häkchen ist es ähnlich. Merken Sie sich einfach: Alles, was aus einem Formular kommt, ist Text, bis Sie etwas anderes vereinbart haben. Ein Zeile Verbindung, und die Formularbibliothek prüft ab sofort gegen Ihr Schema.

15:58 Beachten Sie den Typparameter oben: Er kommt aus dem Schema, wird also nicht zusätzlich beschrieben. Damit ist der Kreis geschlossen — ein Schema liefert die Prüfregeln, die Typen der Werte und die Typen der Fehler. Im unteren Teil sehen Sie die Auszahlung: Die Werte im Absendevorgang sind vollständig typisiert und geprüft. Sie können sie direkt weitergeben, ohne sie zu kontrollieren.

16:22 Diese Übung bringt alles zusammen: Formularprüfung, deutsche Meldungen und die zweite Prüfung auf der Serverseite. Machen Sie den Test, der den Wert des geteilten Schemas zeigt: Ändern Sie eine Regel — etwa die Mindestlänge des Passworts — und beobachten Sie, dass beide Seiten die Änderung sofort mittragen. Das ist der Moment, in dem der Aufwand des Tages sich rechnet. Die Zusatzaufgabe mit dem mehrstufigen Ablauf ist anspruchsvoll und lohnt sich, wenn Sie so etwas im Projekt haben.

16:50 Der zweite Punkt ist der schleichende Verfall: Jemand legt neben dem Schema noch einen eigenen Typ für das Formular an, weil es gerade praktisch schien. Ab da gibt es zwei Wahrheiten, und die zweite altert. Der letzte Punkt ist die Serverprüfung, die ich noch einmal betonen möchte: Eine Prüfung im Browser ist Komfort für ehrliche Nutzer.

17:09 Wer die Schnittstelle direkt anspricht, sieht davon nichts. Verbindlich ist nur, was auf der Serverseite geprüft wird.

API-Grenzen & Ökosystem

17:16 Jetzt weiten wir den Blick vom Formular auf alle Grenzen Ihrer Anwendung. Die Leitfrage lautet: An welchen Stellen kommen Daten herein, über die Sie keine Kontrolle haben? Und die Antwort ist meist länger, als man beim ersten Nachdenken vermutet. Nehmen Sie diese Liste ruhig mit ins eigene Projekt — sie ist dort erfahrungsgemäß länger als gedacht.

17:37 Der wichtigste Gedanke ist die Zentralisierung: Die Prüfung gehört an die Grenze, nicht in die Komponenten. Ein Ort, an dem Daten hereinkommen, ein Ort, an dem geprüft wird — dahinter können Sie sich verlassen. Besonders erwähnenswert sind die Umgebungsvariablen. Die werden regelmäßig vergessen, und der Fehler dabei ist besonders unangenehm: Eine fehlende Konfiguration fällt erst auf, wenn jemand die betroffene Funktion benutzt.

18:02 Das kann Wochen nach dem Ausrollen sein. Der dritte Punkt beschreibt ein Prinzip, das über dieses Thema hinausgeht: Scheitere früh und laut. Eine Anwendung, die beim Start abbricht, weil eine Konfiguration fehlt, ist ärgerlich — aber sie ist ehrlich, und der Fehler ist in zwei Minuten behoben. Eine Anwendung, die startet und drei Wochen später in einem Randbereich seltsame Ergebnisse liefert, kostet einen Tag Suche. Fünf Zeilen Prüfung beim Start machen den Unterschied.

18:31 Der erste Punkt ist die Umsetzung des Zentralisierungsgedankens: Die Prüfung gehört in den Wrapper, den ohnehin jeder Aufruf durchläuft. Damit können Ihre Kolleginnen und Kollegen sie gar nicht vergessen — es gibt keinen Weg an ihr vorbei. Das ist ein Muster, das ich generell empfehle: Machen Sie das Richtige zur einzigen Möglichkeit, statt es zur Verabredung zu erklären.

18:53 Verabredungen halten genau bis zum nächsten Termindruck. Hier wird ausnahmsweise die werfende Variante benutzt, und das ist kein Widerspruch zu vorhin. Eine Schnittstelle, die etwas anderes liefert als vereinbart, ist tatsächlich ein außergewöhnlicher Zustand — anders als ein Formularfeld, das jemand falsch ausgefüllt hat.

19:12 Hier soll es krachen, damit der Fehler sichtbar wird und in Ihrer Fehlerüberwachung landet. Der zweite Vorteil ist subtiler: Der Rückgabetyp dieser Funktion kommt jetzt aus dem Schema. Sie können ihn gar nicht mehr falsch angeben. Sichern Sie die Grenze ab. Ein Tipp für den Test: Verändern Sie die Antwort absichtlich — löschen Sie ein Feld oder ändern Sie einen Typ — und schauen Sie, was passiert.

19:35 Ohne Prüfung wandert der Fehler bis in die Oberfläche und zeigt sich dort als leerer Text oder als Absturz an einer unschuldigen Stelle. Mit Prüfung haben Sie eine klare Meldung an der Grenze, die auch noch sagt, welches Feld fehlt. Nehmen Sie unbedingt auch die Zusatzaufgabe mit den Umgebungsvariablen mit. Der letzte Punkt ist der ärgerlichste, weil er den ganzen Aufwand zunichtemacht: Man prüft ordentlich und schreibt danach eine Umtypisierung hin, weil der Typ gerade nicht passte.

20:03 Damit ist die Garantie weg — der Compiler glaubt Ihnen, und niemand prüft mehr etwas. Wenn Sie an dieser Stelle das Bedürfnis danach verspüren, ist das fast immer ein Zeichen, dass das Schema nicht ganz zur Wirklichkeit passt. Dann gehört das Schema korrigiert, nicht der Typ überschrieben.

Best Practices, Performance & Abschluss

20:19 Zum Abschluss die Fragen, die sich stellen, wenn das alles im Projekt angekommen ist: Wie ordnet man die Schemas, damit sie auffindbar bleiben? Was kostet das an Umfang der ausgelieferten Anwendung? Und welche Muster sollte man im Review gezielt suchen? Es sind die Fragen, die im ersten Monat niemand stellt und die nach einem Jahr über die Wartbarkeit entscheiden.

20:40 Der erste Satz ist die Zusammenfassung des Tages und die eine Regel, die ich Ihnen mitgeben möchte: Das Schema ist die Wahrheit, der Typ wird abgeleitet. Nicht umgekehrt, nicht nebeneinander. Wenn Sie in einem halben Jahr in Ihrem Projekt kein einziges handgeschriebenes Interface für Daten mehr finden, die von außen kommen, haben Sie es richtig gemacht.

20:59 Der zweite Teil betrifft den Umfang — für die meisten Anwendungen ein Nebenthema, für sehr schlanke Frontends aber ein echtes Argument. Zum zweiten Punkt eine ehrliche Einordnung, damit Sie den Aufwand richtig gewichten. Eine Prüfbibliothek bringt Gewicht mit — bei einer Verwaltungsanwendung hinter der Anmeldung ist das völlig gleichgültig, bei einer öffentlichen Verkaufsseite, die um Ladezeit kämpft, nicht.

21:22 Für den zweiten Fall gibt es eine schlanke Variante mit demselben Funktionsumfang, aber besser ausdünnbar. Prüfen Sie das mit einer Messung statt nach Gefühl; oft ist die Prüfbibliothek nicht das größte Stück im Paket. Der zweite Punkt ist eine Abwägung ohne allgemeingültige Antwort. Sollen Schemas neben dem Code liegen, der sie benutzt, oder zentral gesammelt?

21:44 Meine Faustregel: Was mehrere Bereiche benutzen — das Domänenmodell — gehört zentral. Was nur ein Formular betrifft, darf danebenliegen. Das Kriterium ist die Reichweite, nicht der Ordner. Und der letzte Punkt ist der praktischste: Nehmen Sie die Liste der Anti-Muster in Ihre Code-Durchsicht auf. Sie sind alle leicht zu erkennen, wenn man weiß, wonach man sucht.

22:07 Zwei Zeilen, zwei verschiedene Sparmaßnahmen. Oben die schlanke Variante, die ungenutzte Teile beim Bauen entfernen lässt. Unten die gezielte Sprachwahl — statt alle dreißig Sprachpakete mitzuliefern, laden Sie das eine, das Sie brauchen. Wichtig ist der Kommentar unten: Die Typableitung funktioniert unverändert. Sie verlieren nichts von dem, worum es heute ging.

22:30 Das ist reine Konfiguration und kein Kompromiss bei der Sicherheit. Zum Abschluss räumen Sie auf. Gehen Sie durch Ihr Übungsprojekt und suchen Sie gezielt nach den drei Mustern: doppelte Typdefinitionen, Umtypisierungen nach dem Prüfen und Grenzen ohne Prüfung. Diese Suche lohnt sich auch im echten Projekt, und zwar mehr, als man denkt — die Ergebnisse sind meist überraschend.

22:52 Nehmen Sie sich die Liste einfach mit und machen Sie das Gleiche nächste Woche in Ihrem eigenen Code. Diese vier Punkte sind die Zusammenfassung aller Fehler des Tages. Der erste ist die Doppelpflege, der zweite die aufgehobene Garantie, der dritte die fehlende Serverprüfung. Der vierte ist der harmloseste, aber weit verbreitet: Wer alle Sprachpakete lädt, schleppt neunundzwanzig Sprachen mit, die niemand jemals sieht.

23:16 Alle vier haben eines gemeinsam — sie entstehen nicht aus Unwissen, sondern aus einem Moment, in dem etwas gerade schneller ging. Genau deshalb gehören sie in die Code-Durchsicht. Fassen wir den Tag zusammen. Das Schema ist die Wahrheit über Ihre Daten, der Typ wird daraus abgeleitet — eine Beschreibung, nicht zwei. Geprüft wird an jeder Grenze, mit der Ergebnisvariante statt geworfener Ausnahmen, und wo Übertragungs- und Arbeitsform auseinandergehen, erledigt ein Codec beide Richtungen an einer Stelle.

23:46 Fehler landen feldweise und in verständlicher Sprache beim Nutzer. Und die Prüfung im Formular ist Komfort — verbindlich bleibt die auf der Serverseite.

Fragen & Weiterarbeiten

23:56 Alle Schemas und Übungslösungen liegen in der Freigabe — die Schema-Bibliothek aus Kapitel zwei und der geprüfte Schnittstellen-Wrapper sind die beiden Teile, die sich im eigenen Projekt am schnellsten übertragen lassen. Die offizielle Dokumentation ist ausgesprochen gut geschrieben; wenn Sie von einer älteren Fassung kommen, lohnt sich der Migrationsleitfaden, und die Seite zu den Codecs ist noch relativ neu und wenig bekannt.

24:19 Bei Fragen aus dem eigenen Code melden Sie sich gern. Vielen Dank für Ihre Aufmerksamkeit.