Estados de carga compuestos: lo que un booleano nunca supo decir

Pregúntale a un booleano de carga qué está pasando y solo sabe decir sí o no. Pero la pantalla necesita distinguir al menos cuatro situaciones que ese sí engloba: no tengo nada y estoy pidiéndolo, tengo datos viejos y estoy refrescando, tengo datos y el refresco acaba de fallar, y no tengo nada y ya me rendí. Las cuatro comparten un valor verdadero en la misma variable y exigen interfaces completamente distintas —esqueleto, indicador discreto, aviso sobre contenido válido, pantalla de error—. La solución no es añadir un segundo booleano, porque eso multiplica las combinaciones imposibles; es reconocer que había dos preguntas independientes y darle a cada una su propia región.

Las dos preguntas que el booleano aplasta

El origen del problema es que una sola variable intenta responder a dos cosas que varían con independencia. La primera es sobre posesión: hay algo que pintar. La segunda es sobre actividad: hay trabajo en curso hacia el servidor. Ninguna determina a la otra, y por eso su producto tiene cuatro casillas legítimas y todas ocurren a diario.

Seis casillas reales, y ningún par de booleanos las cubre sin permitir además combinaciones sin sentido. El intento clásico de resolverlo con tres banderas —cargando, refrescando y error— genera ocho combinaciones de las cuales la mitad son contradictorias, y esa mitad es precisamente donde viven los fallos de interfaz que solo se reproducen en redes lentas: el esqueleto que aparece sobre datos ya cargados, el error que sigue visible mientras el reintento tuvo éxito, el indicador de refresco eterno porque nadie lo apagó en una rama.

Dos regiones ortogonales

Las regiones paralelas expresan exactamente esta estructura: dos dimensiones activas a la vez, cada una con sus propios estados y transiciones, sin combinaciones ilegales posibles porque ninguna región puede estar en dos posiciones ni en ninguna.

import { setup, assign } from 'xstate'

export const panel = setup({
  types: { context: {} as { items: Item[]; error: unknown; obtenidoEn: number } },
}).createMachine({
  type: 'parallel',
  context: { items: [], error: null, obtenidoEn: 0 },
  states: {
    datos: {
      initial: 'vacio',
      states: {
        vacio: {},
        presente: {},
      },
      on: {
        LLEGARON: {
          target: '.presente',
          actions: assign({ items: ({ event }) => event.items, obtenidoEn: () => Date.now() }),
        },
      },
    },
    red: {
      initial: 'ocioso',
      states: {
        ocioso: { on: { PEDIR: 'trabajando' } },
        trabajando: {
          invoke: {
            src: 'leerItems',
            onDone: { target: 'ocioso', actions: 'emitirLlegaron' },
            onError: { target: 'fallando', actions: assign({ error: ({ event }) => event.error }) },
          },
        },
        fallando: { on: { PEDIR: 'trabajando' } },
      },
    },
  },
})

Lo relevante no es la sintaxis sino lo que se vuelve imposible. La región datos no puede volver a vacio porque una petición falle: nadie escribió esa transición, así que un error jamás borra la pantalla. La región red no puede estar simultáneamente trabajando y fallando, así que el indicador de refresco y el aviso de error nunca aparecen juntos por accidente. Y el evento que puebla los datos es independiente del que gobierna la red, de modo que un dato que llegue por otra vía —un mensaje del servidor, una actualización optimista, una hidratación— entra por la misma puerta sin tocar la región de actividad.

stateDiagram-v2
state panel {
  state datos {
    [*] --> vacio
    vacio --> presente: llegan items
    presente --> presente: llegan items nuevos
  }
  --
  state red {
    [*] --> ocioso
    ocioso --> trabajando: PEDIR
    trabajando --> ocioso: resultado
    trabajando --> fallando: error
    fallando --> trabajando: PEDIR
  }
}

El error parcial: datos viejos con un fallo nuevo

La casilla más valiosa de la matriz es la tercera, y es la que ningún booleano supo nunca expresar: tengo datos válidos en pantalla y el último intento de actualizarlos falló. Un modelo de un solo eje obliga a elegir entre dos mentiras: mostrar el error y esconder información correcta que el usuario estaba leyendo, o esconder el error y hacerle creer que lo que ve está al día. Con regiones separadas no hay que elegir, porque el fallo pertenece a la región de la red y los datos siguen en la suya.

export function vistaDe(snapshot: Snapshot) {
  const conDatos = snapshot.matches({ datos: 'presente' })
  const trabajando = snapshot.matches({ red: 'trabajando' })
  const falla = snapshot.matches({ red: 'fallando' })

  if (!conDatos && trabajando) return 'esqueleto'
  if (!conDatos && falla) return 'errorTotal'
  if (!conDatos) return 'vacio'
  if (trabajando) return 'refrescando'
  if (falla) return 'datosConAviso'
  return 'limpio'
}

Esa función es un derivado puro, no un estado: no guarda nada, se recalcula y traduce la posición del grafo al vocabulario de la interfaz. Ponerla en un solo sitio evita que cada componente invente su propia mezcla de condiciones, y su forma de escalera hace evidente el orden de precedencia —primero la posesión, después la actividad— que en condicionales dispersos siempre acaba contradiciéndose entre pantallas.

La degradación parcial se generaliza cuando el panel agrega varias fuentes. Un tablero con tres secciones no tiene un estado de carga, tiene tres, y aplastarlos en uno solo produce el peor de los dos mundos: o la pantalla entera espera a la sección más lenta, o un fallo aislado tumba secciones que habían cargado bien. Modelar cada sección como una región propia —o como un actor hijo con su propia máquina de dos regiones— permite exactamente lo que el producto quiere: cada parte se muestra en cuanto puede, cada fallo se contiene donde ocurrió y la pantalla nunca queda en blanco por culpa de un endpoint caído.