Saltar al contenido principal
Volver atrás

TypeScript #1: La Inferencia trabaja por ti

#typescript #inference #basics
¿Por qué escribir tipos cuando TypeScript ya los sabe? Entendiendo const vs let y la inferencia automática.

Lo primero por lo que empezaremos es entender que TypeScript es “listo”, no hay que explicarle lo obvio.

La Inferencia de Tipos

Muchos devs que venimos de lenguajes fuertemente tipados (como C, Java o C# antiguos) es normal que estemos acostumbrados a la idea de tiparlo todo.

typescript 
// ❌ Redundante (Boilerplate innecesario)
const userName: string = "BartoloDev";
const userAge: number = 41;
const isAdmin: boolean = true;

TypeScript ya sabe que “BartoloDev” es un string. No hace falta que se lo jures.

typescript 
// ✅ Perfecto (Limpio y legible)
const userName = "BartoloDev"; // TS infiere: string (o literal "BartoloDev", veremos esto luego)
const userAge = 41;       // TS infiere: number
const isAdmin = true;     // TS infiere: boolean

Esto se llama Inferencia de Tipos. Dejamos que TS deduzca el tipo por el valor inicial.

const vs let: La diferencia clave

Aquí es donde la cosa se pone interesante y donde TS brilla.

Con let (Variables mutables)

Cuando usamos let, TS asume que vamos a cambiar el valor, así que infiere el tipo primitivo “general”.

typescript 
// TS con esto entiende: "Ah, 'status' es un STRING y además cambiará a cualquier otro string".
let status = "pending";

status = "success"; // ✅ Bien
status = "error";   // ✅ Bien

status = 123;       // ❌ Si lo intentas te devolverá un error.
// No puedes meter un número en un string.

Con const (Constantes)

Cuando usamos const, TS sabe que ese valor nunca va a cambiar. Así que puede ser mucho más específico.

typescript 
const method = "GET";
// TS dice: "Esto no es solo un string. Es EL string 'GET'".
// El tipo literal es "GET".

Esto parece una tontería ahora, pero es la base para entender por qué a veces TS se queja de que "GET" no es asignable a string (o viceversa) en configuraciones complejas.

Cuándo SÍ anotar tipos

Entonces, si TS lo infiere, ¿nunca es necesario poner tipos? No, hay casos donde es necesario:

  1. Cuando la inferencia falla o es muy amplia:

Desde nuestro punto de vista, dejaríamos que TS infiera any (o lo pondríamos nosotros mismos) en casos en que no sepamos lo que va a pasar, sea por errores o que la respuesta pueda ser muy amplia.

typescript 
// TS infiere 'any' si no está configurado en modo 'strict' (que te obliga a anotar tipos siempre)
let data; 
data = fetchSomething(); // Puedes pasarle lo que quieras y TS no se queja.

Pero ojo con any, porque le estamos quitando a TS todo su propósito. Lo ideal sería no vernos obligados a utilizarlo.

  1. En parámetros de funciones (¡Aquí es obligatorio!):
typescript 
// ❌ TS no puede leer tu mente ni saber quién llamará a esto
function greet(person) {
  ...
}

// ✅ Aquí defines el contrato
function greet(person: string) {
  ...
}
  1. Para definir contratos de retorno explícitos: A veces queremos asegurarnos de que nuestra función devuelve X, aunque infiera Y.

Resumen de la Parte 1

  • Menos es más: Si TS puede inferirlo, no lo escribamos. Nuestro código será más limpio.
  • Variable (let) = Tipo General (string, number).
  • Constante (const) = Tipo Literal (El valor exacto).

En la Parte 2, miraremos cómo usar esos tipos literales a nuestro favor con las Uniones, y cómo decirle a TS: “Esta variable solo puede ser ‘admin’ o ‘user’, nada más”.

¡Experimentemos!

Aquí tenemos un editor de TypeScript real corriendo en el navegador para probar lo aprendido.