Las máquinas de estado pueden sonar intimidantes al principio: tantos diagramas, cajas y flechas. Pero, en esencia, están construidas sobre tres ideas increíblemente simples: estados, eventos y transiciones. Si alguna vez has manejado el clic de un botón o mostrado un indicador de carga, ya has trabajado con ellas. Esta semana vamos a desmitificar cómo encajan estas piezas y por qué pueden hacer que la lógica de tu UI por fin tenga sentido.

✨ Introducción: La base de toda máquina de estado

En la edición anterior, vimos por qué las máquinas de estado son una mejor forma de modelar la lógica de la UI. Esta semana vamos a desglosar los tres conceptos que impulsan toda máquina de estado:

Estados – los diferentes modos en los que puede estar tu UI

Eventos – las cosas que ocurren y desencadenan cambios

Transiciones – cómo pasas de un estado a otro

Una vez que entiendes esto, incluso los flujos más complejos empiezan a parecer… obvios.

🧠 ¿Qué es un estado?

Un estado es simplemente una etiqueta para una condición en la que se encuentra tu UI.

🔁 Ejemplo: Un interruptor tiene dos estados: activo e inactivo. Un formulario podría tener: inactivo, validando, enviando, éxito, error.

Los defines de antemano, y tu componente solo puede estar en uno de ellos a la vez.

⚡ ¿Qué es un evento?

Un evento es algo que sucede, normalmente desencadenado por el usuario o por el sistema.

👇 Ejemplos:

Un clic → TOGGLE

El envío de un formulario → SUBMIT

Una llamada a la API falla → FAILURE

Los eventos no hacen nada por sí solos: le piden a la máquina que cambie.

🔄 ¿Qué es una transición?

Una transición es la forma en que la máquina cambia de un estado a otro en respuesta a un evento.

Piensa en ello así: “Cuando estoy en [este estado] y ocurre [este evento], paso a [aquel estado]”.

En XState, se ve así:

createMachine({
  initial: 'idle',
  states: {
    idle: {
      on: { SUBMIT: 'submitting' }
    },
    submitting: {
      on: {
        SUCCESS: 'success',
        FAILURE: 'error'
      }
    },
    success: {},
    error: {}
  }
});

🧪 Por qué esta estructura es poderosa

Porque defines explícitamente los estados y las transiciones, evitas:

Condiciones ambiguas

Combinaciones inválidas (por ejemplo, isLoading && isError)

Errores del tipo “¿en qué parte del flujo estoy?”

La máquina no permitirá transiciones que no estén definidas. Eso es seguridad por diseño.

Visualízalo

Aquí está ese formulario como un diagrama de máquina de estados:

Este tipo de diagramas no solo se ven bien: son documentación viva de cómo se comporta tu aplicación.

🧠 Consejo profesional: Los eventos son la API de tu componente

En lugar de exponer un montón de props o handlers, puedes pensar en la máquina de tu UI como una interfaz limpia que expone una sola cosa:

send({ type: 'SUBMIT' });

Eso es todo. A quienes consumen tu componente no les importa tu lógica interna: solo envían eventos y obtienen un comportamiento predecible.

Próximamente: Modelando UI con XState

En la próxima edición, pasaremos a la práctica:

✅ Configurar XState en un proyecto de React

✅ Usar useMachine

✅ Conectar el estado a tu UI

Vamos a construir una máquina real y conectarla a un componente real.

💡 Prueba esto

Elige una UI pequeña en tu aplicación (un interruptor, botón, formulario, etc.) y responde:

¿Cuáles son los estados posibles?

¿Qué eventos pueden ocurrir?

¿Cómo pasas de uno a otro?

Intenta modelarlo en papel o en Stately.ai.

Responde con tu flujo; me encantaría destacar algunos en futuras ediciones.

Hasta la próxima,
Horacio