TypeScript für React

TypeScript für React

0:00 Im vorigen Modul haben wir gesehen, wie viele JavaScript-Fehler erst dann auffallen, wenn der Code bereits läuft — im schlimmsten Fall beim Nutzer. Genau hier setzt TypeScript an. Es verschiebt den Moment der Wahrheit nach vorn: von der Laufzeit in den Editor. Was heute noch als Zusatzaufwand erscheinen mag, ist in größeren Projekten längst Standard geworden — und im React-Umfeld praktisch die Regel.

0:23 Wir gehen den Weg heute vollständig: von den Grundlagen über das Typsystem bis zur fertigen, typsicheren Komponente. Am Ende sollen Typen sich nicht wie Bürokratie anfühlen, sondern wie ein Sicherheitsnetz.

Von JavaScript zu typsicherem React

0:35 Der Tag ist als Aufstieg gebaut. Wir starten mit den Grundlagen und dem Setup, schauen uns dann das Typsystem an — Interfaces, Enums und Verwandte. Danach Funktionen und Generics, komplexe Daten mit Objekten und Arrays, die statische Prüfung selbst, und zum Schluss die Zusammenführung in React. Jedes Modul hat eine eigene Übung, das heißt: Sie schreiben heute selbst. Und eine Bitte vorweg — der Leitsatz oben ist ernst gemeint. Typen sind kein Selbstzweck.

1:04 Drei Dinge sollen Sie heute Abend mitnehmen. Erstens ein klares Bild davon, was TypeScript gegenüber JavaScript tatsächlich bringt — und ehrlicherweise auch, was es kostet. Zweitens die Fähigkeit, eigene Typen selbst zu deklarieren und sinnvoll einzusetzen, statt sie nur aus fremden Bibliotheken zu übernehmen. Und drittens ein React-Projekt, das Sie typsicher aufsetzen können. Das Dritte ist das eigentliche Ziel; die ersten beiden sind der Weg dorthin.

1:30 Wenn Sie am Ende in Ihrem eigenen Projekt anfangen können, hat der Tag sein Ziel erreicht.

TypeScript-Grundlagen

1:36 Beginnen wir mit der Frage, die viele im Kopf haben, wenn sie zum ersten Mal davon hören: Ist das jetzt eine neue Sprache, die ich lernen muss? Die Antwort ist angenehmer, als man erwartet. TypeScript ist eine Obermenge von JavaScript. Das bedeutet ganz konkret: Jede gültige JavaScript-Datei ist bereits gültiges TypeScript. Sie fangen nicht bei null an, Sie bauen aus.

1:58 Und am Ende kommt wieder reines JavaScript heraus — der Compiler entfernt die Typinformationen, im Browser läuft nichts anderes als vorher. Man kann sich das wie Baupläne für ein Haus vorstellen: Sie stehen nicht im fertigen Gebäude, aber ohne sie merkt niemand, dass eine tragende Wand fehlt. Der große Vorteil dieser Bauweise: Sie können schrittweise vorgehen, Datei für Datei. Ein Alles-oder-nichts ist es ausdrücklich nicht.

2:24 Der Nutzen zeigt sich auf vier Ebenen. Am offensichtlichsten: Fehler erscheinen beim Kompilieren statt zur Laufzeit — und damit bei Ihnen statt beim Kunden. Der zweite Punkt wird oft unterschätzt, ist im Alltag aber der spürbarste: Die Entwicklungsumgebung weiß plötzlich, was ein Objekt kann. Autovervollständigung, sicheres Umbenennen über das ganze Projekt hinweg.

2:46 Drittens dokumentiert sich der Code selbst — eine Signatur sagt mehr als ein Kommentar, und sie veraltet nicht still. Und viertens der Teamaspekt: Je größer das Projekt und je mehr Hände darin arbeiten, desto wertvoller sind verbindliche Verträge. Genau deshalb hat sich TypeScript durchgesetzt. Der Einstieg ist erfreulich unspektakulär.

3:06 Sie installieren das Werkzeug als Entwicklungsabhängigkeit, erzeugen eine Konfigurationsdatei, benennen Ihre Dateien um — und das war im Wesentlichen der technische Teil. Wichtig ist die Unterscheidung bei der Endung: Sobald JSX im Spiel ist, braucht die Datei die Variante mit dem x. Kompiliert wird entweder direkt oder, im Normalfall, über Ihr Build-Werkzeug, das das ohnehin miterledigt.

