Renderizar según el estado: matches y estados anidados

Antes de las máquinas, un componente de carga solía arrastrar tres booleanos —cargando, error, hayDatos— y una batería de condicionales para cubrir sus combinaciones. El problema es que ocho combinaciones existen en el tipo pero solo cuatro tienen sentido: cargando y error a la vez es un estado imposible que el código, sin embargo, puede representar y renderizar. Una máquina elimina esa clase de bug de raíz, porque solo hay un state.value a la vez y describe una situación legítima por construcción. La vista, entonces, se reduce a una pregunta: dado este snapshot, ¿qué pinto? Y la respuesta se lee, no se calcula.

La vista como función del estado

Con una máquina, el render deja de ser una tabla de verdad de flags y pasa a ser una lectura directa. state.matches("cargando") devuelve true si el estado actual es exactamente ese; encadenas esas preguntas y cada rama de la UI corresponde a un estado declarado. No hay combinaciones espurias porque el actor solo puede estar en un estado a la vez. Fíjate en que el componente ni siquiera necesita conocer las transiciones: solo pregunta dónde está la máquina y pinta en consecuencia.

import { useMachine } from "@xstate/react";
import { maquinaBusqueda } from "./maquina";

export function Buscador() {
  const [state, send] = useMachine(maquinaBusqueda);

  if (state.matches("inactivo")) return <button onClick={() => send({ type: "BUSCAR" })}>Buscar</button>;
  if (state.matches("cargando")) return <Spinner />;
  if (state.matches("fallo")) return <ErrorBox onRetry={() => send({ type: "REINTENTAR" })} />;
  return <Resultados items={state.context.resultados} />;
}

Como el state.value proviene de un tipo unión —la máquina enumera sus estados— el compilador conoce el conjunto exacto de valores posibles, y una cadena de matches que los cubra todos es, en la práctica, un pattern matching exhaustivo: si añades un estado a la máquina y olvidas su rama, el hueco es visible en un solo lugar, no disperso por la app. La vista se vuelve tan honesta como la máquina que proyecta.

Estados anidados y matches jerárquico

Los statecharts existen precisamente para descomponer estados en subestados. Un estado cargando puede tener una fase pidiendo y otra validando; un formulario editando puede anidar limpio y sucio. Para leer un subestado usas state.matches con un objeto que refleja la jerarquía: state.matches({ cargando: "validando" }). La vista elige su nivel de detalle: pregunta por el padre para lo grueso y por el hijo para lo fino, y ambas lecturas conviven.

stateDiagram-v2
[*] --> inactivo
inactivo --> cargando : BUSCAR
state cargando {
  [*] --> pidiendo
  pidiendo --> validando : RESPUESTA
}
cargando --> listo : DONE
cargando --> fallo : ERROR
fallo --> cargando : REINTENTAR
listo --> [*]

// Lectura gruesa y fina del mismo snapshot conviviendo sin conflicto
const enCarga = state.matches("cargando");                   // padre: true en pidiendo y validando
const validando = state.matches({ cargando: "validando" });  // hijo concreto

return (
  <div aria-busy={enCarga}>
    {validando ? <p>Verificando resultados...</p> : null}
    {enCarga ? <BarraProgreso /> : null}
  </div>
);

La anidación no es adorno: el subestado hereda las transiciones del padre, así que un evento CANCELAR declarado en cargando funciona igual en pidiendo y en validando sin repetirlo. La vista, al preguntar por el padre, se beneficia de esa herencia sin saber que existe.

Estados paralelos: dos dimensiones a la vez

A veces un componente vive en dos dimensiones independientes al mismo tiempo: un reproductor está reproduciendo o pausado y, a la vez, conSonido o silenciado. Modelar eso con estados planos daría un producto cartesiano de cuatro estados que crece sin control. Un estado parallel declara regiones ortogonales, y la máquina está en un subestado de cada región simultáneamente. La vista lee cada región por separado con state.matches de objeto.

// La maquina: dos regiones ortogonales activas a la vez
reproductor: {
  type: "parallel",
  states: {
    reproduccion: {
      initial: "pausado",
      states: { pausado: { on: { PLAY: "reproduciendo" } }, reproduciendo: { on: { PAUSA: "pausado" } } },
    },
    sonido: {
      initial: "conSonido",
      states: { conSonido: { on: { SILENCIAR: "silenciado" } }, silenciado: { on: { ACTIVAR: "conSonido" } } },
    },
  },
},

// La vista lee cada dimension de forma independiente
const reproduciendo = state.matches({ reproductor: { reproduccion: "reproduciendo" } });
const silenciado = state.matches({ reproductor: { sonido: "silenciado" } });

Las regiones no se estorban: silenciar no altera si estás reproduciendo. Cada dimensión evoluciona con sus propios eventos, y la explosión combinatoria que temías con flags queda descrita de forma compacta y sin estados imposibles.

Tags: agrupar estados sin acoplar la vista

A veces varios estados comparten una misma pinta desde la UI —pidiendo, validando y un futuro reintentando son, para el usuario, “está ocupado”—. Enumerarlos todos con matches acopla la vista a la topología interna: cada estado nuevo obliga a tocar el componente. Los tags resuelven esto. Etiquetas los estados en la máquina y la vista pregunta por la etiqueta con state.hasTag("ocupado"), ajena a cuántos ni cuáles estados la llevan.

// En la maquina: cada estado declara sus tags
cargando: { tags: ["ocupado"], /* ... */ },
reintentando: { tags: ["ocupado"], /* ... */ },

// En la vista: una sola pregunta estable frente a cambios internos
{state.hasTag("ocupado") && <Spinner />}

Un tag es una capa de indirección deliberada: nombra una intención de presentación —ocupado, editable, erróneo— y deja que la máquina decida qué estados la cumplen. Cuando refactorizas el statechart y partes un estado en tres, la vista no se entera si los tres siguen llevando el tag. Es el mismo desacoplamiento que un selector aporta sobre el contexto, aplicado ahora al estado finito.