Tres antipatrones que arruinan la arquitectura

Las lecciones anteriores construyeron reglas: separa las clases de estado, elige la disciplina que el problema merece, empieza simple y sube cuando duela. Esta lección las mira por su reverso, porque las reglas se entienden mejor a través de sus violaciones más características. Un antipatrón no es cualquier error: es un error tan común, tan tentador y tan destructivo que la comunidad le ha puesto nombre para poder señalarlo de lejos. Los tres que siguen —el store global que lo devora todo, el servidor metido en Redux, la arquitectura formal sobre un booleano— no son casos raros de mala praxis, sino los tres modos en que aplicaciones enteras, escritas por gente competente, se vuelven imposibles de mantener. Reconocerlos por su síntoma es la otra mitad de saber diseñar: la teoría dice qué hacer, los antipatrones dicen qué te delatará cuando dejes de hacerlo.

Antipatrón uno: todo en un store global

El primero es el más difuso y por eso el más extendido: el store global que empieza guardando algo legítimo y termina siendo el vertedero donde vive todo el estado de la app, sin distinción de clase. El síntoma que lo delata es un store cuyo árbol de estado no cabe en la cabeza: apariencia efímera de un desplegable junto a la sesión del usuario, junto a una lista traída del servidor, junto al borrador de un formulario. Cuatro clases con cuatro naturalezas, pudriéndose en el mismo cajón.

La causa es la negación de la primera lección: no clasificar. Cuando el store global es lo primero que montas, todo tiende a caer en él por gravedad, porque es el sitio más cómodo para poner cualquier cosa. El coste llega despacio y luego de golpe: cada componente se re-renderiza por cambios que no le incumben, nadie sabe qué parte del estado es dueña de su verdad y qué parte es copia, y el store se vuelve un acoplamiento global donde cualquier pieza puede depender de cualquier otra. La corrección es la de la lección uno: saca cada pieza a la herramienta de su clase —la apariencia efímera a useState, el servidor a la cache, lo navegable a la URL— y observa cuánto encoge lo que de verdad merecía estar en el store.

Antipatrón dos: el servidor dentro de Redux

El segundo es el más específico y el más caro, y define toda una era de la disciplina: guardar el estado del servidor en el store de cliente. El síntoma es inconfundible: acciones, reducers y thunks cuyo único trabajo es pedir un dato a la API, guardarlo, y mantenerlo sincronizado a mano. Cientos de líneas que no expresan ninguna regla de tu dominio, solo la mecánica de una cache reimplementada peor de lo que ya existe.

La causa es cruzar la frontera sagrada de la lección uno, la que separa lo que posees de lo que solo lees. El estado del servidor es una cache con problemas de obsolescencia, revalidación y deduplicación, y un store de cliente no sabe nada de eso: te obliga a reconstruir a mano toda la maquinaria que TanStack Query te da hecha. La corrección es quirúrgica y de altísimo rendimiento: identifica cada dato que vino de una petición HTTP, sácalo del store, y dáselo a una cache dedicada. Con él se van los reducers y thunks que solo existían para leerlo.

// Antipatron: el servidor vive en el store, sincronizado a mano.
const slice = createSlice({
  name: 'usuarios',
  initialState: { lista: [], cargando: false, error: null },
  reducers: {
    peticionIniciada: (s) => { s.cargando = true; },
    peticionExito: (s, a) => { s.lista = a.payload; s.cargando = false; },
    peticionFallo: (s, a) => { s.error = a.payload; s.cargando = false; },
  }, // una cache casera, peor y con bugs de obsolescencia
});

// Correccion: una cache de verdad se encarga de todo eso.
const { data, isPending, isError } = useQuery({
  queryKey: ['usuarios'],
  queryFn: traerUsuarios,
  staleTime: 60_000, // frescura, revalidacion y deduplicacion incluidas
});

Antipatrón tres: sobre-arquitecturar lo trivial

El tercero es el reverso exacto del segundo en el eje de la disciplina: en lugar de meter demasiado en una herramienta, se pone demasiada herramienta alrededor de muy poco. El síntoma es la ceremonia sin lógica: un archivo de acciones, un reducer, un selector y un test, todo para alternar un booleano que un useState resolvía en una línea. Mucha infraestructura rodeando una lógica que cabría en un renglón.

La causa es invertir la escalera de la lección tres: adoptar el peldaño alto por si acaso, en vez de subir a él cuando el dolor lo pide. Se disfraza de rigor —usar la herramienta seria se siente profesional— pero es un impuesto que pagan a diario todos los que leen y modifican ese código, a cambio de garantías que un booleano no necesita. La corrección es bajar de peldaño sin miedo: si no hay estados imposibles que prevenir, no hace falta máquina; si no hay dominio que auditar, no hace falta arquitectura formal. La herramienta correcta para lógica trivial es la trivial.

flowchart TD
P1[todo en un store global] -->|corregir| F1[una herramienta por clase de estado]
P2[servidor dentro de Redux] -->|corregir| F2[cache dedicada TanStack Query]
P3[arquitectura formal sobre un booleano] -->|corregir| F3[useState o store ligero]
style P1 fill:#f38ba8,color:#11111b
style P2 fill:#f38ba8,color:#11111b
style P3 fill:#f38ba8,color:#11111b
style F1 fill:#a6e3a1,color:#11111b
style F2 fill:#a6e3a1,color:#11111b
style F3 fill:#a6e3a1,color:#11111b

El antipatrón que finge no serlo: guardar lo derivable

Hay un cuarto error que merece mención porque se disfraza de estado legítimo mejor que los otros tres: guardar en el estado un valor que podría calcularse a partir de otro. El total de un carrito junto a sus líneas, el contador de no leídos junto a la lista de mensajes, el nombre completo junto al nombre y el apellido. Parece estado y no lo es: es una consecuencia, y guardarla crea la obligación de recalcularla en cada mutación de su fuente, con el riesgo permanente de que las dos versiones discrepen.

// Antipatron: el total vive en el estado y hay que recalcularlo a mano.
type Carrito = { lineas: Linea[]; total: number };
function anadir(c: Carrito, l: Linea): Carrito {
  return { lineas: [...c.lineas, l], total: c.total + l.precio }; // dos fuentes de verdad
}

// Correccion: el total se deriva de las lineas y no puede desincronizarse.
type CarritoSano = { lineas: Linea[] };
const total = (c: CarritoSano) => c.lineas.reduce((s, l) => s + l.precio, 0);

El síntoma es el bug de sincronización interno: el total dice diez y las líneas suman doce porque alguien actualizó unas sin la otra. La corrección la dio el bloque de Niveles 6 al 8: no lo guardes, derívalo. Un valor computado a partir de su fuente no puede quedar desincronizado, porque no tiene una existencia propia que haya que mantener al día. Antes de asignarle herramienta a cualquier dato, pregúntate si es fuente o consecuencia; si se deduce de otro, no es estado y no entra en ninguna clase.

Fíjate en que los tres antipatrones tienen correcciones que apuntan en direcciones distintas —repartir, extraer, adelgazar— pero nacen del mismo gesto equivocado, y esa raíz común es lo que conviene grabar por encima de los tres casos concretos.