3:28 Der eigentliche Aufwand steckt im letzten Schritt: die gemeldeten Fehler abzuarbeiten. Erschrecken Sie nicht über die Zahl — sie sagt nur, wie viel bislang unbemerkt blieb. Dieses Beispiel bringt den ganzen Unterschied auf einen Punkt. Oben eine Additionsfunktion ohne Typen. Übergibt jemand versehentlich eine Zeichenkette statt einer Zahl, addiert JavaScript nicht — es hängt aneinander. Aus eins plus zwei wird die Zeichenfolge zwölf.

3:54 Kein Fehler, kein Hinweis, nur ein falsches Ergebnis, das irgendwo weiter unten Schaden anrichtet. Unten dieselbe Funktion mit Typangaben. Derselbe Aufruf wird nun sofort im Editor rot unterringelt, noch bevor irgendetwas ausgeführt wurde. Das ist der Kern der Sache, und mehr braucht es zur Begründung eigentlich nicht. Jetzt stellen Sie selbst um. Nehmen Sie ein kleines JavaScript-Projekt — gern eins aus dem vorigen Modul — und bringen Sie es auf TypeScript.

4:22 Das Lernziel ist weniger die Installation als das Lesen: Compiler-Meldungen wirken anfangs abschreckend, sind aber sehr präzise, wenn man sich an ihren Aufbau gewöhnt hat. Fertig sind Sie, wenn der Compiler ohne Konfigurationsfehler durchläuft und einen bewusst eingebauten Typfehler meldet. Wer schneller ist: Sorgen Sie dafür, dass bei Fehlern gar kein Ergebnis mehr erzeugt wird — warum das wichtig ist, sehen wir gleich.

4:47 Drei Dinge, über die alle einmal stolpern. Erstens die Dateiendung: Wer JSX in eine Datei ohne das x schreibt, bekommt kryptische Meldungen, die nichts mit dem eigentlichen Problem zu tun haben. Zweitens — und das überrascht viele — erzeugt der Compiler standardmäßig trotz Typfehlern ein Ergebnis. Er warnt, aber er hält nicht an.

5:07 Wenn Fehler den Build blockieren sollen, müssen Sie das ausdrücklich einschalten. Und drittens der Typ `any`. Er ist die Notausgangstür, und genau deshalb gefährlich: Einmal gesetzt, breitet er sich durch den Code aus und hebelt die Prüfung still wieder aus.

Das Typsystem

5:23 Damit zum Herzstück des Tages. Alles, was danach kommt, baut auf diesen Bausteinen auf — deshalb nehmen wir uns hier bewusst mehr Zeit als anderswo. Eine Typannotation beschreibt die Form eines Wertes — mehr nicht. Sie sagen: Dieses Ding ist eine Zahl, jenes hat die Felder Name und Alter. Und der Compiler prüft dann bei jeder Zuweisung und jedem Aufruf, ob es zusammenpasst.

5:46 Denken Sie an ein Formular mit beschrifteten Feldern: Wo „Postleitzahl" steht, gehört keine Adresse hin, und jemand schaut nach. Die Bausteine dafür sind überschaubar: primitive Typen für die einfachen Werte, Interfaces für Objektformen, Type Aliases als flexible Namen und Enums für feste Wertemengen. Diese vier decken den größten Teil des Alltags ab.

6:08 Vier konkrete Gewinne. Erstens entstehen klare Verträge zwischen Funktionen und Modulen — man muss nicht mehr im fremden Code nachschauen, was erwartet wird. Zweitens fallen Tippfehler bei Eigenschaftsnamen sofort auf; das klingt banal, gehört aber zu den häufigsten und ärgerlichsten Fehlern überhaupt, weil sie still undefinierte Werte liefern.

6:28 Drittens bündeln Enums erlaubte Werte an einer einzigen Stelle, statt sie als Zeichenketten über das Projekt zu verstreuen. Und viertens dokumentieren Interfaces Ihre Datenstrukturen an der Stelle, an der sie definiert sind — lebendige Dokumentation, die nie veraltet. Oben sehen Sie die Grundformen: Zeichenkette, Zahl, Wahrheitswert und eine Liste von Zeichenketten.

