El árbol de decisión: signal, máquina o arquitectura

La lección anterior partió el estado en cuatro clases y dejó tres de ellas casi resueltas: el servidor a una cache, la URL al router, la UI efímera a un useState local. Queda la clase con más matiz y más consecuencias: el estado de dominio que el cliente posee. Para él la pregunta no es dónde vive, sino cómo se muta —con cuánta disciplina, con cuántas barandillas—. Este es el segundo árbol del nivel, y opera un peldaño por encima del árbol de librerías del Nivel 23. Aquel decidía entre Zustand, Jotai y Redux Toolkit; este decide algo anterior y más profundo: si tu problema pide la libertad de un signal, la red de seguridad de una máquina de estado, o el flujo unidireccional estricto de una arquitectura formal. Elegir bien esa disciplina es la diferencia entre un estado que te ayuda y uno que te traiciona.

Las tres preguntas que estructuran la decisión

El árbol se recorre con tres preguntas encadenadas, y su orden importa porque cada una descarta un espacio del problema antes de la siguiente. La primera es la más decisiva: este estado modela modos excluyentes con reglas de transición. Es decir, hay un puñado de estados en los que el sistema puede estar —ocioso, cargando, con error, listo— y transiciones que solo son legales entre ciertos pares, de modo que existen combinaciones imposibles que ningún dato debería poder representar. Si la respuesta es sí, tu problema tiene forma de flujo, y la rama de las máquinas del bloque de Niveles 9 a 16 lo espera. Si es no —el estado son simplemente datos que cambian de valor sin un grafo de modos—, sigue la segunda pregunta.

La segunda afina los datos que solo cambian: cuántas piezas hay y cuánta derivación las relaciona. Un puñado de valores independientes que se leen y se escriben pide lo mínimo: un signal o un store plano. Una red de valores que se computan unos de otros —lo que el bloque de Niveles 4 a 8 llamó grafo de derivación— pide una herramienta que gestione esas dependencias, como los átomos de Jotai. La tercera pregunta es ortogonal a las dos anteriores y puede empujar cualquier hoja hacia arriba: el dominio es grande, el equipo amplio y la corrección exige auditoría. Un dominio pequeño con tres desarrolladores no necesita la ceremonia de una arquitectura formal aunque tenga transiciones; un dominio financiero con cuarenta manos y requisitos de trazabilidad la necesita aunque cada pieza parezca simple.

Las tres familias como hojas del árbol

Cada hoja es una de las grandes familias que el track construyó, y el árbol solo hace explícito cuándo cada una es la respuesta correcta.

Las hojas no son excluyentes entre sí a escala de app: una arquitectura formal puede alojar máquinas para sus flujos, y una máquina puede llevar signals en su contexto. El árbol decide por pieza de estado, no por aplicación entera. Un mismo producto tendrá un store ligero para las preferencias, una máquina para el asistente de alta y —si su dominio lo justifica— una arquitectura formal para el núcleo transaccional. Recorrer el árbol es una operación local que repites por cada flujo, no un veredicto único que firmas al empezar el proyecto.

// Las hojas anidan: una arquitectura formal aloja maquinas,
// una maquina lleva signals o valores planos en su contexto.
const maquinaPago = createMachine({
  context: { intentos: 0 },      // estado plano dentro de la maquina
  initial: 'idle',
  states: { idle: {}, cobrando: {}, error: {}, ok: {} },
});
// y el reducer de una arquitectura formal puede delegar este flujo a la maquina

flowchart TD
A[estado de dominio del cliente] --> B{hay modos excluyentes con transiciones?}
B -->|si: un flujo con fases y aristas prohibidas| M[maquina de estado]
B -->|no: son datos que solo cambian| C{cuanta derivacion los relaciona?}
C -->|pocos valores planos| S[signal o store ligero]
C -->|un grafo interdependiente| D[atomos derivados]
M --> E{dominio grande y auditable?}
S --> E
D --> E
E -->|si: equipo amplio y trazabilidad| F[arquitectura formal unidireccional]
E -->|no| G[quedate en la hoja minima]
style S fill:#a6e3a1,color:#11111b
style D fill:#94e2d5,color:#11111b
style M fill:#89b4fa,color:#11111b
style F fill:#cba6f7,color:#11111b
style G fill:#a6e3a1,color:#11111b

