React 19 de Cero a Experto / Nivel producción

Arquitectura por features

Teoría20 min20 XP

Una app pequeña cabe en unas pocas carpetas; una app real, con decenas de pantallas y varias personas tocándola, necesita una ESTRUCTURA que la mantenga entendible. El error clásico es organizar por TIPO de archivo (todos los componentes juntos, todos los hooks juntos) —lo que dispersa cada funcionalidad por toda la app—. La alternativa que escala es organizar por FEATURE: cada funcionalidad en su propia carpeta con todo lo suyo. Hoy cierras el módulo con cómo estructurar una app React que crece sin volverse un laberinto.

El taller ordenado por proyectos, no por herramientas

Por tipo vs por feature

Dos formas de organizar (y por qué una escala)

Por tipo de archivo (común al empezar, no escala):

por-tipo.txt

src/
components/   ← TODOS los componentes de toda la app
  GastoItem.tsx, PerfilCard.tsx, LoginForm.tsx, GraficaGastos.tsx...
hooks/        ← TODOS los hooks
  useGastos.ts, usePerfil.ts, useAuth.ts...
types/        ← TODOS los tipos
  gasto.ts, perfil.ts, usuario.ts...

El problema: la funcionalidad "gastos" está DISPERSA en tres carpetas. Para cambiarla, saltas entre components/, hooks/, types/. A medida que la app crece, cada carpeta se llena de cosas no relacionadas y nada te dice qué archivos van juntos.

Por feature (escala):

por-feature.txt

src/
features/
  gastos/           ← TODO lo de gastos, junto
    GastoItem.tsx
    GraficaGastos.tsx
    useGastos.ts
    gasto.types.ts
    gastos.test.tsx
  perfil/           ← TODO lo de perfil
    ...
  auth/             ← TODO lo de autenticación
    ...
shared/             ← lo REALMENTE compartido entre features
  components/ (Boton, Modal...)
  hooks/ (useLocalStorage...)
  lib/

Cada feature es autocontenida: sus componentes, hooks, tipos y tests VIVEN JUNTOS. Trabajar en gastos es abrir features/gastos/. Lo que de verdad se comparte entre features (un botón genérico, useLocalStorage) va en shared/. La app se lee como lo que hace —una lista de funcionalidades—, no como un montón de tipos de archivo.

Principios que sostienen la estructura

Las reglas prácticas

Más allá de la carpeta, estos principios mantienen la app sana:

Colocación (colocation): mantén junto lo que cambia junto. El test al lado del componente, el hook al lado de donde se usa. Si algo solo lo usa una feature, vive DENTRO de esa feature —no lo subas a "compartido" hasta que dos features lo necesiten de verdad—.
Límites claros entre features: una feature no debería hurgar en los archivos internos de otra. Si "perfil" necesita algo de "gastos", que sea a través de una interfaz pública clara (lo que la feature exporta), no importando sus entrañas. Esto evita el enredo de dependencias.
shared es para lo GENÉRICO, no para lo común "por ahora": sube a shared/ solo lo que es de verdad reutilizable y no pertenece a ninguna feature (un <Boton>, utilidades puras). Resistir la tentación de un cajón de sastre "utils" gigante.
Consistencia sobre perfección: no existe LA estructura perfecta. Lo importante es que el equipo siga una convención predecible: cualquiera que abra el proyecto sepa dónde vive cada cosa. Frameworks como Next.js (SC-07) imponen parte de la estructura por ti (carpetas de rutas).

La meta: que agregar o cambiar una funcionalidad sea abrir UNA carpeta, y que un recién llegado entienda el mapa de la app en minutos. La arquitectura no es sobre reglas rígidas, sino sobre que el código sea fácil de encontrar, cambiar y borrar.

¿Por qué organizar una app React grande por FEATURE escala mejor que por tipo de archivo?

Mini-reto

Reorganiza (en papel) una app de gastos que hoy tiene components/ (GastoItem, GraficaGastos, LoginForm, PerfilCard), hooks/ (useGastos, useAuth) y types/ todos mezclados: 1) agrúpalos en carpetas features/ (gastos, auth, perfil); 2) decide qué iría en shared/ (pista: ¿hay un <Boton> o un useLocalStorage que usen varias?); 3) explica por qué useGastos va DENTRO de features/gastos/ y no en un hooks/ global.

Qué sigue

Cierras el módulo —y casi el curso— con un reto de producción: optimizar una lista lenta de miles de elementos con las técnicas que aprendiste (virtualización). El último ensayo antes del PROYECTO FINAL: el chat colaborativo en tiempo real que reúne todo React 19 que has dominado.