6:50 In der Praxis schreibt man diese Annotationen übrigens selten hin — der Compiler leitet sie aus dem zugewiesenen Wert selbst her. Explizit werden Sie vor allem bei Funktionsparametern und dort, wo die Herleitung zu unpräzise wäre. Unten ein Enum: eine benannte Sammlung erlaubter Werte, hier drei Rollen. Worauf es ankommt — statt an zwanzig Stellen die Zeichenkette „Admin" zu tippen und sich einmal zu vertippen, gibt es genau eine Quelle der Wahrheit, und der Editor schlägt die Möglichkeiten vor.

7:19 Hier die beiden Werkzeuge für eigene Typen. Oben ein Interface — es beschreibt die Form eines Objekts. Beachten Sie das Fragezeichen: Es markiert ein optionales Feld. Das ist mehr als Kosmetik, denn der Compiler zwingt Sie danach, den Fall zu behandeln, in dem es fehlt. Unten ein Type Alias, und zwar in seiner stärksten Rolle: Er beschreibt hier einen Wert, der entweder das eine oder das andere sein darf.

7:43 Solche Vereinigungstypen sind eines der ausdrucksstärksten Mittel der Sprache — man kann damit Zustände modellieren, die in JavaScript nur als Kommentar existierten. Diese Gegenüberstellung führt zu einer der häufigsten Fragen überhaupt — und die ehrliche Antwort lautet: Die beiden überschneiden sich stark, und in den meisten Fällen funktionieren beide.

8:05 Interessant sind die Ränder. Vereinigungstypen kann nur das eine, das Zusammenführen mehrerer Deklarationen unter demselben Namen nur das andere — was Sie brauchen, wenn Sie Typen fremder Bibliotheken erweitern wollen. Für den Alltag reicht die Faustregel unten völlig: Objektformen als Interface, alles Übrige als Type Alias.

8:23 Wichtiger als die Wahl ist, dass ein Team sich auf eine Linie einigt und dabei bleibt. Jetzt beschreiben Sie selbst ein Datenmodell. Nehmen Sie etwas aus Ihrer eigenen Arbeit — einen Nutzer, eine Bestellung, was Ihnen vertraut ist — und typisieren Sie es. Die eine harte Regel: kein `any`. Wenn es irgendwo nicht ohne geht, ist das genau die interessante Stelle, über die wir danach sprechen.

8:45 Fertig sind Sie, wenn der Compiler einen absichtlich falschen Wert bei einer Eigenschaft anmeckert. Achten Sie darauf, Vereinigungstypen dort einzusetzen, wo ein Feld wirklich nur bestimmte Werte annehmen darf — das ist der Moment, in dem Typen anfangen, echte Arbeit zu leisten. Drei typische Schieflagen. Erstens die willkürliche Mischung von Interface und Type Alias — technisch harmlos, aber der Code liest sich danach uneinheitlich; deshalb lieber eine Regel im Team.

9:12 Zweitens werden Enums oft dort eingesetzt, wo ein einfacher Vereinigungstyp aus Zeichenketten schlanker wäre; Enums erzeugen im Gegensatz zu Typen echten Code im Ergebnis. Und drittens der wichtigste: Ein optionales Feld ohne Prüfung zu benutzen. Das Fragezeichen zu setzen und dann trotzdem blind zuzugreifen, verlagert das Problem nur — der strikte Modus wird Ihnen das später zurecht um die Ohren hauen.

Funktionen und Generics

9:36 Bis hierhin haben wir Daten beschrieben. Jetzt geht es um das, was mit ihnen passiert — und um die Frage, wie man Funktionen typsicher macht, ohne sie für jeden Datentyp neu zu schreiben. Eine Funktion typisieren heißt: sagen, was hineingeht und was herauskommt. Das ist der einfache Teil. Interessant wird es bei Funktionen, die mit ganz unterschiedlichen Typen arbeiten sollen — eine Funktion, die das erste Element einer Liste liefert, funktioniert für Zahlen genauso wie für Nutzerobjekte.

10:05 Generics sind die Antwort darauf. Stellen Sie sich einen Platzhalter vor, so wie eine Schablone: Die Form steht fest, das Material wird erst beim Ausstanzen festgelegt. Beim Aufruf leitet der Compiler den konkreten Typ meist von selbst her — Sie müssen ihn gar nicht hinschreiben. Warum lohnt sich der Aufwand? Weil Rückgabetypen das Verhalten einer Funktion dokumentieren, ohne dass jemand den Rumpf lesen muss.

