Seite 3 - TypeScript

Overloads erlauben es, für eine einzelne Funktion mehrere aufrufbare Signaturen zu definieren, während im Hintergrund nur eine einzige Implementierung existiert. Richtig eingesetzt liefern sie deutlich präzisere Rückgabetypen als eine einzelne Signatur mit Union-Types, bringen aber auch eigene Fallstricke mit, etwa bei der Auflösungsreihenfolge oder bei unerreichbaren Signaturen.

Eine Select-Komponente für Produkte, eine zweite für Nutzer, eine dritte für Kategorien, jede fast identisch, nur mit anderem Datentyp: Genau dieses Muster lösen generische React-Komponenten. Statt für jeden Datentyp eine eigene Komponente zu duplizieren, wird der Typ selbst zum Parameter, und der Compiler prüft bei jeder Verwendung, ob Daten, Callback und Rendering zueinander passen. Dieser Artikel zeigt, wie generische React-Komponenten in der Praxis entstehen, inklusive JSX-Syntax, Constraints und forwardRef.

Wer TypeScript-Interfaces und JSON Schema getrennt pflegt, verliert früher oder später die Synchronität zwischen beiden: Ein Feld wird im Typ umbenannt, das Schema bleibt beim alten Namen stehen, und ein Konsument validiert gegen Regeln, die nicht mehr zur echten API passen. Werkzeuge wie ts-json-schema-generator und zod-to-json-schema leiten das Schema direkt aus dem TypeScript-Code ab und machen den Typ zur einzigen Quelle der Wahrheit.

Wer sich für Runtime Validation in TypeScript entscheidet, steht vor drei sehr unterschiedlichen Philosophien: io-ts mit funktionalem fp-ts-Ökosystem, Zod mit fluent, objektorientierter API und breitem Ökosystem, sowie Valibot mit einer modularen, tree-shakebaren Architektur für minimale Bundle-Größen. Dieser Artikel vergleicht alle drei anhand von API-Stil, Fehlerbehandlung, Bundle-Kosten und Migrationsaufwand, damit die Wahl zur eigenen Projektarchitektur passt statt nach Trend getroffen zu werden.

Statische Typen enden normalerweise an der Netzwerkgrenze: Der Client weiss nicht, was der Server zurueckgibt, ausser er verlaesst sich auf manuell gepflegte Interfaces oder generierte Client-Codes. tRPC schliesst diese Luecke, indem Router-Typen direkt vom Server importiert werden, ganz ohne REST-Konventionen, ohne GraphQL-Schema und ohne separaten Codegenerierungs-Schritt.

Ein TypeScript Transformer greift direkt in den Compiler-Durchlauf ein, noch bevor JavaScript entsteht, und verändert den abstrakten Syntaxbaum programmatisch. Das ermöglicht Dinge, die weder ein Linter noch ein einfaches Build-Skript leisten kann, etwa das automatische Entfernen von Debug-Code oder das Einfügen von Metadaten basierend auf tatsächlichen Typinformationen.

Ein bestehendes JavaScript Projekt komplett auf TypeScript umzustellen, klingt nach Wochen Stillstand. Wer TypeScript schrittweise einfuehrt, aktiviert allowJs, migriert Datei fuer Datei und erreicht am Ende strict Mode, ohne den Feature Betrieb jemals zu unterbrechen.

Exceptions in TypeScript sind unsichtbar fuer den Compiler: eine Funktion, die wirft, sieht in ihrer Signatur genauso aus wie eine, die niemals scheitert. Das Result Type Pattern macht Fehlerpfade explizit, indem Erfolg und Fehlschlag als typisierter Wert zurueckgegeben werden, den der Aufrufer aktiv behandeln muss.

Die meisten TypeScript-Style-Guides landen als lange Wiki-Seite, die einmal geschrieben und danach nie wieder gelesen wird. Ein Style Guide, der tatsächlich wirkt, definiert einen klaren Scope, setzt Regeln automatisiert mit ESLint durch und zeigt Konventionen an echten Beispielen statt in abstrakter Prosa.

Interface und Type Alias wirken auf den ersten Blick austauschbar, doch Declaration Merging, Union Types und die Fähigkeiten des TypeScript-Compilers sorgen für echte Unterschiede. Dieser Artikel zeigt anhand konkreter Beispiele, wann jede Variante technisch notwendig ist, welche Team-Konvention sich in großen Codebasen bewährt und wo Performance und Wartbarkeit tatsächlich auseinanderlaufen.