El modelo puro: la maquina dice QUE, la implementacion dice COMO

Todo lo que aprendiste en este nivel —el context, el assign, los guards, las actions— converge en una sola idea que separa a quien usa XState de quien lo entiende: una maquina no ejecuta su logica, la DESCRIBE. Cuando escribes una maquina bien hecha, el grafo de estados y sus aristas no contienen la peticion de red ni el log ni la validacion; contienen NOMBRES que apuntan a ellos. Ese grafo con nombres es una especificacion pura —el QUE debe ocurrir— hecha de datos planos. Las implementaciones concretas de esos nombres —el COMO— viven en otro sitio, se enchufan con setup y se pueden cambiar con provide. Esta frontera entre la descripcion y su realizacion es la razon ultima por la que una maquina de estados es testeable, visualizable y verificable de formas que ningun amasijo de if y useEffect permite jamas. Es el pago final de haber sido disciplinado con la pureza.

QUE frente a COMO: el grafo solo nombra

Observa una maquina de carga y fijate en que NO aparece: no hay ningun fetch, ningun console.log, ninguna validacion escrita en linea. Hay nombres —cargarDatos, guardaResultado, notifica— que apuntan a implementaciones definidas aparte. El cuerpo de createMachine es pura estructura: estados, transiciones y referencias.

import { setup, assign, fromPromise } from 'xstate'

const maquina = setup({
  types: {
    context: {} as { datos: string | null; error: string | null },
    events: {} as { type: 'CARGA' },
  },
  // el COMO: implementaciones de cada nombre
  actors: {
    cargarDatos: fromPromise(async () => {
      const r = await fetch('/api/datos')
      return r.text()
    }),
  },
  actions: {
    guardaResultado: assign({ datos: ({ event }: any) => event.output }),
    notifica: () => console.log('carga completa'),
  },
}).createMachine({
  // el QUE: estructura pura que solo nombra
  context: { datos: null, error: null },
  initial: 'inactivo',
  states: {
    inactivo: { on: { CARGA: 'cargando' } },
    cargando: {
      invoke: {
        src: 'cargarDatos',                                    // nombre, no implementacion
        onDone: { target: 'exito', actions: ['guardaResultado', 'notifica'] },
        onError: 'error',
      },
    },
    exito: {},
    error: {},
  },
})

El cuerpo de la maquina se lee como un contrato: al recibir CARGA pasa a cargando, invoca lo que sea que cargarDatos haga, y si termina bien guarda y notifica. NO dice como se cargan los datos ni que significa notificar. Esa ignorancia deliberada es su fuerza: la misma descripcion sirve con datos reales, con datos falsos o con datos que fallan a proposito, segun que enchufes detras de cada nombre.

setup y provide: declarar e intercambiar el COMO

setup es donde declaras los tipos y las implementaciones de todos los nombres que la maquina usara. Todo lo que pongas ahi es el COMO por defecto. Pero la pieza que desbloquea la testabilidad es provide: llamar a .provide(...) sobre una maquina devuelve una maquina NUEVA, identica en estructura, con las implementaciones que indiques sustituidas. La descripcion no cambia; solo cambia el relleno de los nombres.

// para un test: misma maquina, otro COMO
const maquinaBajoTest = maquina.provide({
  actors: {
    cargarDatos: fromPromise(async () => 'datos de prueba'),  // no toca la red
  },
  actions: {
    notifica: () => {},   // efecto silenciado
  },
})

Con esto, maquinaBajoTest recorre EXACTAMENTE la misma logica que la de produccion —los mismos estados, guards y transiciones— pero sin que salga una sola peticion ni se imprima nada. Has cambiado el COMO sin tocar el QUE.

flowchart LR
Q[maquina: el QUE estructura pura] --> P[provide]
H1[COMO real: fetch y log] --> P
H2[COMO de test: mocks] --> P
P --> R[maquina lista para ejecutar o testear]
style Q fill:#cba6f7,color:#11111b
style H1 fill:#89b4fa,color:#11111b
style H2 fill:#a6e3a1,color:#11111b

Testabilidad: ejercitar la logica sin el mundo

La separacion rinde su fruto en tres estilos de test, de menos a mas puro. El primero es de integracion ligera: creas un actor con la maquina mockeada por provide, le envias eventos y afirmas sobre el snapshot.

import { createActor } from 'xstate'

const actor = createActor(maquinaBajoTest).start()
actor.send({ type: 'CARGA' })
// tras resolver el actor mockeado:
actor.getSnapshot().matches('exito')          // true
actor.getSnapshot().context.datos             // 'datos de prueba'

El segundo estilo prescinde del actor por completo. XState expone la transicion como FUNCION PURA: dada una maquina, un snapshot y un evento, calcula el siguiente snapshot sin arrancar nada y sin disparar efectos. Es la encarnacion literal de que la maquina es una funcion de estado y evento.

import { getInitialSnapshot, getNextSnapshot } from 'xstate'

const s0 = getInitialSnapshot(maquina, undefined)
const s1 = getNextSnapshot(maquina, s0, { type: 'CARGA' })
s1.value   // 'cargando'  -> transicion calculada, cero efectos ejecutados

El tercer estilo es el testing basado en modelo: como el grafo es datos, una herramienta puede RECORRERLO sola y generar todos los caminos posibles hasta cada estado, convirtiendo tu maquina en su propia bateria de pruebas.

import { getShortestPaths } from '@xstate/graph'

const caminos = getShortestPaths(maquina)   // un camino de eventos hasta cada estado alcanzable
// ejecuta cada camino y afirma que la maquina llega donde el modelo predice