¿Qué son los tipos literales en TypeScript y para qué se utilizan? ¿Cómo se pueden implementar restricciones estrictas en los valores de las variables y qué trampas existen al aplicarlos?

Respuesta

Tipos Literales permiten restringir los posibles valores de una variable a solo ciertas constantes estrictas, y no simplemente a un tipo general (por ejemplo, no solo un número, sino el número 5 o la cadena "sí").

Esto es útil para crear API con parámetros fijos, estados, etc.

type Direction = 'left' | 'right' | 'up' | 'down';

function move(dir: Direction) {
  // ...
}

move('left'); // OK
move('top');  // ¡Error de compilación!

También funcionan con números, booleanos y hasta estructuras completas (tipo literal de tupla):

type WeekDay = 1 | 2 | 3 | 4 | 5 | 6 | 7;
const day: WeekDay = 6; // OK

Limitaciones y matices:

• A los tipos literales no se les pueden asignar valores implícitamente (por ejemplo, no se puede asignar a una variable de tipo 'left' | 'right' una cadena de entrada del usuario sin validación).
• Al trabajar con constantes y variables let es importante recordar el tipo de salida:

const d = 'left'; // tiene tipo 'left' (Literal)
let e = 'left';   // tiene tipo string (normal)

Pregunta trampa

Pregunta: ¿Qué tipo obtendrá la variable si se define como const x = "yes"; — y se le puede asignar otro valor de cadena después?

Respuesta:

• Si se declara const x = "yes"; — x tendrá tipo "yes" (tipo literal), y no se le podrá asignar ningún otro valor diferente de 'yes' (y no se puede cambiar, porque es const).
• Si se declara let x = "yes";, entonces x será tipado como string, y se le podrán asignar cualquier cadena.

const x = 'yes'; // x: 'yes'
let y = 'yes';   // y: string

Ejemplos de errores reales debido al desconocimiento de los matices del tema.

---

Historia

En un proyecto para los estados de las tareas, se usó un enum, pero un desarrollador lo reemplazó por string. Como resultado, la API comenzó a aceptar cualquier cadena como estado, lo que generó numerosos errores al desarrollar el producto en producción, porque se perdió el control.

---

Historia

Un desarrollador intentó usar tipos literales para la validación de datos, pero asignó directamente los parámetros del campo de formulario — TS permitió esto porque el tipo del campo de entrada era string, y no literal (por ejemplo, "ok" | "fail"), ya que los valores de entrada no fueron verificados. Al final, aparecieron valores fuera del conjunto permitido en tiempo de ejecución.

---

Historia

Durante la escritura de pruebas para una función que aceptaba valores literales, una prueba generada automáticamente envió accidentalmente un parámetro de cadena inesperado, las pruebas no pasaron. Luego se descubrió que la tipificación se había debilitado debido a la falta de atención a la salida de tipos al declarar let, y el compilador no lo detectó.