Primero separar: servidor, cliente, UI y URL

Todo el track desemboca aquí: no en una herramienta más, sino en el criterio para elegir entre todas. Y ese criterio empieza con una decisión que precede a cualquier otra y pesa más que ninguna. No es qué gestor de estado usar, ni qué arquitectura adoptar, ni siquiera qué framework. Es reconocer que la palabra estado nombra cuatro cosas distintas que hemos tratado como una sola durante demasiado tiempo. El dato que traes del servidor, el que posee tu cliente, el que solo describe cómo se ve una vista y el que dice dónde está el usuario en tu app no son variaciones de un mismo problema: son problemas diferentes con dueños diferentes, y cada uno pide una herramienta distinta. Separar esas cuatro clases, antes de escribir una línea de arquitectura, es la decisión de mayor palanca que tomarás en todo el diseño.

El estado no es una cosa: son cuatro

Durante años la pregunta de arquitectura se formuló mal: qué gestor de estado adopto. La pregunta presupone que el estado es una sustancia homogénea que un único gestor debe gobernar, y esa premisa es falsa. El estado de una aplicación es una mezcla de cosas con naturalezas incompatibles, y la primera destreza de quien diseña sistemas es dejar de verlas como una sola.

El corte que las separa es de propiedad, la pregunta que ya recorriste en el Nivel 2 y que aquí se vuelve el primer eje: quién posee la verdad de este dato. Si vive en otra máquina y tú solo guardas una copia, no eres su dueño sino su lector, y lo que tienes es una cache que envejece sola. Si lo posee tu cliente —nadie lo cambia a tus espaldas—, tu última escritura es la verdad por definición. Ese primer corte parte el estado en dos mitades tan distintas que apenas comparten problemas.

La mitad que el cliente posee se subdivide por un segundo eje, el propósito. Un dato propio puede ser de dominio —importa a la lógica, lo leen varios módulos, su corrupción sería un bug de datos—, puede ser mera apariencia de una vista —si un desplegable está abierto, qué pestaña interna se ve, dónde está el foco—, o puede describir la ubicación del usuario —el filtro activo, la página, el elemento seleccionado que debería sobrevivir a un enlace compartido—. Tres propósitos que, sumados al servidor, dan las cuatro clases del nivel.

Conviene subrayar que la clase no se lee en la forma del dato. Dos piezas idénticas por fuera —ambas un array de objetos— pueden pertenecer a clases opuestas, porque lo que las separa no es su tipo sino su origen y su dueño.

// Misma forma, clases opuestas: decide el dueno, no el tipo.
type Producto = { id: string; nombre: string };
type Tarea = { id: string; texto: string };

const productos: Producto[] = await traerDeLaApi(); // servidor: copia remota que envejece sola
const tareas: Tarea[] = [];                          // cliente: el usuario las crea, nadie mas las toca

La forma engaña; el dueño no. Por eso el primer eje nunca pregunta cómo es el dato sino de quién es su verdad, y clasificar bien exige mirar el origen y el propósito de cada pieza, no su declaración de tipo.

Cada clase, su herramienta

Clasificada la pieza, la herramienta se deduce casi sin margen. Cada clase tiene una naturaleza y una herramienta diseñada para esa naturaleza; forzar una clase en la herramienta de otra es la raíz del desajuste que este track combate desde el Nivel 1.

La prueba que separa las dos clases más confundidas —cliente de dominio y UI— es doble: durabilidad y alcance. Pregúntate si el dato debería sobrevivir a un recargado y si a alguien fuera de este componente le importa. Si ambas respuestas son no, es UI y se queda local; si alguna es sí, ascendió a dato de cliente y merece un lugar compartido. Un mismo componente lee de las cuatro clases a la vez sin mezclarlas, porque cada dato vive donde su naturaleza manda:

function Panel({ id }: { id: string }) {
  const { data: pedidos } = useQuery({ queryKey: ['pedidos', id], queryFn: traer }); // servidor
  const tema = useSesion((s) => s.tema);           // cliente: dato de dominio propio
  const [abierto, setAbierto] = useState(false);   // ui: efimero y local
  const [filtro] = useSearchParam('filtro');       // url: navegable y compartible
  return <Vista pedidos={pedidos} tema={tema} abierto={abierto} filtro={filtro} />;
}

flowchart TD
E[una pieza de estado] --> Q{de quien es la verdad?}
Q -->|vive en otra maquina| S[servidor: es una cache]
Q -->|la posee el cliente| C{para que sirve?}
C -->|dato propio que importa al dominio| K[cliente: store ligero]
C -->|apariencia efimera de una vista| V[ui: useState local]
C -->|describe donde esta el usuario| U[url: navegable y compartible]
style S fill:#f38ba8,color:#11111b
style K fill:#a6e3a1,color:#11111b
style V fill:#89dceb,color:#11111b
style U fill:#fab387,color:#11111b

La frontera y la palanca

De los tres cortes, uno es sagrado: la frontera entre servidor y cliente. Las otras tres clases comparten dueño y se pueden reubicar sin drama —un dato de UI que asciende a cliente, un filtro que se muda a la URL—, pero cruzar la línea servidor-cliente introduce el peor bug del oficio. Copiar un dato de servidor a un store de cliente crea dos verdades del mismo hecho: la remota, que sabe cuándo caduca, y tu copia, que no sabe nada y quedará obsoleta en cuanto la original cambie. Has reconstruido a mano, y peor, la cache que ya tenías gratis.

Por qué esta clasificación es la palanca mayor y no un preámbulo: porque todas las decisiones posteriores dependen de ella y ninguna la puede reparar. Si clasificas primero, elegir librería (Nivel 23) y elegir disciplina de mutación (lección siguiente) se vuelven casi mecánicos, porque operan dentro de una clase ya delimitada. Si no clasificas, ninguna herramienta te salva: el mejor gestor del mundo aplicado a un servidor disfrazado de estado propio sigue produciendo datos obsoletos en pantalla. La palanca está en el orden. Clasificar cuesta minutos y ahorra la reescritura que cuesta meses.

La clasificación se revisa, no se firma

Un malentendido peligroso sería tomar esta clasificación como un acto único que se hace al nacer el proyecto y se da por cerrado. La clase de una pieza depende de hechos que cambian con la app: un dato que hoy usa un solo componente asciende a estado de cliente el día que una segunda pantalla lo lee; un valor que guardabas como propio se descubre derivable de otro y desaparece del estado real; un filtro atrapado en un store se revela navegable y se muda a la URL. La taxonomía es un mapa que se corrige cuando el territorio cambia de forma.

Por eso conviene volver a pasar las dos preguntas cada vez que una pieza cambia de uso, no solo cuando nace. El coste de reclasificar es bajo si diseñaste con fronteras limpias: mover un dato de una clase a otra es cambiar dónde vive, no reescribir la lógica que lo usa. Lo caro no es reclasificar a tiempo, sino descubrir tarde que una pieza llevaba meses en la clase equivocada, sincronizándose a mano y sembrando los bugs que su clase correcta habría hecho imposibles.