Revision de Componentes Frontend

El Problema

Los componentes frontend empiezan simples y crecen hasta ser masas enredadas. Un componente “simple” de tarjeta acumula 15 props, 3 hooks useState, 2 efectos useEffect y estilos inline. Los props perforan 4 niveles de anidamiento porque “el context parecia excesivo.” Cada tecla en un input de busqueda re-renderiza 200 elementos de lista porque la funcion de filtro se recrea en cada render.

El Prompt

Revisa los siguientes componentes frontend. Actua como un arquitecto frontend evaluando escalabilidad, rendimiento y composicion limpia.

FRAMEWORK: [React / Vue / Svelte / Astro]
TIPO DE COMPONENTE: [ej. formulario, tabla de datos, navegacion, widget de dashboard]

CODIGO:
[pegar codigo del componente aqui]

Evalua en estas dimensiones:

1. **Responsabilidad del Componente**
   - Cada componente hace una cosa (presentacion O logica, no ambas)?
   - Los componentes tienen menos de 150 lineas?
   - Deberia dividirse en container (logica) + presentational (UI)?

2. **Props & API**
   - La interfaz de props es limpia (menos de 7 props)?
   - Los props perforan 3+ niveles (deberia usar context/store)?
   - Los callback props son estables (envueltos en useCallback)?

3. **Gestion de Estado**
   - El estado esta lo mas cerca posible de donde se usa?
   - El estado derivado se computa (useMemo) en vez de sincronizar con useEffect?
   - Hay variables de estado redundantes que pueden derivarse de otras?

4. **Rendimiento de Renderizado**
   - Los items de lista estan envueltos en React.memo?
   - Las computaciones costosas estan memoizadas?
   - Las dependencias de useEffect incluyen referencias inestables?

5. **Efectos Secundarios**
   - Los useEffects tienen funciones de limpieza?
   - Los fetch estan deduplicados (useSWR/React Query en vez de useEffect raw)?
   - Hay estados de loading/error/empty para datos async?

6. **Composicion**
   - El arbol de componentes es plano o profundamente anidado?
   - Se usan slots/children/render props para composicion flexible?

Para cada problema, proporciona:
- **Componente**: Nombre y archivo
- **Severidad**: Reescribir / Refactorizar / Optimizacion / Estilo
- **Problema**: Por que dana escalabilidad o rendimiento
- **Fix**: Codigo refactorizado

Ejemplo de Salida

## Revision de Componentes Frontend: 5 problemas encontrados

### Refactorizar: Prop Drilling por 4 Niveles
Componente: App → Layout → Sidebar → NavItem (prop user)
Fix: Usar React context:
  const UserContext = createContext<User | null>(null);

### Optimizacion: Lista Re-renderiza en Cada Tecla
Fix:
  const filtered = useMemo(
    () => results.filter(r => r.name.includes(query)),
    [results, query]
  );

### Refactorizar: useEffect Sincronizando Estado Derivado
Codigo:
  const [fullName, setFullName] = useState('');
  useEffect(() => setFullName(first + ' ' + last), [first, last]);
Fix: Derivar directamente: const fullName = `${first} ${last}`;

Cuando Usar

Ejecutar al revisar PRs de componentes, cuando una pagina se siente lenta, o cuando un componente ha crecido mas de 200 lineas. Esencial al construir un design system.

Tips Pro

• Incluir el arbol de componentes — muchos problemas viven en la relacion entre componentes, no dentro de uno solo.
• Perfilar antes de memoizar — usar React DevTools Profiler para identificar bottlenecks reales de re-render.
• Pedir plan de descomposicion — “Descompone esto en capas de atomic design: atomos, moleculas, organismos.”