Estados de historia: shallow y deep

Salir de un estado compuesto es destruir su configuración interna. No hay medias tintas: al ejecutar la transición de salida, la máquina abandona la hoja, luego su padre, luego el padre del padre, disparando cada exit por el camino, y lo que quedaba activo dentro deja de existir. Volver a entrar es empezar de cero por el subestado inicial. Ese olvido es una virtud casi siempre —un diálogo reabierto debe arrancar limpio, un formulario cancelado no debería resucitar a medias— pero hay una familia entera de interacciones donde es exactamente lo contrario de lo que el usuario espera: el reproductor que se pausa por una llamada, el panel de ajustes que navega a otra pantalla, el asistente que se interrumpe. Harel resolvió el problema en 1987 con un mecanismo estructural en vez de una convención de código: el pseudoestado de historia, un nodo que no es un estado donde detenerse sino una instrucción de reentrada que dice “vuelve a donde estabas”. Y como los compuestos anidan, la instrucción viene en dos profundidades que conviene no confundir jamás.

El nodo que nunca está activo

Un nodo de historia se declara como un hijo más del estado compuesto, con type: 'history'. Pero es un pseudoestado, no un estado: la máquina jamás reposa en él. Cuando una transición lo apunta como destino, el motor lo resuelve en el mismo microstep —consulta la memoria grabada, la sustituye por el subestado real memorizado y entra allí— sin que la configuración activa llegue a contenerlo ni un instante.

import { createMachine } from 'xstate'

const editor = createMachine({
  id: 'editor',
  initial: 'trabajando',
  states: {
    trabajando: {
      initial: 'redaccion',
      states: {
        redaccion: {
          initial: 'escribiendo',
          states: {
            escribiendo: { on: { PREVISUALIZAR: 'preview' } },
            preview: { on: { EDITAR: 'escribiendo' } },
          },
        },
        terminal: { on: { CERRAR: 'redaccion' } },
        hist: { type: 'history', history: 'deep', target: 'redaccion' },
      },
      on: { TERMINAL: '.terminal', BLOQUEAR: 'bloqueado' },
    },
    bloqueado: {
      on: { DESBLOQUEAR: 'trabajando.hist' },
    },
  },
})

La secuencia temporal importa más que la sintaxis. La memoria se graba al salir: en el momento en que trabajando se desactiva, el motor anota qué configuración tenía dentro. Se consulta al entrar, y solo si la transición apunta explícitamente al nodo de historia; una transición a trabajando a secas ignora la memoria y usa el inicial, aunque el nodo de historia exista. Historia y initial conviven sin estorbarse porque responden a preguntas distintas: initial dice por dónde empezar cuando nadie pide otra cosa, la historia dice por dónde continuar cuando alguien la invoca.

stateDiagram-v2
[*] --> Trabajando
state Trabajando {
  [*] --> Redaccion
  state Redaccion {
    [*] --> Escribiendo
    Escribiendo --> Preview: previsualizar
    Preview --> Escribiendo: editar
  }
  Redaccion --> Terminal: terminal
  Terminal --> Redaccion: cerrar
}
Trabajando --> Bloqueado: bloquear
Bloqueado --> Trabajando: desbloquear via historia
note right of Bloqueado: el nodo de historia se resuelve al entrar y nunca queda activo

Superficial contra profunda

La historia recuerda, pero hay que decidir hasta qué profundidad. Como los compuestos anidan, la respuesta no es única, y elegir mal produce el bug más silencioso de esta familia: uno que solo se manifiesta cuando el subestado recordado es a su vez compuesto.

La tabla siguiente recorre la misma máquina tres veces, saliendo desde tres posiciones distintas, y muestra dónde aterriza cada profundidad al volver. Las dos primeras filas son las que separan los mecanismos; la tercera es la que engaña, porque parece confirmar que la elección da igual.

El criterio que decide es una sola pregunta, formulada desde el usuario y no desde el árbol: cuando vuelve, ¿le basta con la misma sección o exige el mismo estado interno completo? Volver a la pestaña de facturación con sus campos recién montados es superficial. Volver a un reproductor con el mismo modo de subtítulos y el mismo panel abierto es profunda. Cuando dudes, mira qué le resultaría molesto al usuario perder: si lo que perdería es información que él mismo produjo dentro de la sección, quieres profunda.

Un matiz que se pasa por alto: history: 'shallow' es el valor por defecto si escribes type: 'history' sin más. Esa elección de la librería es conservadora y sensata, porque la memoria superficial es más barata de razonar y sorprende menos, pero significa que la profundidad que casi siempre quieres en un asistente interrumpible es la que tienes que pedir explícitamente. Omitir la propiedad no es neutral: es elegir superficial en silencio.

Dónde vive la memoria

La historia no es una idea abstracta del motor: es un campo del snapshot. En XState v5, snapshot.historyValue guarda un registro de qué configuraciones se memorizaron para qué nodos de historia. Verlo como dato explica de golpe tres propiedades que de otro modo parecen mágicas.

import { createActor } from 'xstate'

const actor = createActor(editor).start()
actor.send({ type: 'PREVISUALIZAR' })
actor.send({ type: 'BLOQUEAR' })

const snap = actor.getSnapshot()
snap.value          // 'bloqueado'
snap.historyValue   // registro con la configuracion memorizada de trabajando

const guardado = actor.getPersistedSnapshot()
// guardado viaja a localStorage o al servidor con la historia dentro

Verla como dato tiene además una consecuencia práctica inmediata en depuración. Cuando un flujo interrumpible vuelve al sitio equivocado, la pregunta no es abstracta: imprime historyValue justo antes de la reentrada y compáralo con lo que esperabas que se hubiera memorizado. Casi siempre el registro está vacío —porque nadie llegó a salir del compuesto, sino de un ancestro que lo contenía y que tiene su propia memoria— o contiene la configuración correcta pero la transición apunta al compuesto y no al nodo de historia. Ambos fallos son invisibles leyendo el código y evidentes mirando el dato.

La primera propiedad es que la memoria es local al compuesto: cada nodo de historia tiene su propia entrada, y salir de un compuesto no borra la memoria de otro. La segunda es que la historia sobrevive a la persistencia: si serializas con getPersistedSnapshot y rehidratas con la opción snapshot, el actor restaurado sabe todavía dónde estabas dentro de cada compuesto, lo cual convierte a la historia en la pieza que hace posible reanudar una sesión a través de una recarga completa de página. La tercera es que la memoria es topológica, no de datos: guarda nodos, no contexto.