Empezar simple y escalar cuando duela

Hay una pregunta que precede a toda arquitectura y que casi nadie se hace a tiempo: no qué disciplina necesita este estado, sino cuándo la necesita. La respuesta correcta, casi siempre, es más tarde de lo que tu instinto dice. El reflejo de la industria durante una década fue elegir la herramienta más pesada al arrancar el proyecto —Redux en la línea uno, por si el proyecto crece— y ese reflejo produjo miles de aplicaciones que pagaron el precio completo de una disciplina cuyos beneficios jamás usaron. La tesis de esta lección es la contraria y es incómoda para quien equipara previsión con madurez: empieza con la herramienta más simple que resuelve el problema de hoy, y sube de peldaño solo cuando un dolor concreto te empuje. La escalabilidad no se compra por adelantado; se gana cuando hace falta.

La escalera y la dirección correcta de viaje

La escalera tiene cuatro peldaños, y coinciden con las hojas del árbol de la lección anterior vistas como una progresión. El primero es useState o useReducer: estado local a un componente, cero infraestructura. El segundo es un store ligero —Zustand, Jotai, un signal— cuando el estado deja de ser de un componente y varios necesitan leerlo. El tercero es una máquina de estado cuando aparecen modos excluyentes y transiciones prohibidas. El cuarto es una arquitectura formal cuando el dominio crece hasta exigir auditoría, testeo exhaustivo y trazabilidad. La dirección correcta de viaje es de abajo hacia arriba, y solo cuando el peldaño actual duele.

// El mismo estado, subiendo de peldano solo cuando el anterior deja de bastar.

// 1. useState: nace local, en un solo componente.
const [seleccion, setSeleccion] = useState<Id | null>(null);

// 2. Store ligero: una segunda pantalla necesita leer la seleccion.
const useSeleccion = create<Estado>((set) => ({
  seleccion: null,
  seleccionar: (id: Id) => set({ seleccion: id }),
}));

// 3. Maquina: la seleccion adquiere modos —editando, guardando, con conflicto—.
//    Ya no basta un valor: hay transiciones que deben ser imposibles.

Fíjate en que cada peldaño nace de una necesidad observada, no anticipada. El useState no se elevó a store por si algún día otra pantalla lo lee, sino el día en que una lo leyó de verdad. La máquina no apareció por si el flujo se complica, sino cuando el flujo ya tenía modos que un booleano no podía representar sin permitir combinaciones ilegales. Esa disciplina de esperar al dolor real es lo que mantiene la arquitectura proporcionada al problema en cada momento de su vida.

La asimetría que lo justifica todo

Toda la recomendación descansa en una asimetría de costes entre los dos errores posibles, y vale la pena hacerla explícita porque es lo que convierte una preferencia estética en un argumento de ingeniería. Equivocarse por defecto —usar un store ligero donde acabará haciendo falta una máquina— se corrige con una migración acotada el día que el dolor aparece: refactorizas una pieza cuya forma ya conoces bien, porque la has visto crecer. Equivocarse por exceso —montar una arquitectura formal para media docena de banderas— se paga cada día, en ceremonia que rodea lógica trivial y en una curva de aprendizaje que grava a cada persona que toca el código, hasta que alguien reúne el valor de desmontarlo.

flowchart LR
A[useState local] -->|una segunda vista lo lee| B[store ligero]
B -->|aparecen modos y transiciones| C[maquina de estado]
C -->|dominio grande y auditable| D[arquitectura formal]
A -.->|el reflejo a evitar: por si acaso| D
style A fill:#a6e3a1,color:#11111b
style B fill:#94e2d5,color:#11111b
style C fill:#89b4fa,color:#11111b
style D fill:#cba6f7,color:#11111b

La flecha punteada del diagrama es el error que esta lección combate: el salto directo del problema más simple a la herramienta más pesada, saltándose los peldaños intermedios en nombre de una previsión que casi nunca se cumple. La razón por la que es tentador es psicológica, no técnica: adoptar la herramienta seria se siente responsable, mientras que empezar con useState se siente ingenuo. Pero la responsabilidad real es la contraria. Quien empieza pesado apuesta el presupuesto de complejidad del equipo a una predicción sobre el futuro; quien empieza ligero gasta ese presupuesto solo cuando el futuro llega y le dice qué forma tiene. Subir un peldaño suele ser barato y bajar suele ser carísimo, así que el error reversible es quedarse corto.

Señales de dolor legítimas y migraciones baratas

Si la regla es subir cuando duele, hay que saber distinguir el dolor legítimo del malestar pasajero, porque no todo roce justifica más disciplina. Cada peldaño tiene su síntoma característico, y reconocerlo es lo que separa una escalada oportuna de una prematura.

La otra mitad de la estrategia es hacer que subir sea barato, y eso se diseña desde el primer peldaño. La clave es encapsular el acceso al estado detrás de una frontera estable —un hook, una función— de modo que cambiar la implementación por debajo no obligue a tocar cada consumidor. Si tus componentes leen el estado a través de useSeleccion() sin saber si por dentro es un useState, un Zustand o una máquina, migrar de un peldaño al siguiente es reescribir esa única frontera y no cientos de llamadas dispersas. La migración barata no es suerte: es la recompensa de haber programado contra una interfaz en lugar de contra una implementación.

// La frontera estable: los consumidores no saben que hay detras.
export function useSeleccion() {
  const [id, setId] = useState<Id | null>(null);   // hoy: useState local
  return { id, seleccionar: setId };
}
// Manana, si varias vistas lo necesitan, cambias solo el cuerpo por un store;
// los componentes que llaman a useSeleccion no se enteran del cambio.

Bajar de peldaño también es mantenimiento

La escalera se sube bajo demanda, pero también se baja, y esta segunda dirección se practica mucho menos porque cuesta admitir que la disciplina que montaste sobra. Sin embargo, quitar una herramienta pesada de una pieza que nunca la necesitó es de los refactors más liberadores que existen: cada acción, cada reducer y cada selector que borras es superficie de estado que deja de poder fallar. Si heredas una base que adoptó Redux por si acaso y descubres que gobierna cuatro banderas, bajarla a un store ligero no es una regresión, es devolver la arquitectura a la proporción que su problema siempre tuvo.

// Antes: un slice de Redux para alternar una barra lateral.
// createSlice, tipos de accion, reducer, selector y provider... para un booleano.

// Despues: la misma funcionalidad en un store ligero.
const useUI = create<{ abierta: boolean; alternar: () => void }>((set) => ({
  abierta: true,
  alternar: () => set((s) => ({ abierta: !s.abierta })),
}));
// desaparecen el provider, los tipos de accion y el reducer entero

El obstáculo para bajar rara vez es técnico; es psicológico y social. Retirar disciplina se siente como quitar una red de seguridad, aunque esa red nunca haya atrapado nada, y en un equipo siempre hay quien defenderá la herramienta pesada por costumbre o por el esfuerzo ya invertido en aprenderla. El antídoto es medir en vez de discutir: cuenta las líneas de infraestructura que rodean la lógica real y pregunta qué garantía concreta se perdería al quitarlas. Si la respuesta es ninguna, la red no protegía nada, y bajar de peldaño solo elimina peso muerto.