Estados imposibles fuera del modelo

Casi todo bug de interfaz que has visto tiene la misma forma: la pantalla muestra a la vez dos cosas que no pueden ser ciertas juntas. Un spinner girando sobre un mensaje de error. Un botón de guardar activo mientras ya se está guardando. Datos viejos visibles bajo un “cargando”. Ninguno de esos estados corresponde a una situación real del sistema; son artefactos de haberlo modelado con banderas booleanas sueltas, cada una encendiéndose y apagándose por su cuenta. La FSM ataca el problema de raíz: no intenta evitar que aparezcan los estados imposibles, hace que ni siquiera sean representables.

El producto cartesiano de booleanos

Modela una petición de datos con lo primero que sale: cuatro banderas. Parece razonable, y es una trampa.

type Peticion = {
  isLoading: boolean
  isError: boolean
  data: Usuario | null
  error: Error | null
}

Cuatro booleanos —o cuatro campos con dos estados cada uno— generan 2^4 = 16 combinaciones. Enuméralas y descubrirás que solo cuatro tienen sentido: reposo, cargando, éxito con datos, y fallo con error. Las otras doce son estados imposibles perfectamente representables: isLoading: true con isError: true, o data y error ambos rellenos, o cargando con datos viejos aún presentes. El tipo las admite todas por igual. Nada en Peticion dice que sean ilegales, así que tarde o temprano tu código produce una y la UI la renderiza.

El problema escala fatal: cada bandera nueva duplica el espacio. Cinco booleanos son 32 combinaciones; ocho, 256. El número de estados legales crece de forma lineal con la complejidad real del problema, pero el número de estados representables crece exponencialmente. Esa brecha entre lo representable y lo legal es exactamente el territorio donde viven los bugs.

Hacer irrepresentable lo imposible

La técnica se popularizó con la charla de Richard Feldman “Making Impossible States Impossible” en el mundo de Elm, y hoy es idiomática en TypeScript vía uniones discriminadas. La idea: un único campo discriminante —llámalo status— nombra el estado, y cada variante lleva consigo, y solo consigo, los datos que en ese estado tienen sentido.

El nombre del discriminante es convención, no dogma: status, type, kind o tag cumplen igual, y lo único que importa es que sea un literal distinto por variante para que el compilador pueda estrechar. La misma idea llegó a React con el consejo de Kent C. Dodds de dejar de usar booleanos como isLoading y modelar un único campo de estado. No es una moda de un ecosistema concreto: es teoría de tipos algebraicos aplicada, y por eso reaparece en Elm, en Rust con sus enum, en Swift con sus enum de valores asociados y en Haskell con sus tipos suma. Cuando la ves una vez, la reconoces en todas partes.

type Peticion =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: Usuario }
  | { status: "error"; error: Error }

Mira lo que desapareció. data solo existe cuando status es success; error solo existe cuando es error. Es imposible construir un valor con ambos, porque ninguna variante los declara juntos. Las dieciséis combinaciones colapsaron a cuatro estados, y los doce imposibles ya no se pueden ni escribir: el compilador los rechaza. Pasaste de “cuatro válidos entre dieciséis representables” a “cuatro representables, cuatro válidos”.

El discriminante, además, desbloquea el estrechamiento por control de flujo. Dentro de una rama que comprobó status === "success", el compilador sabe que data está presente y error no existe. Y un switch exhaustivo se verifica en el tipo: si añades un estado y olvidas tratarlo, el caso default con la aserción a never enciende un error de compilación.

function render(p: Peticion): string {
  switch (p.status) {
    case "idle": return "esperando"
    case "loading": return "cargando"
    case "success": return `hola ${p.data.nombre}`   // data existe aqui
    case "error": return `fallo: ${p.error.message}`  // error existe aqui
    default:
      const _exhaustivo: never = p   // error de tipo si falta un caso
      return _exhaustivo
  }
}

Esa exhaustividad es, además, un superpoder al refactorizar. El día que añadas un quinto estado —cancelled, pongamos— el compilador recorrerá cada switch sobre status de toda la base de código y marcará en rojo los que no lo tratan. No hay que recordar dónde se consumía el estado: el tipo lleva la cuenta por ti. Añadir un estado deja de ser una excavación arqueológica por el proyecto y se convierte en seguir los errores del compilador hasta que se apagan uno a uno.

Dos capas de imposibilidad: unión y máquina

La unión discriminada mata los estados ilegales, pero no dice nada sobre las transiciones. Con solo el tipo, nada impide saltar de idle directamente a success sin pasar por loading, o de error a success sin un reintento. La unión describe qué formas son legales; la máquina de estados describe qué caminos entre esas formas son legales. Son dos capas complementarias.

stateDiagram-v2
[*] --> idle
idle --> loading : FETCH
loading --> success : RESOLVE
loading --> error : REJECT
error --> loading : RETRY
success --> loading : REFRESH

La máquina afirma que a success solo se llega desde loading por RESOLVE, y a loading desde idle, error o success. Un evento RESOLVE disparado en estado idle no tiene transición: la máquina lo ignora en lugar de fabricar un estado inconsistente. Así, un estado imposible por combinación de datos lo bloquea la unión, y una secuencia imposible de eventos la bloquea la máquina. Entre las dos, el espacio de lo que tu código puede producir se reduce a lo que el dominio permite.

Queda una tercera frontera que ni el tipo ni la máquina cubren por sí solos: los datos que entran del mundo exterior —una respuesta de red, un localStorage, un parámetro de URL— llegan sin garantía de tipo. En 2026 la práctica es sellar ese límite con un esquema: Zod o ArkType parsean la entrada cruda y devuelven la unión discriminada ya estrechada, o fallan ruidosamente. Así la imposibilidad que el tipo promete en compilación se sostiene también en ejecución, justo en el punto donde los datos no confiables intentan colarse. Tipo, máquina y validación de frontera son las tres capas que, juntas, no dejan resquicio por donde nazca un estado inconsistente.

Enumerar bien no es solo quitar imposibles; es descubrir los legales que faltaban. La interfaz típica olvida que success con lista vacía es un estado distinto de success con datos —el estado vacío que nadie diseña hasta que un cliente lo reporta—. La unión te fuerza a decidirlo de forma explícita en lugar de deducirlo con un length === 0 disperso por la vista.

type Peticion =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "empty" }                        // exito sin resultados: un estado propio
  | { status: "success"; data: Usuario[] }     // exito con al menos un dato
  | { status: "error"; error: Error }

Nota la simetría con el nivel 8. Allí el objetivo era que ningún observador viera un valor intermedio inconsistente durante la propagación; aquí, que ningún tipo pueda siquiera expresar una combinación inconsistente en reposo. La reactividad glitch-free atacaba la inconsistencia en el tiempo; la máquina y la unión la atacan en el espacio de valores. Son la misma guerra contra la inconsistencia, librada en dos frentes distintos.