react-puro-19
  • React Puro - 19
  • code
    • README
    • README
    • README
    • README
    • README
    • README
    • README
    • README
  • 7-state-en-clases
    • Ejemplo inicial: un contador
    • Manejo de eventos
    • El state
    • Sintaxis limpia en Class Components
    • setState es Asincrónico
    • Fusión superficial vs profunda
  • 5-children
    • Personalizar Children antes de renderizar
    • PropTypes para Children
    • Los Children
    • Diferentes tipos de Children
    • Manejando uso Children
  • 13-hook-usereducer
    • Qué es un Reducer?
    • Un ejemplo más practico
    • Entonces, Redux murió?
  • 4-proptypes
    • Documentación y depuración incluida
    • PropTypes como documentación
    • Cómo validar, formas comunes
    • Ejemplo Tweet con PropTypes
  • 3-props
    • Comunicación con componentes Padre
    • Las Props:
    • Pasar Props
    • Recibir Props
    • Ejemplo Tweet con Props
  • 11-pensando-uso-state
    • "Tipos" de componentes
    • Qué colocar en el State
    • Dónde mantener el estado
    • Pensando declarativamente
  • 9-requests-api
    • Intro
    • Eligir libreria HTTP
    • Obtener datos y mostrarlos
  • 10-state-en-funciones
    • El useState Hook
    • Actualizar State basado en State anterior
    • State como un Array
    • Reglas de los Hooks
    • La "magia" de los Hooks
    • State como un Objeto
    • Intro Hooks
  • 15-api-context
    • Usando React API Context
    • Patrón "Slots"
    • Patrón "Render Props"
    • Intro API Context
    • Otros Patrones de Context
    • Ejemplo perforación de props
    • hook_usecontext
  • 8-ciclo-vida-componente
    • Fases
    • El ciclo
    • Manejo de errores
    • Desmontaje
    • Representación
    • Montaje
  • 14-hook-useeffect
    • Límite cuando se ejecuta un Effect
    • Hacer cambios visibles del DOM
    • Obtener datos (Fetch) con useEffect
    • Intro useEffect
    • Re-obtener datos (Re-Fetch) cuando cambian
    • Solo ejecución en montaje y desmontaje
  • 2-jsx
    • Ejemplo componente Tweet:
    • JSX:
    • Trabajando con JSX:
  • 12-controles-entrada
    • Entradas controladas
    • Entradas no controladas
  • 6-github-file-list
    • Parte 2: la Prop 'key'
    • Parte inicial
  • 1-hola_mundo
    • Hola mundo:
Con tecnología de GitBook
En esta página

¿Te fue útil?

  1. 15-api-context

Patrón "Render Props"

El contexto de Consumer espera que su hijo sea una función única. Esto se llama patrón "render props":

<UserContext.Consumer>
    {user => (
        <div> {user.name} </div>
    )}
</UserContext.Consumer>

El nombre "render props" proviene de la idea de que una de las props que se está pasando (prop de children, en este caso) es una función que se llama para renderizar el resultado.

Esta sintaxis se verá extraña si no se está acostumbrado. Si se observa, la función de flecha dentro de las llaves {user => (...)} es una expresión de JavaScript, el mismo tipo que se ha visto entremezclado con JSX en repetidas ocasiones.

Observar también que la prop de función de render no se llama de inmediato. Esto retrasa la ejecución hasta que UserContext.Consumer decida llamar a esa función, lo que significa que puede "esperar" hasta que user esté disponible.

El patrón de render props es bueno porque permite indicar: "Sé lo que quiero renderizar aquí, pero todavía no tengo todos los datos". Pasar esa función permite decidir cuál será la salida, pero permite que el componente (UserContext.Consumer en este caso) decida cuándo y dónde representar esa salida.

El Consumer llamará a su función en el momento de representación (render), pasando el valor que obtuvo del Provider en algún lugar por encima (o el valor predeterminado del contexto, o indefinido).

Si se olvida pasar una función hija al Consumer y, en su lugar, se pasa JSX regular, se recibirá un error que dice "render is not a function".

Si se necesita envolver el contenido con algún otro elemento, colocar esos elementos de envoltura afuera y alrededor del Consumer, en lugar de adentro. No hay que preocuparse de que el Consumer presente alguna división de envoltura ni nada. Es invisible en lo que respecta a la estructura DOM.

Provider acepta un valor

Provider toma solo un valor único, como la prop value. El valor puede ser cualquier cosa. En la práctica, si se desea pasar varios valores hacia abajo, se creará un objeto con todos los valores y lo transmitirá.

Eso es prácticamente lo esencial de la API Context.

AnteriorPatrón "Slots"SiguienteIntro API Context

Última actualización hace 5 años

¿Te fue útil?