TypeScript Patterns, die Ihre Codebase verbessern

TypeScript hat sich von einem "nice-to-have" zu einem unverzichtbaren Werkzeug entwickelt. Aber TypeScript ist mehr als nur Typen an Funktionsparameter zu schreiben. Hier sind fünf Patterns, die ich in realen Projekten einsetze – von SvelteKit bis Node.js-Backends.

1. Discriminated Unions: Statt optionaler Properties verwende ich einen discriminator (z.B. "type" oder "status") um zwischen verschiedenen Zuständen zu unterscheiden. Das eliminiert ganze Fehlerklassen: TypeScript versteht, welche Properties in welchem Zustand existieren. Besonders nützlich bei API-Responses und State-Machines.

2. Branded Types: Eine ID ist eine ID – aber eine User-ID ist nicht dasselbe wie eine Order-ID, auch wenn beide technisch strings sind. Mit Branded Types unterscheidet TypeScript zwischen semantisch unterschiedlichen Typen. Das verhindert Verwechslungen und macht den Code selbstdokumentierend.

3. const assertions und satisfies: Der `as const`-Operator friert Literal-Typen ein – praktisch für Konfigurationen und Enums ohne den Overhead echter Enums. Der `satisfies`-Operator prüft, ob ein Wert einem Typ entspricht, ohne den Typ zu verbreitern.

4. Template Literal Types: Seit TypeScript 4.1 können Sie String-Literal-Typen mit Template-Literals kombinieren. Ideal für Event-Namen, CSS-Klassen oder API-Routen, bei denen die Struktur feststeht aber konkrete Werte variieren. TypeScript prüft zur Compile-Zeit.

5. Conditional Types mit infer: Der `infer`-Keyword in Conditional Types extrahiert Teil-Typen. Ein Klassiker: Den Return-Type einer Funktion, den Payload-Type eines Promises oder den Item-Type eines Arrays aus dem Container-Typ zu gewinnen. Spart Boilerplate und hält Utility-Types generisch.

Diese Patterns sind kein theoretischer Schnickschnack – sie zahlen sich in größeren Codebasen aus. Weniger Runtime-Errors, bessere IDE-Unterstützung und Code, der seine Absicht explizit kommuniziert. TypeScript richtig eingesetzt ist kein Kostentreiber, sondern eine Investition in Wartbarkeit.

Ein letzter Tipp: Übertreiben Sie es nicht. Nicht jede Funktion braucht ein eigenes conditional type. Gute TypeScript-Entwickler finden die Balance zwischen Typsicherheit und Lesbarkeit. Wenn Sie dreimal so viel TypeScript wie Business-Logik schreiben, ist etwas falsch.