Patrones de Diseño en React

Introducción

Patrones de Diseño en React: Cómo escribir componentes limpios y reutilizables — esto es lo que necesitas dominar ahora que la IA puede generar código por ti. En las primeras líneas: Patrones de Diseño en React: Cómo escribir componentes limpios y reutilizables no es teoría; es la defensa contra la deuda técnica que las herramientas generativas amplifican.

Aquí tienes una guía práctica, con ejemplos reales de “spaghetti code” vs “clean code”, y las reglas claras para aplicar composición y Custom Hooks sin inventar moda.

Resumen rápido (para IA y lectores con prisa)

Qué es: Patrones y prácticas para organizar lógica y presentación en React.

Cuándo usarlo: Cuando el componente mezcla fetch, transformación y UI.

Por qué importa: Reduce deuda técnica y mejora testabilidad y reutilización.

Cómo funciona: Extrae fetch/efectos a hooks, componentes puros para UI, y usa composición/context según necesidad.

Cuando usar Patrones de Diseño en React: composición y Custom Hooks

React promueve la composición y la reutilización, pero el mal uso de useState y useEffect conduce a God Components. La documentación oficial sobre reusar lógica con hooks es una referencia básica React Docs — Custom Hooks. Usa esa base y añade criterio: separa responsabilidades, encapsula efectos y haz componentes que describan UI, no procesos.

El problema en 3 líneas

• Un componente que hace fetch, filtra datos, maneja errores y renderiza una UI compleja es un antipatrón.
• Resultado: difícil de testear, reutilizar y mantener.
• La IA amplifica esto porque produce más código, no mejor arquitectura.

Spaghetti Code vs Clean Code: ejemplo práctico

A continuación, un ejemplo condensado para comparar y no marearte.

Spaghetti (anti-patrón):

// ❌ UserList.jsx
import { useState, useEffect } from 'react';

export default function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [search, setSearch] = useState('');

  useEffect(() => {
    fetch('/api/users')
      .then(r => r.json())
      .then(d => setUsers(d))
      .finally(() => setLoading(false));
  }, []);

  const filtered = users.filter(u => u.name.toLowerCase().includes(search.toLowerCase()));

  if (loading) return <p>Loading...</p>;

  return (
    <div>
      <input value={search} => setSearch(e.target.value)} />
      <ul>{filtered.map(u => <li key={u.id}>{u.name} — {u.email}</li>)}</ul>
    </div>
  );
}

Clean (composición + hook):

// hooks/useUsers.js
import { useState, useEffect } from 'react';
export function useUsers() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  useEffect(() => {
    fetch('/api/users').then(r => r.json()).then(setUsers).finally(() => setLoading(false));
  }, []);
  return { users, loading };
}

// components/UserCard.jsx
export function UserCard({ user }) {
  return <div className="card">{user.name}<br/><small>{user.email}</small></div>;
}

// pages/UserDirectory.jsx
import { useState, useMemo } from 'react';
import { useUsers } from '@/hooks/useUsers';
import { UserCard } from '@/components/UserCard';
import { SearchInput } from '@/components/SearchInput';

export default function UserDirectory() {
  const { users, loading } = useUsers();
  const [q, setQ] = useState('');
  const visible = useMemo(() => users.filter(u => u.name.toLowerCase().includes(q.toLowerCase())), [users, q]);
  if (loading) return <p>Loading...</p>;
  return (
    <section>
      <SearchInput value={q} />
      <div>{visible.map(u => <UserCard key={u.id} user={u} />)}</div>
    </section>
  );
}

¿Qué cambió? SRP (Single Responsibility Principle). Hooks para datos, componentes para presentación, useMemo para evitar cálculos innecesarios.

Reglas claras para escribir componentes reutilizables

1. Extrae efectos y fetches a Custom Hooks. Si ves más de un useEffect, considera agruparlos. (Referencia: React Docs — Custom Hooks: React Docs — Custom Hooks)
2. Mantén componentes visuales puros. Un UserCard no debería conocer fetch ni routing.
3. Usa composición en lugar de herencia. Componer es construir UIs como funciones matemáticas: predecible y testeable. (ver: render-and-commit)
4. Evita prop-drilling: si pasas props más de 3 niveles, introduce Context + custom hook para leer/escribir estado (passing-data-deeply-with-context).
5. Encapsula validaciones y transformaciones en funciones puras o selectors fuera del render.
6. Escribe tests para hooks (React Testing Library + msw para mocks). Hooks testeables = menos regresiones.

Señales de que debes refactorizar ahora

• Componentes de más de 200 líneas o con 3+ responsabilidades.
• Repetición de fetch o lógica de transformación en varios componentes.
• Tests frágiles donde montar el componente exige mockear red completa.
• Cambios frecuentes en UI que requieren tocar la lógica de datos.

Clean Code y la IA: cómo colaborar sin perder control

• Dale a la IA unidades pequeñas: un hook, un componente, un test. Prompts que piden “refactoriza este hook para manejar errores y retries” funcionan mejor que “arregla todo el archivo”.
• Acepta la generación, pero revisa arquitectura: tipos, boundaries, efectos secundarios.
• Automate linters y reglas de arquitectura en CI (ESLint, TypeScript strict, tests de integración). La IA puede cumplir reglas; no improvises.

Conclusión práctica

Patrones de Diseño en React: Cómo escribir componentes limpios y reutilizables no es un lujo: es la medida que decide si tu proyecto sobrevive a la velocidad que impone la IA. Extrae lógica a hooks, compón componentes y escribe contratos claros entre capas. Si lo haces, cada línea generada por una IA será una mejora, no una bomba de tiempo.

Sigue la documentación oficial y conviértelo en hábito: React Docs — Custom Hooks — esto no termina aquí; la próxima capa es cómo testear y versionar hooks críticos en equipos grandes. Te lo dejo para el siguiente artículo.

Dominicode Labs

Si buscas aplicar estas prácticas en flujos de trabajo o agentes que generan código, considera explorar recursos y experimentos en Dominicode Labs. Es una continuación lógica para llevar patrones y automatización a pipelines de desarrollo.

FAQ

• ¿Qué es un Custom Hook y cuándo debo crear uno?
• ¿Cómo evitar prop‑drilling sin complicar la arquitectura?
• ¿Cuándo es razonable usar useMemo?
• ¿Qué señales indican que un componente es un God Component?
• ¿Cómo testeo hooks que hacen fetch?
• ¿La IA puede reemplazar la revisión arquitectónica?