Combinar herramientas: el stack pragmático de 2026

Llegamos al final, y el final no es una herramienta ganadora sino una combinación. Después de recorrer signals, observables, máquinas de estado, Redux, Elm, TCA, MVI y la cache de servidor, la conclusión pragmática de 2026 es que ninguna de esas familias gana el debate porque el debate estaba mal planteado: no compiten por el mismo puesto. El stack por defecto de una aplicación seria hoy no elige entre ellas, las combina, y le asigna a cada una la clase de estado para la que fue diseñada. TanStack Query para el servidor, un store ligero como Zustand para el cliente, la URL para lo navegable, y una máquina de estado allí donde un flujo tenga modos que no pueden fallar. Esta lección monta ese stack, muestra cómo sus piezas conviven sin pisarse, y cierra el track devolviendo la pregunta a su origen: la madurez no está en la herramienta que eliges, sino en la combinación mínima donde cada clase de estado vive en su sitio.

El stack como composición, no como elección

El stack de 2026 es la materialización directa del árbol de clases de la primera lección: a cada clase, su herramienta idiomática, y ninguna herramienta invadiendo la clase de otra. No es un producto que instalas ni una opinión de moda; es lo que queda cuando aplicas con disciplina la separación de clases a una app real y dejas que cada pieza caiga en su sitio.

La expresión clave del quinto punto es donde haga falta. La máquina no es una capa que envuelve toda la app, sino una pieza puntual que insertas en el flujo concreto que la merece, mientras el resto del estado sigue en su store ligero o su cache. El stack no impone una disciplina uniforme: aplica la máxima donde el riesgo lo exige y la mínima donde no, dentro de la misma aplicación.

flowchart TD
APP[una app de 2026] --> SRV[estado de servidor]
APP --> CLI[estado de cliente]
APP --> NAV[estado navegable]
APP --> FLU[flujos con transiciones]
SRV --> TQ[TanStack Query o RSC]
CLI --> ZU[Zustand o Jotai o useState]
NAV --> URL[router o nuqs]
FLU --> XS[una maquina XState donde duela]
style TQ fill:#f38ba8,color:#11111b
style ZU fill:#a6e3a1,color:#11111b
style URL fill:#fab387,color:#11111b
style XS fill:#89b4fa,color:#11111b

Cómo conviven sin pisarse

La objeción instintiva al stack es que suena a más cosas que aprender y mantener. La respuesta es que cada pieza es pequeña porque hace una sola cosa, y que las fronteras entre ellas son limpias justamente porque cada una gobierna una clase distinta. Un mismo componente orquesta las cuatro sin que ninguna sepa de las otras:

function PanelPedidos() {
  // servidor: verdad remota, vive en la cache y solo se lee
  const { data: pedidos, isPending } = useQuery({
    queryKey: ['pedidos'], queryFn: traerPedidos,
  });

  // navegable: el filtro vive en la URL, compartible y restaurable
  const [estado] = useSearchParam('estado');

  // cliente: preferencia propia, vive en un store ligero
  const compacto = useUI((s) => s.vistaCompacta);

  // flujo critico: el alta de un pedido es una maquina con modos
  const [snapshot, enviar] = useMachine(maquinaAlta);

  if (isPending) return <Cargando />;
  const visibles = pedidos.filter((p) => p.estado === estado);
  return <Tabla filas={visibles} compacta={compacto} onNuevo={() => enviar({ type: 'abrir' })} />;
}

Ninguna de las cuatro herramientas conoce a las demás. TanStack Query no sabe que existe un store; el store no sabe de la URL; la máquina gobierna su flujo sin tocar la cache. Esa ignorancia mutua no es un accidente: es la propiedad que hace el stack mantenible. Cuando cada pieza tiene una frontera clara y una sola responsabilidad, puedes razonar sobre una sin cargar las otras en la cabeza, y puedes reemplazar cualquiera —cambiar Zustand por Jotai, nuqs por el router nativo— sin que las demás se enteren.

Combinar mal: cuando dos herramientas se disputan un dato

El stack falla no cuando eliges mal una pieza, sino cuando dos piezas se disputan la misma. El caso típico: traes una lista con TanStack Query y la copias al store de Zustand para tenerla a mano, o guardas el filtro a la vez en la URL y en un useState local. En ese instante el dato tiene dos dueños, y la pregunta de cuál manda cuando discrepan no tiene respuesta limpia. El solapamiento de fronteras reintroduce exactamente los bugs de sincronización que la separación de clases existía para eliminar.

La regla que lo previene es de dueño único: cada pieza de estado tiene una sola herramienta que la posee, y las demás la leen de ahí sin copiarla. Si dos componentes necesitan la misma lista de servidor, ambos la piden con la misma clave a la cache, que deduplica; no la copian a un store compartido. Si un filtro vive en la URL, los componentes lo leen de la URL, no de una copia local que habría que mantener sincronizada. Un dato, un dueño: esa es la disciplina que hace que combinar herramientas sume claridad en vez de multiplicar el desorden.

// Dos componentes, un dueno: ambos leen de la cache con la misma clave.
function Cabecera() {
  const { data } = useQuery({ queryKey: ['pedidos'], queryFn: traer }); // no copia
  return <Contador n={data?.length ?? 0} />;
}
function Tabla() {
  const { data } = useQuery({ queryKey: ['pedidos'], queryFn: traer }); // deduplica
  return <Filas datos={data ?? []} />;
}
// una sola peticion, una sola verdad; ninguno guarda una copia en un store

El cierre: de la elección a la composición

Aquí termina el track, y conviene ver cuánto ha cambiado la pregunta desde el principio. Empezamos con la pregunta ingenua —qué gestor de estado es el mejor— y llegamos a entender que carecía de sentido, porque presuponía un ganador único para un problema que no es uno solo. La pregunta madura no busca la mejor herramienta: busca la combinación mínima donde cada clase de estado vive gobernada por lo que su naturaleza pide.