Acciones de entrada y salida, y guards

Hasta aquí hemos modelado la topología del comportamiento: qué estados hay, cómo anidan, cómo conviven y cómo se recuerda dónde estabas. Falta lo que hace que un statechart interactúe con el mundo. Dos mecanismos lo aportan. Las acciones de entrada y salida atan efectos secundarios al ciclo de vida de cada estado: algo que sucede exactamente al entrar y algo que sucede exactamente al salir, sin que ninguna transición tenga que acordarse de dispararlo. Los guards ponen condiciones sobre las transiciones: una transición deja de ser incondicional y solo se toma si un predicado se cumple. Juntos completan el formalismo, y su verdadera dificultad no está en la sintaxis, sino en el orden y la pureza: cuándo corre cada efecto y qué tiene prohibido hacer un guard.

Efectos atados al ciclo de vida

Una acción de entrada se declara con entry y corre cuando el estado se activa; una de salida se declara con exit y corre cuando se abandona. La pareja modela recursos que se adquieren y se liberan. Un estado cargando enciende un spinner al entrar y lo apaga al salir, pase lo que pase después.

import { setup, assign } from 'xstate'

const cargador = setup({
  types: {} as { context: { intentos: number; max: number } },
  actions: {
    mostrarSpinner: () => ui.spinner(true),
    ocultarSpinner: () => ui.spinner(false),
    contarIntento: assign({ intentos: ({ context }) => context.intentos + 1 }),
  },
  guards: {
    quedanIntentos: ({ context }) => context.intentos < context.max,
  },
}).createMachine({
  id: 'cargador',
  initial: 'inactivo',
  context: { intentos: 0, max: 3 },
  states: {
    inactivo: { on: { PEDIR: 'cargando' } },
    cargando: {
      entry: ['mostrarSpinner', 'contarIntento'], // efectos al ENTRAR
      exit: 'ocultarSpinner', // efecto al SALIR, por cualquier via
      on: { OK: 'exito', FALLO: 'evaluando' },
    },
    evaluando: {
      on: {
        REINTENTAR: [
          { target: 'cargando', guard: 'quedanIntentos' }, // solo si quedan
          { target: 'error' }, // candidato de reserva sin condicion
        ],
      },
    },
    exito: { type: 'final' },
    error: { type: 'final' },
  },
})

La garantía es fuerte: el spinner se apaga en TODA salida de cargando, sea hacia exito o hacia evaluando, sin repetir la orden en cada transición. Igual que un bloque de recursos que se libera sea cual sea la rama por la que sales de una función, la acción de salida centraliza la limpieza en un único lugar ligado al estado, no a los caminos.

stateDiagram-v2
[*] --> Inactivo
Inactivo --> Cargando: pedir
Cargando --> Exito: ok
Cargando --> Evaluando: fallo
Evaluando --> Cargando: reintentar si quedan intentos
Evaluando --> Error: agotados los intentos
Exito --> [*]
Error --> [*]

Casi todo efecto con un principio y un final encaja en este molde de entrada y salida. Reconocer el patrón evita el clásico recurso disperso donde el arranque vive en un sitio y la limpieza se olvida en otro.

El orden exacto durante una transición

Cuando una transición se dispara, los efectos no corren de cualquier manera: siguen un orden que el formalismo fija y que SCXML estandariza. Para una transición del estado de origen al de destino:

1. Se evalúa el guard. Si falla, no ocurre nada: ni salida, ni acción, ni entrada.
2. Si pasa, corren las acciones de salida de los estados que se abandonan, de dentro hacia afuera, hasta el ancestro común más bajo.
3. Corren las acciones propias de la transición.
4. Corren las acciones de entrada de los estados en los que se entra, de fuera hacia dentro, hasta la hoja de destino.

El patrón es limpieza antes que montaje: primero se desmonta lo viejo de dentro hacia afuera, luego se monta lo nuevo de fuera hacia dentro. Es exactamente el orden de destructores y constructores en una jerarquía anidada, o el de la limpieza de un efecto antes del siguiente montaje en una UI. Al entrar en un compuesto, además, primero corre la acción de entrada del compuesto y después la de su subestado inicial, respetando el anidamiento de fuera hacia dentro.

Guards: el permiso de la transición

Un guard es un predicado que decide si una transición está permitida. Se evalúa antes de tocar nada, y si devuelve falso, la transición se descarta como si no existiera para ese evento. Cuando un evento ofrece varios candidatos, se prueban en orden y gana el primero cuyo guard pase; un candidato final sin guard actúa como caso por defecto.

// evaluando: primero se prueba el candidato con guard, luego el de reserva
REINTENTAR: [
  { target: 'cargando', guard: 'quedanIntentos' }, // se toma si el predicado pasa
  { target: 'error' }, // si no, cae aqui
],

Esta cadena de candidatos con guards es el equivalente en el statechart a una expresión condicional: una lista de ramas evaluadas en orden hasta que una aplica. La lógica de decisión vive así en la capa de transiciones, declarativa e inspeccionable, en vez de esconderse dentro de un manejador imperativo.