10:29 Weil Generics verhindern, dass Sie dieselbe Logik dreimal für drei Datentypen schreiben — Duplikate sind Wartungsschulden. Weil die Typsicherheit dabei trotzdem erhalten bleibt, was der entscheidende Punkt ist: Die Alternative wäre, alles auf `any` zu setzen, und damit hätten Sie zwar Wiederverwendbarkeit, aber die Prüfung wieder verloren.

10:49 Genau dieses Abwägen — allgemein genug, aber nicht beliebig — ist der Kern guter Typisierung. Drei Varianten derselben Idee. Oben die klassische Form mit Typ für den Parameter und für die Rückgabe. In der Mitte etwas, das man häufig braucht: ein Parameter mit Standardwert. Beachten Sie, dass hier kein Typ steht — der Compiler leitet ihn aus dem Standardwert her, das ist eine legitime Abkürzung. Unten dieselbe Funktion als Kurzschreibweise.

11:16 Worauf es ankommt: Den Rückgabetyp explizit hinzuschreiben, ist optional, aber oft eine gute Idee. Er wirkt wie eine Zusicherung — wenn Sie innerhalb der Funktion versehentlich etwas anderes zurückgeben, merken Sie es sofort und nicht erst beim Aufrufer. Hier das Prinzip in seiner kleinstmöglichen Form. Das T in den spitzen Klammern ist nichts weiter als ein Platzhalter für „irgendein Typ, aber durchgängig derselbe".

11:42 Die Funktion nimmt eine Liste von T und gibt ein T zurück. Was daran wertvoll ist, zeigen die beiden Aufrufe unten: Beim ersten geben Sie den Typ vor, beim zweiten erkennt ihn der Compiler selbst am übergebenen Wert. Danach weiß die Entwicklungsumgebung genau, womit Sie es zu tun haben — mit einer Zahl oder einer Zeichenkette — und schlägt die passenden Methoden vor.

12:03 Ein Buchstabe, große Wirkung. Schreiben Sie eine solche Funktion selbst. Der Klassiker ist die Funktion für das erste Element, aber nehmen Sie gern etwas anderes — das Letzte, das Maximum nach einem Kriterium, was Sie mögen. Der Erfolg zeigt sich nicht im Ausführen, sondern im Editor: Rufen Sie die Funktion einmal mit Zahlen und einmal mit Zeichenketten auf und schauen Sie, was Ihnen die Entwicklungsumgebung beim Ergebnis anbietet.

12:28 Wenn dort jeweils die passenden Methoden erscheinen, haben Sie es richtig gemacht. Genau dieses Erlebnis ist es, das Generics für viele vom abstrakten Konzept zum Werkzeug macht. Auch hier drei Punkte. Erstens: Generics sind kein Selbstzweck. Wenn eine Funktion tatsächlich nur mit einem Typ arbeitet, dann schreiben Sie diesen Typ hin — ein unnötiger Platzhalter macht den Code nur schwerer lesbar.

12:51 Zweitens der Rückfall auf `any`, wenn ein Generic zu kompliziert wird; das ist verständlich, aber es löst das Problem nicht, es versteckt es. Und drittens: Wer den Rückgabetyp weglässt, kann Fehler verschleppen — die Funktion gibt dann klaglos etwas Unerwartetes zurück, und auffallen wird es erst weit entfernt an der Verwendungsstelle.

Objekte und Arrays

13:11 In der Praxis haben Sie es selten mit einzelnen Zahlen zu tun, sondern mit verschachtelten Strukturen — Listen von Objekten, Objekte mit Listen darin. Schauen wir uns an, wie das typsicher bleibt. Komplexe Daten beschreiben Sie über Objekt-Typen, Arrays und, für Sonderfälle, Tupel. Der Compiler prüft dann nicht nur die Zuweisung, sondern auch jeden Zugriff: auf Felder, auf Indizes, auf Ergebnisse von Array-Methoden.

13:35 Und hier passiert etwas sehr Angenehmes, das man leicht übersieht — innerhalb einer Array-Methode kennt der Compiler den Elementtyp bereits. Sie bekommen also beim Durchlaufen einer Liste von Produkten Vorschläge für Produkteigenschaften, ohne irgendetwas zusätzlich hinschreiben zu müssen. Diese Weitergabe von Typinformationen durch die Kette hindurch ist einer der Gründe, warum sich das im Alltag so gut anfühlt.

