¿Qué es el props drilling en React? Guía de arquitectura y soluciones
Tiempo estimado de lectura: 4 min
- Props drilling es pasar props a través de varios niveles que no las usan.
- Opciones: composición, Context API o stores externos según alcance y frecuencia de cambio.
- Decisión técnica: privilegia composición; Context para valores estables; store para coordinación entre subsistemas.
Resumen rápido (lectores con prisa)
Props drilling: pasar datos por componentes intermedios que no los usan. Si atraviesa pocos niveles (<3) suele estar bien; si escala, considerar composición, Context o un store externo. Elige según alcance, frecuencia de cambio y acoplamiento.
¿Qué es el props drilling en React?
El props drilling en React es cuando pasas propiedades a través de múltiples niveles de componentes que no las usan, solo las retransmiten hasta el componente que sí las necesita.
Ejemplo visual:
App (tiene user)
└─ Layout
└─ Sidebar
└─ Menu
└─ UserProfile (usa user)
Código mínimo:
function App() {
const user = { name: "Ana", avatar: "/ana.jpg" };
return <Layout user={user} />;
}
function Layout({ user }) { return <Sidebar user={user} />; }
function Sidebar({ user }) { return <UserProfile user={user} />; }
function UserProfile({ user }) { return <img src={user.avatar} alt={user.name} />; }Layout y Sidebar no necesitan user. Solo lo llevan. Eso genera acoplamiento y ruido en el código.
¿Cuándo es un problema real?
No todo props que viaja es pecado. Pasar props uno o dos niveles es totalmente aceptable. El problema aparece cuando:
- La propiedad atraviesa tres o más niveles.
- Múltiples props no relacionadas llenan la firma de componentes intermedios.
- Mover un componente exige recablear docenas de firmas.
- Los re-renders se disparan y el rendimiento cae.
Consecuencias prácticas: acoplamiento innecesario, refactors costosos, más tests y mayor probabilidad de bugs al cambiar la forma del dato.
Soluciones (con criterio técnico)
No hay varita mágica. Hay herramientas y criterios para escoger la correcta.
1) Composición de componentes (cuando aplica)
Primera regla: intenta composición antes que librerías. Si el componente final vive en un subárbol que puedes construir desde el padre que tiene el dato, inyecta el subárbol.
function App() {
const user = { name: "Ana", avatar: "/ana.jpg" };
return (
<Layout sidebar=&{`Ventaja: cero dependencias, cero props intermedios. Referencia: docs de React sobre composición
Cuándo usar: datos locales a una sección, poco compartidos fuera del subárbol.
2) Context API (cuando el dato es global y estable)
Context te permite proveer un valor desde arriba y consumirlo en cualquier punto del árbol, sin pasar props intermedios.
const UserContext = React.createContext(null);
function App() {
const user = { name: "Ana" };
return <UserContext.Provider value={user}><Layout /></UserContext.Provider>;
}
function UserProfile() {
const user = useContext(UserContext);
return <span>{user.name}</span>;
}Docs oficiales: React Context
Advertencia: Context es ideal para valores que cambian poco (tema, idioma, sesión). Si el valor cambia con alta frecuencia, todos los consumidores se re-renderizan y el rendimiento puede sufrir.
3) Estado global / stores (cuando la app escala)
Cuando múltiples partes desconectadas del árbol necesitan leer y escribir el mismo estado, un store fuera del árbol es la opción práctica.
Opciones razonables hoy:
- Zustand: simple, sin boilerplate, buen rendimiento.
- Redux Toolkit: trazabilidad y patterns para apps enterprise.
- Jotai/Recoil: atom-based state para control fino de re-renders.
No uses un store global por moda. Úsalo cuando la composición y Context se queden cortos.
Cómo decidir (lista rápida)
Hazte estas preguntas antes de refactorizar:
- ¿Cuántos niveles atraviesa la prop? (<3 → probablemente ok)
- ¿Los componentes intermedios la usan? (si sí, deja el flujo)
- ¿El dato cambia con frecuencia? (si sí, evita Context)
- ¿Se comparte entre partes no relacionadas de la UI? (si sí, considera un store)
Si la respuesta apunta a complejidad real, planifica: migración por fases, pruebas y medición de re-renders.
Buenas prácticas finales
- Mantén el estado lo más cerca posible del lugar donde se usa.
- Prefiere composición cuando sea viable.
- Usa Context para datos estables.
- Reserva stores externos para coordinación entre subsistemas.
- Evita micro-optimizaciones prematuras: primero estructura, luego perf.
Referencias útiles
Esto no acaba aquí: en el siguiente post veremos cómo migrar un árbol con props drilling a Zustand paso a paso, sin romper la app ni a los desarrolladores. Suscríbete al boletín de Dominicode para recibir la guía y los snippets listos para copiar.
FAQ
- ¿Qué es exactamente el props drilling?
- ¿Cuándo puedo ignorarlo?
- ¿Cuándo usar Context en lugar de un store?
- ¿La composición siempre es la mejor opción?
- ¿Qué problemas de rendimiento trae Context?
- ¿Qué store elegir si la app escala?
¿Qué es exactamente el props drilling?
Es el patrón donde pasas propiedades desde un componente superior hasta uno profundo, atravesando componentes intermedios que no las usan. Genera firmas de props infladas y acoplamiento innecesario.
¿Cuándo puedo ignorarlo?
Cuando la prop atraviesa uno o dos niveles y no complica el mantenimiento. No todo pasaje de props requiere refactor.
¿Cuándo usar Context en lugar de un store?
Usa Context para valores globales y estables (tema, idioma, sesión). Evita Context para datos que cambian con alta frecuencia o requieren escrituras concurrentes desde múltiples partes.
¿La composición siempre es la mejor opción?
No siempre, pero es la primera estrategia a intentar: sin dependencias y con menor acoplamiento cuando puedes construir el subárbol desde el padre que tiene el dato.
¿Qué problemas de rendimiento trae Context?
Si el valor del Provider cambia con frecuencia, todos los consumidores se re-renderizan, lo que puede impactar el rendimiento. Se puede mitigar con memos, splitting de contexts o stores que controlen re-renders finos.
¿Qué store elegir si la app escala?
Depende: Zustand para simplicidad y rendimiento, Redux Toolkit para trazabilidad en enterprise, y Jotai/Recoil para control fino de re-renders.
