> *Tiempo de lectura estimado: 15-20 minutos.* Pasamos de luchar contra el DOM con jQuery a gestionar estados globales complejos con Redux, luego simplificamos todo con React Query (TanStack Query) para manejar el estado del servidor en el cliente. Hoy, con la llegada de **Next.js 16** y **React 19**, estamos ante un nuevo cambio de paradigma: el retorno al servidor y la simplificación radical de la arquitectura. En este artículo, desglosaremos cómo construir una aplicación robusta, minimalista y mantenible bajo una **Arquitectura Hexagonal**, eliminando dependencias que creíamos imprescindibles (como React Query) y estableciendo una "única fuente de verdad" mediante tipos estrictos con Zod. Basaremos este análisis en un caso práctico común: una **Plataforma de Bienes Raíces (Real Estate)**, donde la gestión de filtros, formularios multipaso y datos complejos es crítica. --- ## 1. El Nuevo Tablero de Juego: Arquitectura Hexagonal Minimalista Antes de hablar de herramientas, hablemos de estructura. El mayor error en proyectos frontend es mezclar *qué hace la aplicación* (Reglas de Negocio) con *cómo se ve* (UI/React). Para solucionar esto, adoptamos una variación estricta de **Puertos y Adaptadores**: ### 📂 `domain/` (La Verdad Inmutable) Aquí vive el negocio puro. **Prohibido importar React, Next.js o librerías de terceros.** - **Entidades:** Tipos TypeScript puros (`type Property`, `type Agent`). - **Repositorios (Puertos):** Interfaces que definen contratos (`IPropertyRepository`). *Si mañana cambias Next.js por Remix o Vue, esta carpeta no se toca.* ### 📂 `application/` (La Orquestación) Contiene los **Casos de Uso**. - Clases o funciones que ejecutan una acción específica: `CreatePropertyListingUseCase`, `GetPropertyBySlugUseCase`. - Aquí se aplica la validación de negocio y se llama a los repositorios. ### 📂 `infrastructure/` (Los Detalles Sucios) Aquí es donde el framework brilla. Es la única capa que "sabe" que estamos usando Next.js. - **UI:** Componentes, Hooks, Stores. - **Implementaciones:** Fetching de datos, adaptadores de DB (Supabase, Firebase). ### 📂 `shared/` (El Pegamento) Utilidades transversales. - **Schemas:** Aquí vive **Zod**. Es crucial que los esquemas estén aquí para ser consumidos tanto por el `domain` (para inferir tipos) como por la `infrastructure` (para validar formularios y APIs). --- ## 2. ¿Por qué ya no necesitas React Query en Next.js App Router? Durante años, `react-query` fue nuestra navaja suiza para solucionar el problema de: *"¿Cómo traigo datos, los cacheo, manejo el loading y revalido?"*. Con **Next.js App Router** y los **React Server Components (RSC)**, el framework ha absorbido estas responsabilidades. ### El problema del "Client-Side Fetching" excesivo En el patrón antiguo ("Pages Router" o SPA): 1. El componente monta. 2. `useEffect` dispara un fetch. 3. Mostramos un spinner. 4. Llega la data -> Renderizamos. Esto causaba **waterfalls** (cascadas de peticiones) y obligaba a tener un gestor de caché complejo en el cliente. ### La Solución Nativa: Fetch + RSC En nuestra arquitectura, el componente de UI (Infrastructure) no hace fetch. El componente es un **Server Component** que llama directamente al Caso de Uso, el cual llama al Repositorio. **Ejemplo de Repositorio en Infraestructura (`infrastructure/api/property-repository.impl.ts`):** ```typescript // Fíjate: Usamos el fetch nativo extendido por Next.js export class ApiPropertyRepository implements IPropertyRepository { async getPropertyBySlug(slug: string): Promise { const res = await fetch(`${process.env.API_URL}/properties/${slug}`, { // 1. Caching automático: Por defecto es 'force-cache' si no es dinámico. // 2. Revalidación basada en tiempo (ISR) o bajo demanda (Tags). next: { tags: [`property-${slug}`], revalidate: 3600 // 1 hora } }); if (!res.ok) return null; // Validamos que lo que viene del backend sea lo que esperamos (Ver sección Zod más abajo) const data = await res.json(); return propertySchema.parse(data); } } ``` ### ¿Cómo reemplazamos las features de React Query? 1. **Caching y Deduplicación:** Next.js hace "Request Memoization". Si llamas a `getPropertyBySlug` en el Layout y luego en la Page, solo se ejecuta un fetch real. 2. **Revalidación (Invalidate Queries):** En lugar de `queryClient.invalidateQueries`, usamos **Server Actions** con `revalidateTag` o `revalidatePath`. 3. **Loading States:** Usamos `Suspense` y `loading.tsx` de Next.js. La UI es declarativa, no gestionada por booleanos `isLoading`. **Conclusión:** Para operaciones de lectura (GET) en Server Components, **React Query es redundante**. Añade peso al bundle JS innecesariamente. Resérvalo solo para interacciones cliente-complejas (polling en tiempo real, scroll infinito puramente cliente). --- ## 3. Estado Global vs. Estado en la URL: La Trampa del Store Otro patrón común que debemos corregir es el abuso de Stores globales (Zustand, Redux, Context). **El mito:** *"Necesito poner el paso actual del formulario en un estado global para que mis componentes sepan dónde están."* **La realidad:** El estado global es volátil. Si el usuario recarga la página, ¿dónde queda su progreso? Si comparte el link, ¿su amigo ve lo mismo? ### La Regla de Oro del Estado Antes de crear un `useStore`, pregúntate: 1. **¿Debería ser compartible?** -> **URL (`searchParams`)**. 2. **¿Viene del servidor?** -> **Server Component Data**. 3. **¿Es efímero de un componente?** -> **`useState` / `useReducer`**. 4. **¿Es estado de un formulario (Loading/Error)?** -> **`useActionState` (React 19)**. 5. **¿Es configuración global de sesión?** -> **Global Store**. ### Gestión de Formularios: Adiós al Store Global con `useActionState` Un antipatrón clásico es almacenar los errores de validación o el estado `isLoading` de un formulario en un Store global o en estados complejos manuales. React 19 introduce `useActionState`, diseñado específicamente para gestionar el resultado de las Server Actions. Este hook encapsula el ciclo de vida de la interacción (envío -> validación servidor -> respuesta), manteniendo el estado localizado y limpio. ```tsx // infrastructure/ui/create-listing-form.tsx const [state, formAction, isPending] = useActionState(createListingUseCase, initialState); // `state` contiene los errores devueltos por el dominio (Zod) // `isPending` se gestiona automáticamente durante la ejecución del Server Action ``` ### Caso de Estudio: El Wizard de Publicación En una app inmobiliaria, publicar una casa requiere varios pasos: (Detalles -> Ubicación -> Fotos). En lugar de un Store, utilizamos la URL. **Mal patrón (Store):** ```typescript // infrastructure/store/listing-store.ts // ❌ Si recargo, vuelvo al paso 1. No puedo compartir el link del paso 3. const useListingStore = create((set) => ({ step: 1, setStep: (step) => set({ step }) })); ``` **Patrón Senior (URL Driven State):** ```tsx // infrastructure/ui/property/listing-flow.tsx import { useSearchParams, useRouter } from 'next/navigation'; export const PropertyListingFlow = () => { const searchParams = useSearchParams(); const step = searchParams.get('step') ?? 'details'; // 'details' | 'location' | 'photos' const navigateTo = (newStep: string) => { // ✅ Actualizamos la URL. El navegador gestiona el historial. // ✅ Al compartir el link, el receptor llega al mismo punto. router.push(`?step=${newStep}`, { scroll: false }); }; return ( <> {step === 'details' && navigateTo('location')} />} {step === 'location' && } ); }; ``` Esto reduce drásticamente la cantidad de código JS que necesitamos mantener y sincronizar. **La URL es el Store más robusto que existe.** --- ## 4. Zod: Tipado Defensivo y "Schema-First" TypeScript nos da seguridad en tiempo de compilación, pero **Zod nos da seguridad en tiempo de ejecución**. En una arquitectura profesional, no confiamos ciegamente en que el Backend cumpla su contrato. ### El Patrón "Schema-First" En lugar de escribir interfaces TS manualmente, escribimos esquemas Zod en `shared/schemas` y derivamos los tipos. ```typescript // shared/schemas/property.ts import { z } from "zod"; export const propertySchema = z.object({ id: z.string().uuid(), title: z.string().min(10), price: z.number().positive(), // Transformación de datos al vuelo: string ISO -> Date Object listedAt: z.string().transform((str) => new Date(str)), isAvailable: z.boolean().default(true) }); // ✨ Magia: Un solo origen de verdad export type Property = z.infer; ``` ### Tipado de Respuestas (Response Parsing) Es común tipar la respuesta de axios/fetch con `as Property`. **Esto es mentira.** Estás forzando al compilador a creer algo que no has comprobado. **Forma Incorrecta (Fe ciega):** ```typescript const data = await res.json() as Property; // 🚩 Riesgo alto si la API cambia ``` **Forma Senior (Parseo Defensivo):** En nuestra capa de infraestructura, usamos `safeParse`. Si el backend cambia el nombre de un campo, nuestra aplicación explota controladamente en la capa de adaptación con un mensaje claro, en lugar de renderizar `undefined` silenciosamente en la UI. ```typescript // infrastructure/api/property-repository.ts const json = await res.json(); const result = propertySchema.safeParse(json); if (!result.success) { console.error("Critical: API Contract Breach", result.error); throw new Error("Error de integridad de datos"); } return result.data; // Aquí TypeScript sabe que es 100% un Property válido ``` ### Reutilización en Formularios El mismo esquema `createPropertySchema` que usas para validar el `POST` en tu API Route (Backend), lo importas en tu componente cliente con `react-hook-form` y `zodResolver`. **Resultado:** Lógica de validación escrita UNA vez, ejecutada en cliente (UX inmediata) y servidor (seguridad). --- ## 5. Rendimiento: ¿El exceso de estados globales afecta? Absolutamente. El uso indiscriminado de Context API o Stores globales mal diseñados provoca el temido **"Render Drilling"**. Un cambio en una propiedad menor del Store puede causar re-renderizados en componentes que ni siquiera usan esa propiedad si no se usan selectores adecuadamente. **Regla de optimización:** 1. **Colocación del Estado (State Colocation):** Mueve el estado lo más abajo posible en el árbol de componentes. 2. **Composición:** Usa `children` para evitar prop drilling sin necesidad de Context. 3. **Server Components:** Mueve toda la lógica de obtención de datos al servidor. Un Server Component no se "re-renderiza" en el cliente, simplemente envía nuevo HTML/RSC Payload. Esto elimina gran parte de la carga de rendimiento de React en el navegador. --- ## 6. React 19: La Limpieza Final Si la arquitectura hexagonal limpia nuestra lógica, **React 19** limpia nuestra sintaxis. Las nuevas primitivas eliminan gran parte del "pegamento" técnico que solíamos escribir en la capa de Infraestructura. ### El Fin de `useMemo` y `useCallback`: React Compiler Hasta ahora, optimizar React requería llenar el código de dependencias manuales `[a, b]` y envolver funciones. Si olvidabas una dependencia, el bug estaba garantizado. Con **React Compiler** (ya disponible en Next.js 16), esto se acabó. El compilador analiza tu código y memoriza automáticamente valores y funciones. * **Antes:** `const handeClick = useCallback(() => { ... }, [dependency])` * **Ahora:** `const handleClick = () => { ... }` El código se vuelve agnóstico a la optimización. Escribes JavaScript normal, y React se encarga de que sea rápido. ### El Hook `use`: Adiós `useEffect` para datos ¿Recuerdas tener que declarar un estado `loading`, luego un `useEffect`, hacer el fetch, setear la data...? El nuevo hook `use` permite consumir Promesas directamente en el renderizado (integrándose con Suspense) y leer Contextos condicionalmente. ```tsx // infrastructure/ui/property-list.tsx import { use } from 'react'; export function PropertyList({ propertyPromise }: { propertyPromise: Promise }) { // 🤯 Se suspende automáticamente hasta que resuelve. // Adiós isLoading, adiós useEffect. const properties = use(propertyPromise); return

