Estados finales: declarar que una región terminó

Un interruptor no termina nunca: alterna indefinidamente y su modelo es un ciclo. Pero la mayoría de los procesos que valen la pena modelar sí tienen final —un pago se completa, un asistente concluye, una subida acaba, una sesión se cierra— y ese final necesita estar en el modelo, no en un comentario. La teoría de autómatas lo contempló desde el principio: la quíntupla incluye un conjunto de estados de aceptación, los estados donde la máquina se detiene habiendo reconocido su entrada. XState lo expresa con una sola propiedad, type: 'final', y esa propiedad hace tres cosas a la vez que conviene separar mentalmente antes de usarlas. Prohíbe las transiciones de salida, porque aceptar es detenerse. Declara completada la región que contiene al estado, emitiendo un evento sintético que su contenedor puede escuchar. Y, si la región es la raíz, detiene el actor. Tres efectos, un mismo concepto: terminar.

El estado sin salida

Un estado terminal se declara con una propiedad y se caracteriza por una ausencia: no tiene on. La ausencia no es una limitación que soportemos, es la definición. Si un estado de aceptación pudiera seguir transicionando, no marcaría el final de nada; sería un estado intermedio con nombre pomposo.

import { createMachine } from 'xstate'

const subida = createMachine({
  id: 'subida',
  initial: 'inactiva',
  states: {
    inactiva: { on: { EMPEZAR: 'subiendo' } },
    subiendo: {
      on: { OK: 'completada', ERROR: 'fallida', CANCELAR: 'cancelada' },
    },
    completada: { type: 'final', entry: 'registrarExito' },
    fallida: { type: 'final', entry: 'registrarFallo' },
    cancelada: { type: 'final' },
  },
})

Tres detalles de esa declaración merecen atención. El primero es que un estado terminal sí ejecuta sus acciones de entrada: registrarExito corre con normalidad al llegar. Terminar no significa no hacer nada, significa no ir a ninguna parte, y el último acto de un proceso suele ser precisamente el más importante. El segundo es que puede haber varios finales distintos en la misma región, y distinguirlos es información valiosa: terminar bien, terminar mal y terminar por decisión del usuario son tres desenlaces con consecuencias diferentes aguas arriba. El tercero es que un final tiene exit declarable pero solo se ejecutará si el compuesto que lo contiene es abandonado desde fuera, nunca por iniciativa propia.

stateDiagram-v2
[*] --> Inactiva
Inactiva --> Subiendo: empezar
Subiendo --> Completada: ok
Subiendo --> Fallida: error
Subiendo --> Cancelada: cancelar
Completada --> [*]
Fallida --> [*]
Cancelada --> [*]
note right of Subiendo: tres desenlaces distintos y ninguno tiene transiciones de salida

Hay una lectura teórica que ilumina todo lo demás. En teoría de autómatas los estados finales son los estados de aceptación: la máquina lee una secuencia de símbolos y se dice que la acepta si termina en uno de ellos. Traducido, la secuencia de eventos que llevó al actor hasta un final es una secuencia aceptada, una historia válida y completa del proceso. Una subida que acaba en completada es una traza que el modelo reconoce como subida bien formada. Esa es, literalmente, la noción de aceptación de los cursos de lenguajes formales, y explica por qué modelar los finales con nombres distintos equivale a definir varios lenguajes aceptados por la misma máquina.

Terminar una región

El estado terminal despliega todo su poder dentro de un compuesto. Cuando la submáquina de un estado compuesto alcanza su propio final, ese compuesto se declara completado y el motor emite un evento sintético con la forma done.state.<id>, dirigido al padre. El padre no vigila los detalles internos del hijo ni escucha eventos del exterior: reacciona a una señal que significa exactamente “lo que había aquí dentro ha terminado”.

const registro = createMachine({
  id: 'registro',
  initial: 'formulario',
  states: {
    formulario: {
      initial: 'datos',
      states: {
        datos: { on: { SIGUIENTE: 'plan' } },
        plan: { on: { SIGUIENTE: 'revision' } },
        revision: { on: { CONFIRMAR: 'listo' } },
        listo: { type: 'final' },
      },
      onDone: 'bienvenida',
    },
    bienvenida: { type: 'final' },
  },
})

La composición es estructural y no depende de ningún actor externo: el compuesto formulario termina cuando su interior llega a listo, y esa terminación mueve al padre a bienvenida. Lo que hace valiosa la construcción es la dirección de la dependencia. El padre conoce el hecho de que su hijo terminó, pero no cómo lo hizo ni cuántos pasos tuvo; puedes reordenar, añadir o eliminar pasos internos sin tocar una línea del padre mientras siga existiendo un camino hasta el final. Es encapsulación real, con la frontera puesta donde debe estar.

Regiones paralelas y la raíz

La finalización se compone también con el paralelismo, y ahí sigue una regla de conjunción lógica: un estado type: 'parallel' se considera terminado, y dispara su onDone, solo cuando cada una de sus regiones ha alcanzado su propio estado final. No basta con que una acabe, ni con que acaben la mayoría. El subproceso completo termina cuando terminan todas sus ramas simultáneas, lo cual convierte al paralelo con finales en el equivalente declarativo de esperar a que varias tareas concurrentes confluyan.

const arranque = createMachine({
  id: 'arranque',
  type: 'parallel',
  states: {
    sesion: {
      initial: 'cargando',
      states: {
        cargando: { on: { SESION_OK: 'lista' } },
        lista: { type: 'final' },
      },
    },
    config: {
      initial: 'cargando',
      states: {
        cargando: { on: { CONFIG_OK: 'lista' } },
        lista: { type: 'final' },
      },
    },
  },
  onDone: { actions: 'arrancarApp' },
})

Cuando el estado final está en la raíz, el efecto es de otra magnitud: el actor entero se detiene. Su status deja de ser active y pasa a done, los eventos que le envíes se ignoran en silencio, sus suscriptores reciben la notificación de finalización y todos los actores que hubiera invocado se detienen con él. Un actor en done es inmutable de hecho: su comportamiento ha quedado sellado y ninguna interacción posterior puede alterarlo.

La distinción entre esos cuatro valores no es cosmética: cada uno cuenta una historia distinta que tu interfaz debería contar de forma distinta, porque terminar bien no es fallar y que te detengan desde fuera no es haber concluido. Colapsarlos en un booleano terminado es exactamente el tipo de pérdida de información que este track lleva ocho niveles combatiendo, y la ironía es que se comete con más frecuencia en el ciclo de vida del actor que en el dominio, precisamente porque parece infraestructura y no modelo.