El objeto de configuración: states, target y estados anidados

La lección anterior usó el atajo: on: { ALTERNAR: 'activo' }, un evento que apunta directamente a una cadena. Ese atajo esconde una estructura más rica. Una transición es en realidad un objeto con una propiedad target, y ese objeto es donde más tarde colgarás acciones y guardas. Y los estados, a su vez, no son planos: un estado puede contener otros estados, con su propio initial y su propio states, formando un árbol. Esa jerarquía es lo que separa una máquina de estados finitos clásica de una statechart —la extensión que David Harel propuso en 1987 precisamente para domar la explosión de estados de los sistemas reactivos reales—. Entender el objeto de configuración es entender que la máquina es un árbol de comportamiento, no una tabla de transiciones.

La transición: atajo de cadena y forma de objeto

Cuando una transición solo necesita indicar a dónde va, basta la cadena. Pero esa cadena es azúcar sintáctico sobre un objeto cuya propiedad target nombra el destino. Ambas formas son idénticas para el motor:

// Atajo de cadena
inactivo: {
  on: { ALTERNAR: 'activo' },
}

// Forma de objeto: exactamente lo mismo
inactivo: {
  on: { ALTERNAR: { target: 'activo' } },
}

La forma de objeto parece verbosa hasta que la transición necesita algo más que un destino. Ahí es donde viven las acciones a ejecutar durante el salto y las guardas que deciden si el salto es legal:

on: {
  ALTERNAR: {
    target: 'activo',
    guard: 'estaPermitido',
    actions: 'registrarCambio',
  },
}

Estados compuestos: una máquina dentro de un estado

La intuición de Harel fue simple y profunda: si un estado puede contener otros estados, gran parte de la explosión combinatoria desaparece. En lugar de multiplicar conectado-inactivo, conectado-sincronizando, desconectado-inactivo como estados planos independientes, declaras un estado conectado que contiene por dentro su propia submáquina. Un estado con hijos se llama compuesto y necesita, igual que la raíz, un initial que diga por cuál de sus hijos empieza.

import { createMachine } from 'xstate'

const cliente = createMachine({
  id: 'cliente',
  initial: 'desconectado',
  states: {
    desconectado: {
      on: { CONECTAR: 'conectado' },
    },
    conectado: {
      initial: 'inactivo',
      states: {
        inactivo: {
          on: { SINCRONIZAR: 'sincronizando' },
        },
        sincronizando: {
          on: { LISTO: 'inactivo' },
        },
      },
      on: { DESCONECTAR: 'desconectado' },
    },
  },
})

Fíjate en la economía: el evento DESCONECTAR se declara UNA vez, en el estado conectado, y aplica a todos sus hijos. En un modelo plano habrías tenido que repetir esa transición en cada subestado. La jerarquía factoriza el comportamiento común hacia arriba, igual que una superclase factoriza métodos compartidos. Esto es la descomposición XOR de Harel: estar en conectado significa estar en exactamente uno de sus hijos, nunca en dos, nunca en ninguno.

Un detalle con consecuencias: cuando la máquina entra en un estado compuesto, no se posa de forma abstracta en conectado, sino que desciende automáticamente hasta su initial y aterriza en inactivo. Entrar en un compuesto es siempre entrar en su estado inicial; por eso todo compuesto debe declarar uno, igual que la raíz. La transición hacia conectado es, en rigor, una transición a conectado seguida de un descenso a su hijo por defecto, y ese descenso es automático y obligatorio.

stateDiagram-v2
[*] --> desconectado
desconectado --> conectado: CONECTAR
conectado --> desconectado: DESCONECTAR
state conectado {
  [*] --> inactivo
  inactivo --> sincronizando: SINCRONIZAR
  sincronizando --> inactivo: LISTO
}

state.value y matches: leer la jerarquía

Cuando la máquina está en un estado atómico, state.value es una cadena: 'desconectado'. Pero cuando está en un estado compuesto, state.value es un objeto que refleja el camino en el árbol: { conectado: 'sincronizando' }. Ese objeto no es un accidente de implementación; es la representación fiel de que el estado activo es una ruta, no un punto.

const snapshot = actor.getSnapshot()
snapshot.value                          // { conectado: 'sincronizando' }
snapshot.matches('conectado')           // true para cualquier subestado
snapshot.matches({ conectado: 'sincronizando' })  // true solo en ese
snapshot.matches('desconectado')        // false

matches es la forma correcta de preguntar por el estado sin acoplarte a la profundidad exacta. Preguntar matches('conectado') responde “sí” tanto si estás en inactivo como en sincronizando, porque ambos viven bajo conectado. Comparar state.value con igualdad estricta contra un objeto es frágil: si mañana añades un tercer subestado, tu comparación exacta se rompe, pero matches('conectado') sigue siendo verdadera. Por eso matches entiende la jerarquía y es la interfaz pública; la forma cruda de state.value es para inspección, no para lógica de negocio.