Un ejemplo recorrido fija el método. Un modal de confirmación: sin transiciones reales, un booleano —hoja del signal—. Un reproductor de vídeo con estados ocioso, cargando, reproduciendo, pausado y error, donde reproducir desde error no tiene sentido: modos excluyentes, hoja de la máquina. El núcleo de una plataforma de trading con decenas de acciones auditables, equipo grande y necesidad de reconstruir cualquier estado pasado: hoja de la arquitectura formal. Tres piezas del mismo producto, tres hojas distintas, y ni una decisión tomada por moda.

Subir de disciplina es un intercambio, no una mejora

El error de lectura más común de este árbol es verlo como una escala de calidad, donde la arquitectura formal sería la opción seria y el signal la de juguete. Es falso. Cada peldaño hacia arriba compra una garantía concreta y cobra un precio concreto, y elegir bien es saber si necesitas lo que compras más de lo que te molesta lo que pagas.

// La misma pieza de estado, tres disciplinas, tres costes.
// 1. Signal: libertad total, cero garantias estructurales.
const abierto = signal(false);
abierto.value = true; // nada impide ninguna transicion

// 2. Maquina: las transiciones ilegales no compilan como eventos validos.
type Estado = 'ocioso' | 'cargando' | 'error' | 'listo';
const transiciones: Record<Estado, Estado[]> = {
  ocioso: ['cargando'], cargando: ['error', 'listo'], error: ['cargando'], listo: [],
}; // reproducir desde 'listo' no existe: estado imposible, irrepresentable

// 3. Arquitectura formal: cada cambio es una accion serializable y auditable.
type Accion = { type: 'cargar' } | { type: 'exito'; datos: Datos } | { type: 'fallo' };
function reducer(estado: Estado, accion: Accion): Estado { /* ... */ }

La máquina compra la imposibilidad de estados ilegales —el gran regalo del bloque de statecharts— y cobra el coste de declarar por adelantado todos los modos y aristas. La arquitectura formal compra trazabilidad total, testeo exhaustivo y viaje en el tiempo, y cobra la ceremonia de acciones, reducers y selectores que el Nivel 22 diseccionó. El signal no compra ninguna garantía estructural y por eso no cobra ceremonia alguna. Ninguno es mejor en abstracto; cada uno es mejor para un problema con una forma y un contexto concretos.

El árbol se recorre por pieza, no por proyecto

Una lectura equivocada del árbol sería recorrerlo una sola vez, al empezar, y declarar una disciplina única para toda la aplicación: esta app es de máquinas, aquella es de Redux. Pero el árbol clasifica piezas de estado, no proyectos, y una misma aplicación aloja piezas de formas distintas que caen en hojas distintas. Lo normal y sano es que un producto tenga un store ligero para sus preferencias, una máquina para su asistente de alta y, si el dominio lo pide, una arquitectura formal para su núcleo transaccional, todo a la vez. Recorrer el árbol es una operación local que repites por cada flujo, no un veredicto único que firmas al arrancar.

Y como los problemas cambian de forma con el tiempo, la hoja de una pieza tampoco es permanente. Un dato que hoy es un simple valor —hoja del signal— puede desarrollar modos el día que le añades estados de carga y error que no pueden coexistir, y entonces cruza a la rama de las máquinas. La señal de que una pieza se quedó en la hoja equivocada es la misma que enseñó el bloque de statecharts: booleanos que se contradicen, condiciones que existen solo para prohibir combinaciones imposibles. Cuando aparezca, vuelve a recorrer el árbol para esa pieza y déjala subir de rama; no toques por ello las demás.