¿Por qué el 'as' en TypeScript suele ser peligroso?

31/10/2024

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.

El problema del `as`: errores ocultos en la compilación

En 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.

Ejemplo 1: Forzar un tipo con `as` que no es realmente compatible

Tomemos 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
1type Person = {
2  name: string;
3  age: number;
4};
5
6type Employee = {
7  name: string;
8  age: number;
9  role: string;
10};
11
12const person: Person = { name: 'Alice', age: 30 };
13
14// Fuerza person a Employee, aunque 'role' no está definido
15const employee = person as Employee;
16
17console.log(employee.role); // Error de ejecución: 'role' es undefined

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.

Ejemplo 2: Eludir las verificaciones con `as unknown as`

A veces, vemos desarrolladores usar casteos en cadena para forzar un tipo vía unknown, como en este ejemplo:

typescript
1function processData(data: any) {
2  // Fuerza data a número, aunque no lo sea
3  const numberData = data as unknown as number;
4  console.log(numberData + 10);
5}
6
7processData('texto'); // Error de ejecución: NaN

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.

Ejemplo 3: Manipular objetos parciales

Tomemos otro caso clásico donde forzamos un objeto parcialmente completado a un tipo completo pensando que todo irá bien:

typescript
1type Product = {
2  id: number;
3  name: string;
4  price: number;
5};
6
7const partialProduct = { id: 1, name: 'Book' } as Product;
8
9console.log(partialProduct.price); // Error de ejecución: 'price' es undefined

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.

Cómo evitar errores con Zod

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
1import { z } from 'zod';
2
3// Definición de un esquema para Product
4const ProductSchema = z.object({
5  id: z.number(),
6  name: z.string(),
7  price: z.number(),
8});
9
10// Validación de datos con Zod
11const result = ProductSchema.safeParse(partialProduct);
12
13if (result.success) {
14  const product = result.data;
15  console.log('Producto válido:', product);
16} else {
17  console.error('Error de validación:', result.error.errors);
18}

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.

Conclusión

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.