Vue y Solid: la máquina como lógica agnóstica del framework

Hemos escrito bastante código de React en este nivel, pero apenas hemos tocado la máquina: setup, createMachine, estados, eventos y assign no mencionan React por ninguna parte. Esa ausencia no es casual, es el activo. La máquina es lógica de actor pura, y un actor ofrece siempre la misma interfaz —un snapshot que observar y un buzón al que enviar— sin importar quién la observe. Por eso la misma máquina de búsqueda de las lecciones anteriores se monta en Vue o en Solid cambiando el import del adaptador y nada más de la lógica. Lo único que cada framework aporta es su forma de conectar la observación del snapshot con su sistema de reactividad. Ver eso con claridad reordena las prioridades de aprendizaje: invierte en la máquina, que es portable; el adaptador es un detalle que se aprende en una tarde.

La misma máquina, tres adaptadores

Los tres adaptadores oficiales —@xstate/react, @xstate/vue y @xstate/solid— exponen la misma familia de hooks o composables: useMachine, useActor, useActorRef y useSelector. Los nombres coinciden a propósito, porque el problema que resuelven es idéntico: instanciar un actor, atarlo al ciclo de vida del componente, observar su snapshot y ofrecer un send. Lo que difiere es el envoltorio reactivo del snapshot, y ese envoltorio lo dicta el framework, no XState.

flowchart TD
M[maquina logica de actor pura] --> RA[xstate react]
M --> VU[xstate vue]
M --> SO[xstate solid]
RA --> RR[snapshot y send con re-render]
VU --> VR[snapshot como ref reactiva y send]
SO --> SR[snapshot como store de grano fino y send]

La forma exacta de la devolución cambia un poco entre adaptadores —React y Solid devuelven una tupla [snapshot, send]; Vue devuelve un objeto { snapshot, send, actorRef }—, pero esa diferencia es superficial y responde a la ergonomía de cada ecosistema. La sustancia es idéntica en los tres: un snapshot inmutable que describe la situación y una función send que empuja hechos al buzón.

Vue: el snapshot como ref reactiva

En Vue, useMachine devuelve un objeto { snapshot, send, actorRef }, y snapshot es una ref. Dentro de script setup accedes al valor con snapshot.value; en la plantilla, Vue desenvuelve la ref automáticamente, así que escribes snapshot.matches("cargando") sin .value. La reactividad de Vue se encarga de que la plantilla se recompute cuando el snapshot cambia, del mismo modo que lo haría con cualquier otra ref.

<script setup lang="ts">
import { useMachine } from "@xstate/vue";
import { maquinaBusqueda } from "./maquina";

const { snapshot, send } = useMachine(maquinaBusqueda);
</script>

<template>
  <button v-if="snapshot.matches('inactivo')" @click="send({ type: 'BUSCAR' })">Buscar</button>
  <Spinner v-else-if="snapshot.matches('cargando')" />
  <ul v-else-if="snapshot.matches('listo')">
    <li v-for="r in snapshot.context.resultados" :key="r">{{ r }}</li>
  </ul>
</template>

Para el grano fino, @xstate/vue ofrece useSelector(actorRef, selector), que devuelve una ref derivada que solo cambia cuando cambia la porción seleccionada, con la misma semántica que su gemelo de React. El patrón es reconocible de inmediato: snapshot.matches, snapshot.context y send son idénticos a los de React; solo el envoltorio ref y la sintaxis de plantilla delatan que estás en Vue. Quien haya escrito la vista de React de las lecciones anteriores no aprende un modelo nuevo, sino una traducción de sintaxis: los conceptos —snapshot, matches, send— viajan intactos.

Solid: el snapshot como store de grano fino

Solid no tiene renders que rehacer: su reactividad es de grano fino y solo re-ejecuta las expresiones concretas que leen un valor cambiado. Por eso @xstate/solid no envuelve el snapshot en una ref sino que lo proyecta en un store de Solid. useMachine devuelve una tupla [snapshot, send] como en React, pero acceder a snapshot.context.resultados en el JSX crea una dependencia fina: solo esa lectura se recomputa cuando ese dato cambia, sin re-renderizar el componente entero.

import { useMachine } from "@xstate/solid";
import { Show, For } from "solid-js";
import { maquinaBusqueda } from "./maquina";

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

  return (
    <>
      <Show when={snapshot.matches("inactivo")}>
        <button onClick={() => send({ type: "BUSCAR" })}>Buscar</button>
      </Show>
      <Show when={snapshot.matches("listo")}>
        <ul><For each={snapshot.context.resultados}>{(r) => <li>{r}</li>}</For></ul>
      </Show>
    </>
  );
}

Esta diferencia ilustra el punto central del nivel mejor que ninguna otra: la misma máquina, sin cambiar una línea, obtiene grano grueso en React y grano fino en Solid. La granularidad de reactividad no es una propiedad de la máquina, sino del adaptador y del framework que hay debajo. La máquina solo emite snapshots; qué se hace con esa emisión —re-renderizar todo, recomputar una plantilla, actualizar un nodo del DOM— es decisión del observador.

Un detalle de montaje vale para los tres adaptadores: define la máquina en el ámbito del módulo, no dentro del componente. Crearla en cada render la reconstruiría una y otra vez y podría reiniciar el actor; el adaptador espera una lógica estable a la que dar identidad.

El núcleo agnóstico: ejecutar la máquina sin framework

La prueba definitiva de que la máquina no depende de ningún framework es que puedes arrancarla con createActor —la API base de XState— y manejarla desde JavaScript plano: te suscribes a sus snapshots, envías eventos y lees el contexto sin montar un solo componente. Esto es exactamente lo que hacen los adaptadores por dentro, y es también la forma en que testeas la lógica: un test recorre la máquina enviando eventos y comprobando estados, sin render ni DOM.

import { createActor } from "xstate";
import { maquinaBusqueda } from "./maquina";

const actor = createActor(maquinaBusqueda);
actor.subscribe((snapshot) => console.log(snapshot.value));
actor.start();                 // imprime: inactivo
actor.send({ type: "BUSCAR" }); // imprime: cargando
// un test asertaria: expect(actor.getSnapshot().matches("cargando")).toBe(true)

Esta portabilidad tiene un corolario organizativo: un equipo puede escribir y versionar las máquinas en un paquete compartido, y que las apps —una en React, otra en Solid, un widget embebido en JavaScript plano— las consuman sin reimplementar la lógica. La regla de negocio deja de duplicarse por framework y pasa a tener un único dueño, con un único juego de tests.