13:59 Vier Effekte im Alltag. Zugriffe auf Felder, die es gar nicht gibt, werden verhindert — Schluss mit dem stillen `undefined`, das erst drei Funktionen weiter zum Absturz führt. Array-Methoden kennen den Elementtyp automatisch, wie eben gesehen. Verschachtelte Strukturen bleiben nachvollziehbar, weil Sie sich jederzeit anzeigen lassen können, was auf welcher Ebene liegt.

14:20 Und schließlich `readonly`: die Möglichkeit, eine Struktur ausdrücklich als unveränderlich zu kennzeichnen. Das klingt nach einer Kleinigkeit, ist aber genau das, was wir im JavaScript-Modul über unveränderliche Daten besprochen haben — jetzt vom Compiler durchgesetzt statt nur gut gemeint. Ein alltägliches Beispiel: ein Warenkorb. Oben die Form eines Produkts, darunter eine Liste davon. Der interessante Teil steht unten.

14:46 Beim Zusammenrechnen der Preise weiß der Compiler, dass jedes Element ein Produkt ist — und damit, dass es ein Preisfeld hat. Vertippen Sie sich beim Feldnamen, sagt er es Ihnen sofort. Worauf es hier ankommt: Sie haben an genau einer Stelle beschrieben, wie ein Produkt aussieht, und profitieren davon im ganzen weiteren Code, ohne es zu wiederholen.

15:07 Das ist der Hebel, um den es bei Typen geht. Zwei Spezialwerkzeuge. Oben ein Tupel: eine Liste mit fester Länge und festen Typen je Position. Man braucht es seltener als Arrays, aber wenn, dann ist es sehr nützlich — Koordinatenpaare etwa, oder, und das werden Sie in React ständig sehen, der Rückgabewert eines Hooks aus Wert und Setzfunktion.

15:28 Unten die schreibgeschützte Variante: Der Compiler verhindert das Hinzufügen. Es ist kein Schutz zur Laufzeit, sondern eine Absichtserklärung, die durchgesetzt wird — und genau das reicht meist, um versehentliche Änderungen zu unterbinden. Bauen Sie den Warenkorb selbst. Typisieren Sie die Liste, füllen Sie sie und werten Sie sie anschließend mit den Methoden aus, die Sie im JavaScript-Modul kennengelernt haben.

15:53 Das entscheidende Erfolgskriterium ist ein negatives: Sie sollen dabei keinen einzigen Cast brauchen. Wenn Sie an einer Stelle den Compiler mit einer Typumdeutung überstimmen müssen, stimmt meist die Modellierung darüber nicht. Genau solche Stellen sind es wert, im Kurs besprochen zu werden — bringen Sie sie also gern mit, statt sie stillschweigend wegzucasten.

16:13 Drei Wege, sich die Vorteile selbst zu nehmen. Der erste: den allgemeinen Objekt-Typ verwenden statt eines konkreten Interface — damit haben Sie zwar formal einen Typ, aber keinerlei Wissen über die Felder. Der zweite: eine Liste als Liste von `any` deklarieren; dann ist der Elementtyp weg und mit ihm die ganze Unterstützung in den Methoden.

16:33 Und der dritte, subtilste: Zugriff über einen Index ohne Prüfung. Der Compiler nimmt standardmäßig an, dass an jeder Position etwas liegt — bei einer leeren Liste stimmt das nicht. Dafür gibt es eine Einstellung, die sich lohnt.

Statische Typprüfung

16:47 Jetzt kommen wir zu dem Punkt, an dem sich der ganze bisherige Aufwand auszahlt. Bisher haben wir Typen beschrieben — jetzt geht es darum, den Compiler wirklich arbeiten zu lassen. Statisch heißt: vor der Ausführung. Der Compiler liest Ihren Code, ohne ihn laufen zu lassen, und prüft, ob alles zusammenpasst. Der Unterschied zur klassischen Fehlersuche ist fundamental.

17:10 Ein Test findet Fehler auf den Wegen, die er abläuft — die statische Prüfung schaut auf alle Wege gleichzeitig, auch auf die, die nur selten genommen werden. Sie ersetzt keine Tests, aber sie räumt eine ganze Fehlerklasse ab, bevor der erste Test überhaupt startet. Und sie tut es in Echtzeit, während Sie tippen. Das ist der Grund, warum sich das im Alltag so verändert anfühlt.