{p.title} - {p.price}€

; } ``` ### UX Optimista sin Dolor: `useOptimistic` Implementar actualizaciones optimistas (que la UI cambie antes de que el servidor responda) solía requerir lógica compleja de rollback y caché manual. React 19 nos regala `useOptimistic`. Ideal para interacciones instantáneas como marcar una propiedad como "Favorita": ```tsx // infrastructure/ui/property/favorite-button.tsx import { useOptimistic } from 'react'; export function FavoriteButton({ isFavorite, onToggle }: { isFavorite: boolean, onToggle: () => void }) { const [optimisticFavorite, toggleOptimistic] = useOptimistic( isFavorite, (state) => !state // Lógica visual inmediata ); return ( ); } ``` --- ## Conclusión Desarrollar software nivel Senior no significa usar las librerías más complejas, sino **saber cuándo NO usarlas**. Al adoptar esta arquitectura hexagonal en Next.js: 1. Eliminamos **React Query** a favor de `fetch` nativo y Server Actions. 2. Eliminamos **Stores innecesarios** a favor de la URL (`searchParams`). 3. Eliminamos **Interfaces duplicadas** a favor de inferencia con Zod. 4. Ganamos una estructura donde el dominio es sagrado y la UI es un simple detalle de implementación. La próxima vez que inicies un proyecto, no empieces instalando dependencias. Empieza diseñando tu **Dominio** y tus **Esquemas**. El resto es solo carpintería.