Contenido del curso
Composición de componentes
- 3

Composición de Componentes en React: Principios y Prácticas
13:29 min - 4

Composición y Colocación de Estado en React con Patrones de Renderización
11:47 min - 5

Optimización de Composición de Componentes en React
05:03 min - 6

Composición Saludable con React Context en Aplicaciones React
Viendo ahora - 7

Eliminación de React Context mediante Custom Hooks en React
09:39 min
Render props
- 8

Render Props y Render Functions en React: Patrones Avanzados
06:50 min - 9

Render Props en React: Mejora de Componentes con Ejemplo de To-Do List
13:29 min - 10

Validación y optimización de Render Props y Render Functions en React
12:40 min - 11

Uso de React.Children y React.CloneElement para Composición Avanzada
12:05 min
High Order Components
- 12

Funciones y Componentes de Orden Superior en JavaScript y React
07:17 min - 13

Práctica de High-Order Components en React
14:02 min - 14

Sincronización de Cambios en React con StorageListener
16:17 min - 15

Sincronización de Estados en React con Local Storage
16:05 min - 16

Sincronización y validación de to-do list con local storage
04:20 min
React Hooks
Próximos pasos
Composición Saludable con React Context en Aplicaciones React
Resumen
Cuando trabajamos con React Context, es tentador consumirlo en cada componente que necesite datos. Sin embargo, existe una forma mucho más limpia de estructurar una aplicación: combinar React Context con una buena composición de componentes. Esto permite reducir llamados innecesarios al contexto y mantener una arquitectura clara, donde cada componente recibe solo lo que necesita sin intermediarios.
¿Cómo mover los llamados de contexto a un solo componente padre?
La primera mejora consiste en centralizar los llamados a React Context en un único componente, en este caso AppUI, en lugar de que cada componente hijo consuma el contexto por su cuenta [01:05].
- Se cortan las propiedades
totalTodosycompletedTodosdelTodoCountery se pasan como props desdeAppUI. - Se elimina el
importdel contexto y el llamado auseContextdentro deTodoCounter. - Se repite el mismo proceso con
TodoSearch, moviendosearchValueysetSearchValuecomo props [02:15].
El resultado es que los componentes TodoCounter y TodoSearch ya no dependen directamente de React Context. Reciben su información como propiedades, lo cual los hace más reutilizables y fáciles de testear.
¿Qué problema aparece al introducir un componente intermedio como TodoHeader?
El escenario se complica cuando se introduce un componente TodoHeader que envuelve tanto al contador como al buscador dentro de un elemento <header> [03:20]. Al hacer esto sin composición adecuada, surge el problema conocido como prop drilling: AppUI debe enviar todas las propiedades a TodoHeader, y este a su vez debe reenviarlas a TodoCounter y TodoSearch.
TodoHeadertermina recibiendo propiedades que no utiliza directamente.- Solo actúa como intermediario, pasando
totalTodos,completedTodos,searchValueysetSearchValuea sus hijos. - El código se vuelve más difícil de mantener a medida que crece la jerarquía.
Este patrón es exactamente lo que queremos evitar.
¿Cómo aplicar composición con children para eliminar el prop drilling?
La solución es usar la propiedad especial children de React [06:08]. En lugar de que TodoHeader defina internamente qué componentes renderiza, se le permite recibir sus hijos desde el componente que lo invoca.
¿Qué cambia dentro de TodoHeader?
- Se eliminan todas las props específicas como
totalTodososearchValue. - Se recibe únicamente
childreny se renderiza dentro del elemento<header>. - Ya no necesita importar
TodoCounterniTodoSearch.
¿Cómo queda el componente AppUI?
En AppUI, se llama a TodoHeader como un componente con etiqueta de apertura y cierre. Dentro se colocan TodoCounter y TodoSearch directamente, pasándoles sus props correspondientes [06:45].
jsx <TodoHeader> <TodoCounter totalTodos={totalTodos} completedTodos={completedTodos} /> <TodoSearch searchValue={searchValue} setSearchValue={setSearchValue} /> </TodoHeader>
Con este patrón, no importa cuántos niveles de profundidad existan entre AppUI y los componentes que necesitan los datos. Pueden ser nietos, bisnietos o incluso más profundos en la jerarquía. La comunicación es directa porque AppUI define qué componentes se renderizan y qué datos reciben.
¿Por qué esta composición es más saludable?
- Se evita que componentes intermedios manejen props que no les corresponden.
- Se reduce la dependencia de
useContexta un solo punto de la aplicación. - Los componentes hijos se mantienen puros y desacoplados del mecanismo de estado global.
- La estructura queda preparada para, en aplicaciones más pequeñas, incluso prescindir completamente de React Context [07:55].
El concepto de children en React es fundamental para lograr este tipo de arquitectura flexible. Permite que un componente contenedor no necesite conocer de antemano qué va a renderizar, delegando esa responsabilidad al componente padre que lo utiliza.
Si tu aplicación no tiene una jerarquía de componentes extremadamente profunda, esta composición puede ser suficiente para manejar el estado sin necesidad de un contexto global. ¿Has probado a refactorizar tus componentes usando children en lugar de pasar props por múltiples niveles? Comparte tu experiencia.