Einleitung: Warum TypeScript Anfänger beißt, oder wie man das erste Projekt nicht vermasselt
\n\nHaben Sie jemals das Gefühl gehabt, dass TypeScript wie ein strenger Lehrer ist, der für jede Kleinigkeit eine schlechte Note gibt? Wenn ja – willkommen im Club. Jeder zweite Anfänger, der von JavaScript auf TypeScript umsteigt, macht dieselben Fehler. Und das ist normal: TypeScript ist tatsächlich schwieriger, es erfordert Disziplin und ein Verständnis von Typen.
\n\nAber es gibt auch eine gute Nachricht: Die meisten Fehler beim Erlernen von TypeScript lassen sich vorhersagen und vermeiden. In diesem Artikel habe ich die 7 häufigsten Fallstricke zusammengestellt, auf die angehende Entwickler treten. Wir werden jeden Fehler mit Codebeispielen analysieren, erklären, warum er schlecht ist, und zeigen, wie man es richtig macht.
\n\nWenn Sie gerade erst mit TypeScript begonnen haben oder bereits ein paar Erfahrungen gesammelt haben – dieser Artikel spart Ihnen Stunden des Debuggings und Nerven. Los geht's!
\n\nFehler Nr. 1: Unkontrollierte Verwendung von any (die Quelle allen Übels)
\n\nWas Anfänger tun
\nDer häufigste Fehler unter denen, die TypeScript lernen, ist, überall any zu schreiben. Es scheint: „Na und, ich habe den Typ nicht angegeben, der Code funktioniert doch!“.
// ❌ Schlecht: any zerstört den gesamten Nutzen von TypeScript\nfunction processData(data: any) {\n console.log(data.name.toUpperCase());\n return data.price * 2;\n}\n\nconst result = processData({ name: "Laptop", price: 500 });\n// Alles funktioniert... bis man null übergibt\nprocessData(null); // Fehler zur Laufzeit!\n\nWarum das ein Fehler ist
\nany ist ein schwarzes Loch in TypeScript. Wenn Sie any schreiben, sagen Sie dem Compiler: „Geh weg, ich kümmere mich selbst darum.“ Und er geht weg. Sie verlieren die Autovervollständigung, die Typprüfung und den Schutz vor dummen Fehlern. TypeScript wird wieder zu JavaScript – mit all seinen Nachteilen.
Wie man es behebt
\nVerwenden Sie konkrete Typen. Wenn der Typ im Voraus unbekannt ist – unknown ist Ihr Freund. Es zwingt Sie, die Daten vor der Verwendung zu überprüfen.
// ✅ Gut: konkrete Typen und unknown\nfunction processData(data: { name: string; price: number }) {\n console.log(data.name.toUpperCase());\n return data.price * 2;\n}\n\n// Oder wenn der Typ wirklich unbekannt ist:\nfunction safeProcess(data: unknown) {\n if (typeof data === 'object' && data !== null && 'name' in data) {\n // Jetzt weiß TypeScript, dass data ein Objekt mit dem Feld name ist\n console.log((data as { name: string }).name);\n }\n}\n\nTipp: Aktivieren Sie die Regel no-explicit-any in ESLint – sie verhindert, dass Sie any ohne triftigen Grund verwenden.
Fehler Nr. 2: Ignorieren des strict mode (oder „warum bei mir alles funktioniert, aber nicht richtig“)
\n\nWas Anfänger tun
\nViele angehende Entwickler deaktivieren beim Erlernen von TypeScript den strikten Modus in der tsconfig.json oder aktivieren ihn gar nicht erst. Angeblich „reicht das ja so, weniger Kompilierungsfehler“.
// ❌ Schlecht: strict: false\n// tsconfig.json\n{\n "compilerOptions": {\n "strict": false, // Fehler!\n "noImplicitAny": false,\n "strictNullChecks": false\n }\n}\n\n// Jetzt wird dieser Code ohne Fehler kompiliert:\nfunction greet(name: string | null) {\n console.log(name.toUpperCase()); // Potenzielles null!\n}\ngreet(null); // Runtime error: Cannot read properties of null\n\nWarum das ein Fehler ist
\nOhne den strikten Modus verliert TypeScript die Hälfte seiner Stärke. Sie erhalten keine Warnungen vor potenziellen null und undefined, prüfen keine Argumenttypen – und fangen am Ende Bugs in der Produktion.
Wie man es behebt
\nAktivieren Sie immer strict: true. Dies aktiviert alle strengen Prüfungen auf einmal.
// ✅ Gut: strict: true\n{\n "compilerOptions": {\n "strict": true,\n "target": "ES2020",\n "module": "ESNext"\n }\n}\n\n// Jetzt zwingt TypeScript Sie, null zu behandeln:\nfunction g