Sébastien TIMONER
Als Experte für Webentwicklung und Teammanagement spezialisiere ich mich auf die Erstellung und Optimierung hochleistungsfähiger digitaler Lösungen. Mit umfassender Expertise in modernen Technologien wie React.js, Node.js, TypeScript, Symfony und Zephyr OS für IoT stelle ich bei offroadLabs den Erfolg komplexer SaaS- und IoT-Projekte von der Konzeption bis zur Produktion für Unternehmen verschiedener Branchen sicher.
Bei offroadLabs biete ich maßgeschneiderte Entwicklungsdienstleistungen, die technische Expertise mit einem kollaborativen Ansatz verbinden. Ob bei der Erstellung einer innovativen SaaS-Lösung, der Entwicklung von IoT-Systemen mit Zephyr OS, der Modernisierung einer bestehenden Anwendung oder der Unterstützung bei der Weiterbildung eines Teams - ich setze mich für die Bereitstellung robuster und leistungsstarker Lösungen ein, die auf die spezifischen Bedürfnisse jedes Projekts zugeschnitten sind.
Ich bin verfügbar für Projekte im Raum Aix-en-Provence oder vollständig remote.
Du nutzt TypeScript für die Sicherheit, die es deinem Code bietet, aber du hast sicherlich bemerkt, dass der as
-Operator die Kompilierung erzwingt, selbst wenn TypeScript inkompatible Typen vermutet. Diese Flexibilität kann verlockend sein, verbirgt aber oft Fallstricke. Lass uns gemeinsam entdecken, warum die übermäßige Verwendung von as
zu Laufzeitfehlern führen kann und wie man diese Fallen vermeidet.
as
: Versteckte Fehler bei der KompilierungIn TypeScript ermöglicht der as
-Operator eine sogenannte Type Assertion, das heißt, du sagst TypeScript "Vertrau mir, ich weiß, was ich tue." Dieses Werkzeug kann jedoch manchmal eine schlechte Idee sein, da es die Typüberprüfungen umgeht. Wenn du as
verwendest, übernimmst du die Verantwortung dafür, dass der Typ wirklich korrekt ist, auch wenn TypeScript dies nicht überprüfen kann. Schauen wir uns das anhand einiger konkreter Beispiele an.
as
, der nicht wirklich kompatibel istNehmen wir ein Beispiel, bei dem du ein Objekt vom Typ Person
mit bestimmten definierten Eigenschaften hast, aber du entscheidest dich, as
zu verwenden, um es zu einem anderen Typ zu zwingen, in der Annahme, dass es funktionieren wird.
typescript
In diesem Beispiel hat employee
nicht die Eigenschaft role
, aber TypeScript meldet aufgrund des as
keinen Fehler bei der Kompilierung. Zur Laufzeit ist employee.role
jedoch undefined
, was zu Fehlern führen kann, wenn dein Code einen Wert vom Typ string
erwartet.
as unknown as
Manchmal sieht man Entwickler verkettete Typumwandlungen über unknown
verwenden, wie in diesem Beispiel:
typescript
Hier nehmen wir einen Wert data
, der alles sein könnte, und wandeln ihn über unknown
in number
um. Bei der Kompilierung scheint alles zu funktionieren, aber zur Laufzeit ergibt die Addition NaN
, weil data
tatsächlich ein String war.
Betrachten wir einen weiteren klassischen Fall, bei dem wir ein teilweise ausgefülltes Objekt zu einem vollständigen Typ zwingen und denken, dass alles gut gehen wird:
typescript
Das Objekt partialProduct
wird in Product
umgewandelt, obwohl die Eigenschaft price
fehlt. Dieses Fehlen wird von TypeScript aufgrund des as
nicht erkannt, führt aber zu einem undefined
, das Laufzeitfehler verursachen kann, wenn dieser Wert ohne vorherige Überprüfung verwendet wird.
Um die durch as
verursachten Probleme zu vermeiden, ist es eine gute Praxis, die Daten zur Laufzeit zu validieren, insbesondere wenn sie aus einer externen Quelle stammen. Hier kommt Zod ins Spiel. Zod ist eine Schema-Validierungsbibliothek für TypeScript, die es ermöglicht, sichere Typen zu definieren und sie zur Laufzeit zu validieren.
Mit Zod kannst du, anstatt einen Typ mit as
zu erzwingen, Daten mit einem vordefinierten Schema validieren und konvertieren. Zum Beispiel:
typescript
In diesem Beispiel überprüft Zod, ob partialProduct
dem Product
-Schema entspricht. Wenn Eigenschaften fehlen, gibt Zod einen Validierungsfehler zurück, anstatt undefined
-Werte durchzulassen. Mit Zod sicherst du deine Daten ab und vermeidest Laufzeitfehler durch unvollständige oder falsche Typen.
Der as
-Operator kann eine schnelle Lösung sein, um TypeScript-Überprüfungen zu umgehen, aber er führt zu Laufzeitfehlerrisiken, besonders wenn Typen ohne Validierung erzwungen werden. Mit einer Bibliothek wie Zod kannst du deine Daten zur Laufzeit validieren und so die Sicherheit von TypeScript voll ausnutzen, auch in Fällen, in denen as
die einzige Lösung zu sein schien.