17:32 Vier Argumente, die sich in der Praxis bewähren. Ganze Fehlerklassen verschwinden vor dem Deploy — nicht alle Fehler, das wäre unehrlich, aber die langweiligen, häufigen. Refactorings werden sicher: Sie benennen etwas um, und der Compiler zeigt Ihnen jede betroffene Stelle. Wer das einmal in einem großen Projekt erlebt hat, möchte nicht zurück.

17:54 Der strikte Modus erzwingt zudem saubere Typen, statt sie zu empfehlen. Und der vielleicht wichtigste Punkt: Null- und undefinierte Werte werden abgefangen. Das ist historisch die häufigste Fehlerursache in JavaScript überhaupt. Der Weg zur strengen Prüfung hat fünf Stationen, und die Reihenfolge ist wichtig. Zuerst die Einstellung setzen — danach werden Sie erst einmal viele Meldungen sehen.

18:18 Dann die `any`-Stellen aufräumen und Prüfungen für optionale Werte ergänzen; das ist die eigentliche Arbeit. Anschließend nehmen Sie die reine Typprüfung in die Bauautomatisierung auf, damit niemand sie umgehen kann. Und der fünfte Punkt ist weniger technisch als kulturell: Typfehler müssen im Team als echte Blocker gelten. Eine Prüfung, die alle rot ignorieren, ist keine Prüfung.

18:41 Hier sehen Sie die wichtigste Einzelprüfung des strikten Modus in Aktion. Der Parameter ist optional, kann also fehlen. Die auskommentierte Zeile wäre in JavaScript völlig üblich — und würde in dem Moment, in dem tatsächlich nichts übergeben wird, mit einem Laufzeitfehler abbrechen. Der Compiler lässt sie gar nicht erst zu. Die Zeile darunter zeigt die Lösung: erst prüfen, dann zugreifen. Worauf es ankommt — das ist keine Schikane.

19:07 Der Compiler zwingt Sie lediglich, eine Entscheidung zu treffen, die Sie ohnehin treffen müssten, nur eben jetzt und nicht später im Fehlerprotokoll. Schalten Sie in Ihrem Übungsprojekt die strenge Prüfung ein und arbeiten Sie sich durch die Meldungen. Ziel ist ein Projekt, das anschließend fehlerfrei durchkompiliert — ohne dass Sie Fehler weggecastet haben.

19:28 Zur Gegenprobe: Entfernen Sie danach eine Ihrer Null-Prüfungen und beobachten Sie, ob der Compiler das zuverlässig anmeckert. Wenn ja, arbeitet die Prüfung wirklich für Sie. Rechnen Sie mit ein paar Stellen, an denen Sie überlegen müssen, was eigentlich richtig wäre — das ist kein Zeitverlust, sondern genau der Erkenntnisgewinn.

19:47 Der größte Fehler: den strikten Modus erst spät zu aktivieren. In einem gewachsenen Projekt prasseln dann hunderte Meldungen auf einmal herunter, und die typische Reaktion ist, ihn wieder auszuschalten. Beginnen Sie also möglichst am ersten Tag. Der zweite Punkt hängt damit zusammen: Fehler mit einer Typumdeutung oder `any` wegzuräumen fühlt sich wie Fortschritt an, ist aber nur ein Zurückstellen.

20:09 Und der dritte: Die Kommentaranweisung, mit der man den Compiler für eine Zeile stummschaltet, ist ein legitimes Notventil — als Dauerlösung höhlt sie das ganze System aus.

TypeScript in React

20:20 Und damit zur Zusammenführung. Alles, was wir heute besprochen haben, treffen Sie in React an genau drei Stellen wieder: bei Props, bei State und bei Events. Schauen wir uns an, wie das aussieht. In React beschreibt TypeScript vor allem drei Dinge: die Eigenschaften, die eine Komponente von außen bekommt, den Zustand, den sie selbst hält, und die Ereignisse, auf die sie reagiert.

20:43 Der entscheidende Gedanke dabei: Eine Komponente wird damit zu einem überprüfbaren Vertrag zwischen Eltern und Kind. Vorher stand in der Dokumentation, welche Werte erwartet werden — jetzt steht es im Code, und die Einhaltung wird geprüft. Das ist besonders wertvoll, wenn andere Ihre Komponenten verwenden: Sie müssen nicht mehr erklären, wie man sie benutzt, der Editor tut es.

