context: el estado extendido

Una maquina de estados finita, tomada al pie de la letra, solo sabe en cual de un punado de modos se encuentra. Pero ningun sistema real vive de modos puros: un reproductor recuerda el segundo exacto, un formulario acumula lo que escribes, una peticion cuenta cuantas veces reintento. Ese dato no cabe en un conjunto finito de estados —hay infinitos segundos posibles— y sin embargo la maquina debe recordarlo. La respuesta de los statecharts es una segunda memoria, ortogonal a la primera: el context, o estado extendido. Entender que toda maquina lleva DOS memorias —una cualitativa y finita, otra cuantitativa y abierta— y saber exactamente que va en cada una es la diferencia entre modelar un sistema y ahogarlo en estados.

Dos memorias: lo cualitativo y lo cuantitativo

Harel, al inventar los statecharts, separo de forma deliberada dos clases de informacion que las maquinas ingenuas mezclaban. Los estados finitos describen el modo del sistema: son cualitativos, mutuamente excluyentes y enumerables —inactivo, cargando, exito, error—. El estado extendido guarda los datos que acompanan a ese modo: son cuantitativos y de dominio abierto —cuantos reintentos llevas, que devolvio el servidor, que texto hay en el campo—. XState llama context a esta segunda memoria.

import { setup, assign } from 'xstate'

const recurso = setup({
  types: {
    context: {} as { intentos: number; datos: string | null; error: string | null },
    events: {} as
      | { type: 'PIDE' }
      | { type: 'RESUELVE'; datos: string }
      | { type: 'RECHAZA'; error: string },
  },
}).createMachine({
  id: 'recurso',
  context: { intentos: 0, datos: null, error: null },   // estado extendido inicial
  initial: 'inactivo',
  states: {
    inactivo: { on: { PIDE: 'cargando' } },
    cargando: { on: { RESUELVE: 'exito', RECHAZA: 'error' } },
    exito: {},
    error: { on: { PIDE: 'cargando' } },
  },
})

El valor finito de esta maquina toma cuatro valores; su context toma infinitos, porque intentos es un entero sin cota y datos es cualquier cadena. Las dos memorias avanzan a la vez pero por reglas distintas: el valor finito solo cambia por una transicion declarada, mientras que el context solo cambia cuando una action lo reescribe.

El estado total es un par

Aqui esta el punto que casi todos pasan por alto: el estado real de la maquina no es su valor finito, sino el par formado por el valor finito y el context. Dos actores en el modo cargando pero con intentos distintos NO estan en el mismo estado total; comparten modo pero difieren en memoria extendida. El snapshot que devuelve XState lo refleja: snapshot.value es el modo cualitativo y snapshot.context es la memoria cuantitativa, y solo juntos determinan que hara la maquina ante el proximo evento.

import { createActor } from 'xstate'

const actor = createActor(recurso).start()
actor.send({ type: 'PIDE' })
actor.send({ type: 'RECHAZA', error: 'timeout' })

const s = actor.getSnapshot()
s.value           // 'error'  -> el modo cualitativo
s.context.error   // 'timeout' -> el dato cuantitativo que lo acompana
s.matches('error') // true

Esta dualidad explica por que una maquina con pocos estados puede modelar un sistema riquisimo: los cuatro modos capturan las situaciones que cambian el comportamiento, y el context carga con todo el detalle que no lo cambia. La finitud vive en el control; la infinitud, en la memoria.

El criterio: estado finito o context

La pregunta practica en cada dato es: donde lo pongo. El criterio decisivo no es el tipo del dato sino su papel en el comportamiento.

Un caso limite aclara la frontera. El saldo de una cuenta es cuantitativo y vive en el context. Pero la distincion cualitativa “hay saldo o no lo hay” SI es un modo, si de ella depende que transiciones existan. La solucion elegante no es duplicar el dato en dos sitios: es dejar el numero en el context y expresar la condicion cualitativa con un guard que lo lea en el momento de transitar —el tema de la leccion 3—. El dato vive una sola vez; la maquina lo consulta cuando la cualidad importa.

La explosion combinatoria y su cura

Que pasa si ignoras la frontera y modelas datos cuantitativos como estados. Imagina un contador de 0 a 100 codificado como cien estados cuenta0, cuenta1, hasta cuenta100, cada uno con sus transiciones. Ahora cruzalo con tres modos de un formulario y con un flag de carga: los estados se multiplican. Ese es el pecado que las maquinas nacieron para evitar y en el que caen quienes olvidan el context.

// ANTIPATRON: codificar una cantidad como estados finitos
states: {
  intento0: { on: { FALLA: 'intento1' } },
  intento1: { on: { FALLA: 'intento2' } },
  intento2: { on: { FALLA: 'agotado' } },   // ...y asi sin fin
}
// CURA: un solo estado y la cantidad en el context
states: {
  cargando: {
    on: {
      FALLA: {
        target: 'cargando',   // se queda; solo cambia la memoria
        actions: assign({ intentos: ({ context }) => context.intentos + 1 }),
      },
    },
  },
}

Los mismos reintentos, dos modelos opuestos: arriba, un estado nuevo por cada numero, un grafo que crece sin fin y transiciones duplicadas; abajo, un unico estado que incrementa un entero. La cantidad pertenece a la memoria, no al control, y en cuanto la devuelves a su sitio el diagrama recupera su tamano.

flowchart LR
I[inactivo] -->|PIDE| C[cargando]
C -->|RESUELVE| E[exito]
C -->|RECHAZA| F[error]
F -->|PIDE| C
style I fill:#89b4fa,color:#11111b
style E fill:#a6e3a1,color:#11111b
style F fill:#f38ba8,color:#11111b

En el diagrama solo hay cuatro cajas: los modos que de verdad cambian el comportamiento. Los intentos, el error textual, los datos devueltos —todo lo cuantitativo— no aparece como caja porque viaja en el context, invisible en el grafo pero presente en cada snapshot. Anadir un quinto reintento no crea un estado nuevo: solo incrementa un entero.