Errores de arquitectura de estado

Ya sabes ubicar cada dato en el plano y asignarle su herramienta. Esta lección enseña lo contrario y complementario: reconocer cuándo alguien lo hizo mal, incluido tu yo de hace seis meses. Porque los errores de arquitectura de estado no son infinitos ni misteriosos; son un catálogo corto de patologías recurrentes, y todas comparten un mismo diagnóstico de fondo. Un error de arquitectura de estado es siempre un desajuste de coordenada: o pusiste el dato en la clase equivocada del plano, o le diste la dosis equivocada de reactividad o de disciplina. Nada más. Vamos a recorrer las patologías más frecuentes como lo haría un médico: primero el síntoma, lo que ves sin abrir nada; luego la causa, el desajuste de coordenada que lo produce; y por último el refactor, el movimiento en el plano que lo cura. Aprende a leer los síntomas y diagnosticarás una base de código ajena en minutos, sin haber escrito una línea de ella.

Errores de clase equivocada: el dato está en la región errónea del plano

La primera familia de errores no es de dosis, sino de ubicación: el dato acabó en una clase que no le corresponde, y arrastra consigo todos los problemas de esa clase ajena. Son los más caros porque parecen funcionar hasta que no lo hacen.

El error cardinal es el estado de servidor viviendo en un store de cliente. El síntoma es inconfundible: banderas de isLoading esparcidas por todas partes, lógica de refetch escrita a mano, datos que se quedan rancios y bugs de invalidación de caché que aparecen y desaparecen. La causa es tratar una copia de algo ajeno como si fuera verdad propia. El refactor es sacarlo del store y dárselo a TanStack Query, que gestiona frescura y revalidación como lo que son, un problema de caché.

El segundo es el estado derivado guardado en lugar de calculado. El síntoma son dos campos que deberían concordar y que, cada cierto tiempo, discrepan —el total del carrito que no cuadra con los artículos, el contador que se queda desfasado—, y casi siempre un efecto escrito para mantenerlos sincronizados a mano. La causa es duplicar una verdad que debería derivarse de otra. El refactor es borrar la copia y calcularla con un useMemo, un selector o un computed, para que sea imposible que difieran.

El tercero es la sopa de booleanos donde tocaba una máquina. El síntoma es la combinación imposible que aparece en pantalla: el spinner girando sobre un mensaje de error, la lista visible mientras el error dice que falló. La causa es modelar modos excluyentes como banderas independientes, de modo que el tipo admite combinaciones que no deberían existir. El refactor es sustituir los booleanos por un estado con transiciones declaradas, una máquina o al menos una unión discriminada, que vuelve irrepresentable lo imposible.

Errores de dosis equivocada: la región es buena, la cantidad no

La segunda familia acierta la clase pero yerra la cantidad: demasiada reactividad, demasiada poca, demasiada disciplina o demasiada poca. Son más sutiles porque el dato está donde debe; lo que falla es su calibración.

El store monstruo es el arquetipo del exceso de centralización con reactividad demasiado gruesa. El síntoma es que cualquier cambio, por pequeño que sea, despierta a media aplicación, y nadie sabe ya por qué se recomputa lo que se recomputa. La causa es haberse saltado la clasificación y usar un único objeto global para las siete clases a la vez. El refactor es partirlo por clase, colocar cada trozo donde se usa y afinar la propagación con selectores o átomos.

Su espejo es el estado sobreelevado. El síntoma es un dato que vive muchos pisos por encima de donde se usa, con cadenas de props interminables o un contexto que hace re-renderizar ramas enteras por un valor que solo mira una hoja. La causa es violar la regla de la altura: no usar el nivel más bajo que resuelve. El refactor es bajar el estado hasta su punto de uso, o poner el límite de contexto justo donde empieza a hacer falta.

La cadena de efectos que sincroniza estado es la patología reactiva por excelencia en React. El síntoma son varios useEffect encadenados que reaccionan unos a otros, renders de más, parpadeos de estados intermedios y carreras difíciles de reproducir. La causa es usar el efecto como mecanismo de propagación —reactividad manual y a destiempo— en lugar de derivar. El refactor casi siempre es calcular el valor durante el render o mover el evento a su origen; la mayoría de esos efectos, sencillamente, sobran.

Y en el otro extremo del eje de la disciplina está la ceremonia injustificada. El síntoma es Redux con tres archivos para un interruptor, o una máquina de estado para una bandera de dos valores. La causa es elegir una coordenada de disciplina más alta de la que el problema pedía. El refactor es bajar: un useState para el interruptor, un useReducer para lo que apenas crece. La disciplina de más no es virtud, es peaje.

flowchart TD
SINT[Sintoma en tu app] --> A{el dato se queda rancio o refetcheas a mano?}
A -->|si| C1[servidor en store: pasalo a TanStack Query]
A -->|no| B{dos campos que deben concordar se desincronizan?}
B -->|si| C2[derivado guardado: calculalo con un memo]
B -->|no| D{ves combinaciones imposibles en pantalla?}
D -->|si| C3[sopa de booleanos: modela con una maquina]
D -->|no| E{todo se re-renderiza ante cualquier cambio?}
E -->|si| C4[store monstruo: separa por clase y afina selectores]
E -->|no| C5[revisa la altura y la dosis de disciplina]
style SINT fill:#f38ba8,color:#11111b
style C1 fill:#a6e3a1,color:#11111b
style C3 fill:#f9e2af,color:#11111b
style C4 fill:#89b4fa,color:#11111b