Seite 6 - TypeScript

Ein TypeScript-Review, das nur auf Syntax achtet, übersieht die eigentlichen Risiken: any-Creep, unnötige as-Assertions, unlesbare Generic-Konstruktionen und Non-Null Assertions, die echte Fehlerquellen maskieren. Dieser Artikel zeigt die wichtigsten Red Flags erfahrener Reviewer, eine praktische Checkliste und einen Weg, Typsicherheit und Review-Tempo im Gleichgewicht zu halten.

Loading-Spinner, Fehlermeldung, Daten: Dieses Dreieck aus State tippt sich in jeder Komponente, die Daten von einer API lädt, fast identisch. Ein eigener Custom Hook bündelt dieses Muster an einer Stelle, bevor er automatisch zu jeder Komponente wandert, die ihn braucht, und zeigt gleichzeitig, wo der Eigenbau endet und eine Bibliothek wie TanStack Query beginnt.

Wer eine TypeScript-Bibliothek veröffentlicht, schreibt nicht einfach nur Code, sondern einen Vertrag mit fremden Projekten. Projektstruktur, tsconfig.json, Dual-Format-Build und das exports-Feld entscheiden darüber, ob eine TypeScript-Bibliothek in jedem Konsumenten-Setup reibungslos funktioniert oder täglich Supportanfragen erzeugt.

Wenn Frontend und Backend ihre eigenen, unabhängig gepflegten Typen für dieselbe API definieren, driften beide Seiten früher oder später auseinander, und der Fehler zeigt sich erst zur Laufzeit beim Kunden. Ein gemeinsam genutztes Contracts-Paket im TypeScript-Monorepo macht solche Abweichungen bereits beim Kompilieren sichtbar.

Das React Error Boundary Interface arbeitet intern mit dem Typ unknown fuer gefangene Fehler, was Fallback Komponenten oft zwingt, auf any oder unsichere Casts auszuweichen. Mit generischen Typparametern und Discriminated Error Types lassen sich Error Boundaries bauen, die dem Aufrufer konkrete, typisierte Fehlerinformationen liefern.

Wer TypeScript nur als PHP mit Typen begreift, stolpert schnell über strukturelle Typprüfung, Referenzsemantik bei Objekten und fehlende Nominal-Typisierung. Dieser Artikel erklärt den fundamentalen Unterschied zwischen primitiven und Object Types, zeigt TypeScripts Duck-Typing-Philosophie im direkten Vergleich zu PHP und macht die häufigsten Denkfehler beim Umstieg sichtbar.

Wer TypeScripts Typsystem nur als Annotation für Laufzeitwerte betrachtet, übersieht seine eigentliche Mächtigkeit. Conditional Types entsprechen If/Else, Mapped Types entsprechen ForEach, infer entspricht Pattern Matching, und Rekursion ist das einzige Kontrollflusskonstrukt. Zusammen bilden diese vier Bausteine eine vollständige funktionale Sprache, die zur Compile-Zeit ausgewertet wird und mit der sich sogar kleine Parser bauen lassen.

Eine TypeScript-Bibliothek mit Dutzenden internen Modulen erzeugt beim Standard-Build genauso viele einzelne Typdefinitionsdateien, ohne dass irgendwo sichtbar wird, was davon eigentlich zur öffentlichen API gehört. API Extractor löst genau dieses Problem: ein einziger Rollup, ein maschinenlesbarer API-Report als Contract-Test und Release Tags, die genau festlegen, was Konsumenten verwenden dürfen.

ESLint prüft Syntax und einfache Muster, aber sobald eine Regel wissen muss, welchen tatsächlichen Typ ein Ausdruck hat, reicht das nicht mehr aus. Die TypeScript Compiler API stellt Program, TypeChecker und Diagnostics als öffentliche Bausteine bereit, mit denen sich eigene, präzise typbasierte Prüfungen direkt auf dem echten Compiler aufbauen lassen.

Wer React-Props ohne klare Typen schreibt, verlässt sich auf Konventionen statt auf den Compiler. TypeScript macht aus stillschweigenden Annahmen über Props explizite Verträge: Welche Werte sind Pflicht, welche optional, welche Form dürfen Children annehmen und welche zusätzlichen HTML-Attribute soll eine Komponente durchreichen. Dieser Artikel zeigt, wie man React-Props von der ersten Interface-Definition bis zu erweiterten, wiederverwendbaren Komponenten sauber typisiert.