Patrones de Diseño en React: Cómo escribir componentes limpios y reutilizables
Tiempo estimado de lectura: 4 min
- Ideas clave:
- Extrae lógica de datos a Custom Hooks y mantén componentes como responsables solo de UI.
- Usa composición y useMemo para optimizar y evitar God Components.
- Evita prop‑drilling; adopta Context + custom hooks cuando el estado cruza >3 niveles.
- La IA puede acelerar producción de código, no la arquitectura: automatiza políticas en CI.
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} onChange={e => 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} onChange={setQ} />
<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
- 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) - Mantén componentes visuales puros. Un
UserCardno debería conocerfetchnirouting. - Usa composición en lugar de herencia. Componer es construir UIs como funciones matemáticas: predecible y testeable. (ver: render-and-commit)
- Evita prop-drilling: si pasas props más de 3 niveles, introduce Context + custom hook para leer/escribir estado (passing-data-deeply-with-context).
- Encapsula validaciones y transformaciones en funciones puras o selectors fuera del render.
- 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
fetcho 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?
useMemo para evitar recomputaciones costosas cuando el cálculo depende de entradas estables (arrays, listas) y cuando el coste de la memoización es menor que el cálculo en renders frecuentes.
