¿Por qué el 'as' en TypeScript suele ser peligroso?
Disponible en :
Sébastien TIMONER
Experto en desarrollo web y gestión de equipos técnicos, me especializo en la creación y optimización de soluciones digitales de alto rendimiento. Gracias a un profundo dominio de tecnologías modernas como React.js, Node.js, TypeScript, Symfony y Zephyr OS para IoT, garantizo el éxito de proyectos SaaS e IoT complejos, desde el diseño hasta la implementación, para empresas de diversos sectores, dentro de offroadLabs.
En offroadLabs, ofrezco servicios de desarrollo a medida, combinando experiencia técnica y enfoque colaborativo. Ya sea para crear una solución SaaS innovadora, desarrollar sistemas IoT con Zephyr OS, modernizar una aplicación existente o acompañar el desarrollo de habilidades de un equipo, me comprometo a proporcionar soluciones robustas y eficientes, adaptadas a las necesidades específicas de cada proyecto.
Estoy disponible para proyectos en la zona de Aix-en-Provence o en modalidad totalmente remota.
Utilizas TypeScript por la seguridad que aporta a tu código, pero seguramente has notado que el operador as permite forzar la compilación incluso cuando TypeScript sospecha tipos incompatibles. Esta flexibilidad puede ser tentadora, pero a menudo esconde trampas. Descubramos juntos por qué el uso excesivo de as puede introducir errores de ejecución y cómo evitar estas trampas.
as: errores ocultos en la compilaciónEn TypeScript, el operador as permite hacer lo que llamamos una aserción de tipo, es decir, decirle a TypeScript "Confía en mí, sé lo que hago." Sin embargo, esta herramienta puede ser a veces una mala idea, ya que elude las verificaciones de tipo. Cuando usas as, asumes la responsabilidad de garantizar que el tipo es correcto, incluso si TypeScript no puede verificarlo. Veamos esto con algunos ejemplos concretos.
as que no es realmente compatibleTomemos un ejemplo donde tienes un objeto de tipo Person con ciertas propiedades bien definidas, pero decides usar as para forzarlo a un tipo diferente, pensando que funcionará.
typescript
En este ejemplo, employee no tiene la propiedad role, pero TypeScript no devuelve un error durante la compilación gracias al as. Sin embargo, en ejecución, employee.role es undefined, lo que puede provocar errores si tu código espera un valor de tipo string.
as unknown asA veces, vemos desarrolladores usar casteos en cadena para forzar un tipo vía unknown, como en este ejemplo:
typescript
Aquí, tomamos un valor data que podría ser cualquier cosa, y lo casteamos a number vía unknown. En la compilación, todo parece funcionar, pero durante la ejecución, la suma produce NaN porque data era en realidad una cadena de caracteres.
Tomemos otro caso clásico donde forzamos un objeto parcialmente completado a un tipo completo pensando que todo irá bien:
typescript
El objeto partialProduct se convierte a Product aunque le falta la propiedad price. Esta ausencia no es detectada por TypeScript gracias al as, pero lleva a un undefined que puede generar errores de ejecución si este valor se utiliza sin verificación previa.
Para evitar los problemas generados por as, una buena práctica es validar los datos en tiempo de ejecución, especialmente si provienen de una fuente externa. Aquí es donde entra en escena Zod. Zod es una biblioteca de validación de esquemas en TypeScript que permite definir tipos seguros y validarlos en runtime.
Con Zod, en lugar de forzar un tipo con as, puedes validar y convertir los datos con un esquema predefinido. Por ejemplo:
typescript
En este ejemplo, Zod verifica que partialProduct respeta el esquema Product. Si faltan propiedades, Zod devuelve un error de validación en lugar de dejar pasar valores undefined. Gracias a Zod, aseguras tus datos y evitas errores de ejecución relacionados con tipos incompletos o incorrectos.
El operador as puede ser una solución rápida para eludir las verificaciones de TypeScript, pero introduce riesgos de errores de ejecución, especialmente cuando forzamos tipos sin validación. Utilizando una biblioteca como Zod, puedes validar tus datos en runtime y así aprovechar plenamente la seguridad de TypeScript, incluso en los casos donde as parecía la única solución.