21:05 Vier sehr konkrete Alltagsvorteile. Falsche Eigenschaften werden schon an der Verwendungsstelle gemeldet, nicht erst, wenn die Komponente leer bleibt. Autovervollständigung für Props und Hooks — Sie tippen den Anfang und bekommen angeboten, was möglich ist. Zustandsverwaltung wird typsicher, was besonders bei komplexeren Zuständen viel wert ist. Und in Summe: deutlich weniger Laufzeitfehler in der Oberfläche.

21:29 Das ist der Bereich, in dem Fehler am sichtbarsten sind, weil sie beim Nutzer direkt auf dem Bildschirm landen. Hier zahlt sich Typsicherheit am schnellsten aus. Das Grundmuster, das Sie ab jetzt bei jeder Komponente schreiben werden. Oben ein Interface, das die erwarteten Eigenschaften beschreibt — eine verpflichtende, eine optionale.

21:49 Unten die Komponente, die diese Eigenschaften direkt beim Empfang auseinandernimmt und für die optionale einen Standardwert setzt. Worauf es ankommt: Von diesem Moment an prüft der Compiler jede Verwendung dieser Komponente. Wer sie ohne den Titel einbindet, bekommt eine Fehlermeldung an der Einbindungsstelle — und wer wissen will, was die Komponente kann, muss nur auf das Interface schauen.

22:12 Zwei Stellen, an denen Typen in React besonders viel Nutzen bringen. Oben ein Zustand, der ausdrücklich auch leer sein darf. Genau diese Angabe zwingt Sie später, den Ladezustand zu behandeln, statt blind auf Nutzerdaten zuzugreifen, die noch gar nicht da sind — ein sehr häufiger Fehler in React-Anwendungen. Unten der Typ eines Eingabe-Ereignisses. Zugegeben, diese Typnamen wirken zunächst sperrig.

22:36 Der Gewinn ist aber real: Der Editor weiß danach, dass das Ziel ein Eingabefeld ist und einen Wert hat. Man muss diese Namen nicht auswendig können, nur wissen, wo man sie findet. Zum Abschluss bauen Sie eine eigene Komponente mit typisierten Eigenschaften und typisiertem Zustand. Der Test ist einfach und aussagekräftig: Binden Sie die Komponente einmal absichtlich falsch ein — lassen Sie eine Pflichteigenschaft weg — und schauen Sie, ob der Editor es markiert.

23:05 Wenn ja, funktioniert Ihr Vertrag. Wer mehr will, typisiert den Zustand mit dem Reducer-Hook statt mit dem einfachen. Das ist deutlich anspruchsvoller, zeigt aber besonders schön, wie Typen komplexe Zustandsübergänge absichern. Drei Punkte aus der Praxis. Der erste ist ein Klassiker mit Geschichte: Der vordefinierte Komponententyp aus React wurde lange empfohlen, brachte aber stillschweigend Kind-Elemente mit, die niemand deklariert hatte.

23:31 Heute schreibt man die Props einfach direkt hin. Zweitens: `any` für Event-Handler ist verlockend, weil die richtigen Typnamen lang sind — aber damit verlieren Sie genau dort die Sicherheit, wo Nutzereingaben ankommen. Und drittens: Wenn Props-Interface und Standardwerte auseinanderlaufen, entsteht ein Vertrag, der etwas anderes verspricht, als die Komponente tut.

23:52 Fassen wir zusammen. TypeScript ist JavaScript plus statische Typen — kein Neuanfang, sondern ein Ausbau, den Sie schrittweise gehen können. Sie haben die Bausteine kennengelernt: Interfaces, Generics und Vereinigungstypen. Sie wissen, was der strikte Modus leistet und warum es sich lohnt, ihn von Anfang an einzuschalten.

24:11 Und Sie haben gesehen, wie das in React zusammenkommt — bei Props, Hooks und Events. Was jetzt noch fehlt, ist Übung. Die Typen fühlen sich in den ersten Tagen nach Mehrarbeit an und nach zwei Wochen nach Selbstverständlichkeit.

Danke!

24:26 Damit sind wir am Ende des TypeScript-Moduls. Alle Materialien liegen in der Freigabe — die Codebeispiele eignen sich gut zum Nachschlagen, wenn Sie in Ihrem eigenen Projekt anfangen. Bei Fragen finden Sie uns unter der angegebenen Adresse. Im nächsten Modul wenden wir uns React selbst zu: Komponenten, JSX, Props und Rendering.

24:46 Vieles von dem, was wir heute typisiert haben, wird dort mit Leben gefüllt — und Sie werden merken, wie gut sich beides ergänzt. Vielen Dank.