No puedes usar Hooks condicionalmente... ¿o sí puedes?

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Spanish audio is available in the player settings
Bookmark
Rate this content

Es la regla número uno de los hooks: “Solo llama a los hooks en el nivel superior”.


Pero, ¿qué pasaría si te dijera que esta regla no se aplica a todos los hooks? Uno de ellos puede ser usado condicionalmente de manera segura.


Para entender cómo useContext es diferente de otros hooks, y por qué está exento de esta regla principal, necesitamos saber por qué existe esta regla en primer lugar. Construiremos nuestro propio modelo mental del comportamiento de renderizado de react, centrado en cómo react mantiene un seguimiento de los datos en tiempo de ejecución: props, estados, refs... y valores de contexto.

This talk has been presented at React Summit 2023, check out the latest edition of this React Conference.

FAQ

El hook Use es una propuesta de React que permite desempaquetar promesas y obtener datos sincrónicos para usar directamente en los componentes, similar a Await en funciones asíncronas.

Las dos reglas principales son: 1) Solo llamar a los hooks desde funciones de React como componentes de función y otros hooks. 2) No llamar a los hooks de manera condicional para mantener el orden de ejecución y evitar errores.

useContext puede usarse de manera condicional porque lee y almacena su valor dentro de un objeto de contexto que está ubicado fuera de la lista enlazada de otros hooks, lo que lo hace independiente de la secuencia de llamadas de otros hooks.

React construye un árbol virtual llamado árbol de fibras que realiza un seguimiento de todos los componentes. La información como props y estados se mantiene en cada nodo o fibra del árbol, y React inyecta los cambios en el DOM basándose en las diferencias entre renderizados.

El orden de llamada de los hooks es crucial porque React asume un orden específico en cada renderizado. Cambiar el orden por llamadas condicionales puede llevar a errores, ya que React usa este orden para asignar y actualizar los estados internamente.

Al cambiar el valor de contexto, React recalcula el árbol de fibras afectadas y actualiza el DOM para reflejar los cambios. Los componentes que consumen el contexto se re-renderizarán con el nuevo valor, asegurando que la interfaz esté actualizada.

Charlotte Isambert
Charlotte Isambert
28 min
02 Jun, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute el uso del hook Use en React y su capacidad para ser usado condicionalmente. Explica el concepto del árbol de fibra y cómo se almacenan los valores de los hooks en la memoria. La charla también profundiza en el uso condicional de useContext y cómo difiere de useState. Explora el proceso de actualización de los valores de contexto y la optimización del renderizado de contexto. Se enfatiza el papel del proveedor en la gestión de los valores de contexto y el renderizado.

1. Introducción al Use Hook

Short description:

Hace unos meses, el equipo central de React hizo una propuesta para preguntar a la comunidad su opinión sobre la idea de agregar un nuevo hook, el Use hook. Use tendría una habilidad especial. Seríamos capaces de usarlo condicionalmente. En la propuesta, luego aprendimos que use no solo estaría obstaculizando las promesas, sino también otras cosas, como los valores de contexto.

Hola a todos, soy Charlotte, y hoy vamos a desafiar las leyes de los hooks juntos. Hace unos meses, el equipo central de React hizo una propuesta para preguntar a la community su opinión sobre la idea de agregar un nuevo hook, el Use hook. Una versión exclusiva de React de Await que desempaqueta promesas, permitiéndonos obtener datos sincrónicos data y usarlos directamente en nuestros componentes. No voy a detenerme en este hook hoy, pero hay una cosa sobre este hook que me interesa. Use tendría una habilidad especial. Seríamos capaces de usarlo condicionalmente. ¿Qué? ¿Cómo es eso posible? Solo hay dos reglas con respecto a los hooks. Regla número uno, solo llame a los hooks desde las funciones de React, por lo tanto, componentes de función y otros hooks, y regla número dos, no llame a los hooks condicionalmente. Solo dos reglas, ¿y este hook estaría exento de la mitad de ellas? Empeora. En la propuesta, luego aprendimos que use no solo estaría obstaculizando las promesas, sino también otras cosas, como los valores de contexto. Seríamos capaces de leer los valores de contexto con use, al igual que lo hacemos con use context.

2. Entendiendo el Uso Condicional de Use Context

Short description:

Para entender por qué use context puede ser utilizado condicionalmente, primero necesitaremos entender por qué otros hooks no pueden. Cuando construimos nuestra aplicación por primera vez, React crea un árbol de fibras para hacer un seguimiento de nuestros componentes. Cada componente está representado por un objeto de fibra que contiene información sobre el componente. El árbol de fibras ayuda a React a determinar qué elementos deben ser renderizados y actualizados en el DOM. Cuando instanciamos un componente de React, se añade una nueva fibra al árbol. La fibra contiene el tipo de componente, sus props y su posición en el árbol.

Así que déjame entender esto correctamente. Esto significa que seríamos capaces de leer los valores del contexto condicionalmente, y de hecho, hemos aprendido en este tweet de Andrew Clarke que ya podemos. Ya podemos llamar a use context condicionalmente. ¿Pero por qué? ¿Por qué use context puede ser utilizado condicionalmente, mientras que otros hooks no pueden? Esa es la pregunta que vamos a intentar responder hoy.

Para entender por qué use context puede ser utilizado condicionalmente, primero necesitaremos entender por qué otros hooks no pueden. Y para entender esto, necesitaremos entender cómo funcionan los hooks. ¿Dónde se almacena el data de un hook? ¿Cómo hace React para hacer un seguimiento de nuestros data a través del tiempo y del renderizado? Para entender la diferencia de use context, primero necesitaremos entender React. Así que comencemos con esta primera pregunta.

¿Dónde se almacena el data de nuestro hook? ¿Dónde se almacena el data de nuestro componente? Cuando construimos nuestra aplicación por primera vez, React va a construir este árbol virtual hecho de nuestros componentes de React. Este árbol se llama el árbol de fibras. El árbol de fibras hace un seguimiento de los componentes de React que componen nuestra aplicación. Y a partir de este árbol, React va a inyectar nuestros elementos HTML en el DOM para mostrar nuestra aplicación en la pantalla. El árbol de fibras mantiene en memoria a través del tiempo y re-renderiza información sobre nuestros componentes, sus data, sus props y sus estados. De esta manera, cuando ocurre el re-renderizado, React sabe qué elementos deberían haber cambiado, cuáles deberían ser renderizados y qué información debería ser actualizada en el DOM.

Así que la primera vez que construimos nuestra aplicación, React crea este árbol de fibras. Cada vez que instanciamos un componente de React, React añade un nodo al árbol. Y tal nodo se llama una fibra. Echemos un vistazo a uno de ellos. Echemos un vistazo a una fibra en este componente de saludos. Cuando instanciamos saludos, estamos utilizando esta sintaxis JSX, y JSX es en realidad sólo azúcar sintáctica y es equivalente a la llamada de esta función JSX, o crear elemento hasta React 17. Y esta función JSX, cuando se ejecuta, creará, añadiremos, una nueva fibra en el árbol. Así que cuando instancias un componente con esta sintaxis JSX, en realidad añades un nodo en el árbol. Creas una nueva fibra.

Ahora, ¿cómo es realmente una fibra? Bueno, una fibra es simplemente un objeto que contiene información sobre un componente. Así que si miramos esta fibra de saludos, tenemos su tipo, tenemos sus props, los data de las props, se mantienen en memoria dentro de cada fibra, junto con un montón de otros estados y banderas para que React pueda hacer un seguimiento, y finalmente, tenemos su posición dentro del árbol de fibras. Hablando del árbol de fibras, veamos cómo se construye. Veamos qué pasa en el primer renderizado cuando se construye nuestro árbol de fibras. Vamos a recorrer nuestro code, y cada vez que instanciamos un componente de React con esta sintaxis JSX, React va a añadir una fibra al árbol.

Así que primero, tenemos este componente de aplicación que tiene el nombre de usuario en este estado que pasa a este componente de saludos, que lo muestra en un párrafo, y finalmente, tenemos este botón que podemos pulsar para cambiar nuestro nombre de usuario. Y aquí vamos.

3. Entendiendo el Árbol de Fibras y los Hooks

Short description:

Hemos construido nuestro árbol de fibras e inyectado nuestros componentes en el DOM. Los valores de los hooks se almacenan en la memoria dentro de cada fibra individual como una lista enlazada. El componente de función no retiene datos; la fibra sí. Cuando se ejecuta la aplicación, los valores almacenados en la fibra se pasan a la función.

Hemos construido nuestro árbol de fibras. ¿Y ahora qué? Este árbol todavía es virtual. Aún no hemos mostrado nada en el DOM. Así que lo que React va a hacer es que va a inyectar nuestros componentes en el DOM, pero no todos ellos. Algunos de estos componentes son puras funciones de React. Este componente de saludos, por ejemplo, es un componente puro de React. No existe en el DOM. No es un elemento HTML. Así que lo que React va a hacer es que va a recorrer nuestro árbol de fibras y cada vez que encuentra un elemento HTML, lo va a inyectar en el DOM. Así que nuestro párrafo y nuestro botón. Y ahora nuestra aplicación está en vivo en la pantalla.

Así que nuestros componentes data, nuestras props, se mantienen en la memoria dentro de cada fibra. Ahora, ¿qué pasa con los hooks? Estamos aquí para hablar de hooks, ¿verdad? Así que vamos a añadir un segundo estado aquí. ¿Dónde se almacenan estos dos valores? Bueno, lo has adivinado. Los valores de los hooks se mantienen en la memoria dentro de cada fibra individual también, pero no de cualquier manera. Los valores de los hooks se almacenan dentro de una lista enlazada, donde cada valor apunta hacia el siguiente. Estos valores son luego leídos por los hooks en el orden en que son llamados. Una cosa que tienes que entender aquí es que este componente de función, app, es solo una función. No retiene data. UseState no retiene data. La fibra sí. Cuando ejecutas la aplicación, ejecutas esta función y le pasas los valores que se almacenaron en la memoria dentro de la fibra. Así que vamos a ejecutar la aplicación por primera vez. Construyamos nuestra fibra. Ejecutamos la aplicación. Vamos a estar escribiendo esto. Este useState estará escribiendo ese valor predeterminado en la fibra en el orden en que son llamados. Así que primero, tendremos nombre, que va a estar escribiendo en el primer elemento de la lista enlazada ya que está vacía hasta ahora, Rachel. Luego tenemos edad, que va a estar escribiendo en el elemento actual de la lista enlazada, .next. Así que el segundo, 29.

4. Entendiendo Hooks y Uso Condicional

Short description:

¿Qué sucede después del renderizado? ¿Puedes ver en este esquema por qué no puedes llamar a los Hooks de manera condicional? Intentemos llamar a este estado de nombre de manera condicional basándonos en este primer valor booleano. Tenemos este error que probablemente ya has encontrado en tu vida como desarrollador de React. Los Hooks dependen del orden en que se llaman. Todos ellos son interdependientes en sus listas enlazadas. Por eso no puedes usarlos de manera condicional.

¿Qué sucede después del renderizado? ¿Qué sucede si hacemos clic en este botón aquí y cambiamos nuestro primer estado, nuestro nombre de usuario? Vamos a renderizar. Vamos a ejecutar la aplicación y pasarle los valores que se guardaron en la memoria dentro de la fibra. Así que primero, el nombre va a leer el primer elemento de la lista enlazada y la edad el segundo. ¿Puedes ver en este esquema por qué no puedes llamar a los Hooks de manera condicional? Los Hooks dependen del orden en que se llaman. Así que si en el próximo renderizado añades o quitas un hook, cambias el orden y los data que obtienes no son los correctos.

Intentémoslo. Intentemos llamar a este estado de nombre de manera condicional basándonos en este primer valor booleano que es originalmente igual a falso. Rendericemos la aplicación por primera vez. Así que primero tenemos shuname que va a escribir falso en el primer elemento de la lista enlazada. Y no pasamos esta condición, así que pasamos a la edad que va a escribir 29. ¿Qué sucede si hacemos clic en este botón aquí y cambiamos nuestro primer booleano a verdadero? Renderizaremos la aplicación y le pasaremos estos dos valores. Así que primero, shuname va a leer verdadero en el primer elemento de la lista enlazada. Luego, esta vez pasamos esta condición, así que tenemos nombre que va a leer 29. Así que sí, el nombre va a ser 29 y luego tenemos edad que no puede encontrar su valor en ninguna parte y nos saca. Tenemos este error que probablemente ya has encontrado en tu vida como desarrollador de React. Los Hooks dependen del orden en que se llaman. Todos ellos son interdependientes en sus listas enlazadas. Por eso no puedes usarlos de manera condicional.

5. Entendiendo el Uso de useContext

Short description:

¿Y qué pasa con useContext entonces? ¿Por qué useContext puede usarse condicionalmente? Vamos a retorcer un poco nuestro ejemplo y usar proporciona nuestro nombre de usuario en este valor de contexto. La respuesta se encuentra en nuestro árbol de fibra. Así que vamos a construirlo. Primero tenemos estos objetos de contexto, luego tenemos la aplicación que todavía tiene el nombre de usuario en este estado que pasa esta vez en props a este proveedor de contexto. Debajo del proveedor tenemos saludos que ahora es un consumidor de contexto. Lee el valor del contexto del valor del nombre de usuario del contexto y lo pasa a este párrafo. Y finalmente, terminamos con este botón en el que podemos hacer clic para cambiar nuestro valor de contexto.

¿Y qué pasa con useContext entonces? ¿Por qué useContext puede usarse condicionalmente? Vamos a retorcer un poco nuestro ejemplo y usar proporciona nuestro nombre de usuario en este valor de contexto. La respuesta se encuentra en nuestro árbol de fibra. Así que vamos a construirlo. Primero tenemos estos objetos de contexto, luego tenemos la aplicación que todavía tiene el nombre de usuario en este estado que pasa esta vez en props a este proveedor de contexto. Debajo del proveedor tenemos saludos que ahora es un consumidor de contexto. Lee el valor del contexto del valor del nombre de usuario del contexto y lo pasa a este párrafo. Y finalmente, terminamos con este botón en el que podemos hacer clic para cambiar nuestro valor de contexto.

6. Entendiendo el Uso Condicional de useContext

Short description:

¿Puedes ver en este esquema por qué useContext puede usarse condicionalmente? useContext lee y almacena su valor dentro de un objeto de contexto ubicado fuera del árbol, sin relación con otros hooks. Al llamar a useContext, el objeto de contexto se pasa como argumento, permitiendo el acceso directo al valor. useState, por otro lado, depende del orden para determinar su valor, ya que no hay identificadores para diferenciar múltiples instancias. Esta distinción permite el uso condicional de useContext.

¿Puedes ver en este esquema por qué useContext puede usarse condicionalmente? Vamos a agregar un segundo estado aquí. Los valores de los Hooks como useState o useEffect leen y almacenan su valor dentro de la lista enlazada donde todos los Hooks son interdependientes y donde otros importan. useContext, por otro lado, lee y almacena su valor dentro de un objeto de contexto que está ubicado fuera del árbol, fuera de la lista enlazada. useContext no está relacionado con otros hooks de la manera en que lo está useState. Así que puedes llamarlo condicionalmente todo lo que quieras. Simplemente no afectará a otros hooks.

Y eso es algo que también puedes ver en el code. Echa un vistazo más de cerca al code. Verás que cuando llamas a useContext, le estás pasando en argumentos, el objeto de contexto. Le estás diciendo, ve a verificar tu valor justo aquí en este mismo objeto. Está codificado. useState, por otro lado, no recibe ninguna variable clave codificada para encontrar su valor. Todo lo que recibe es la lista de valores de todos los hooks de la fibra. Y este useState es igual que este otro. No hay un identificador para diferenciarlos. Entonces, ¿cómo sabe cuál de estos valores le pertenece? Depende del orden. Esa es la implementación que se decidió. Por eso es por lo que useContext puede usarse condicionalmente. Por eso es por lo que useContext es diferente.

7. Entendiendo la Actualización de los Valores de Contexto

Short description:

Para entender cómo se actualiza un valor de contexto, necesitamos entender cómo se actualiza cualquier valor regular. Cuando cambiamos el valor de contexto, React calcula una nueva versión del árbol de fibra que corresponde al cambio. Compara este nuevo árbol con el anterior y aplica las diferencias al DOM. Sin embargo, sólo se renderizan los componentes que pueden haber cambiado, no todos los componentes. Este proceso de cálculo implica duplicar el árbol de fibra, actualizarlo para reflejar el cambio, marcar la fibra que contiene el estado cambiado, y recorrer el árbol para decidir qué componentes renderizar.

Pero parece que todavía falta algo. ¿Cómo funciona esto exactamente, verdad? El valor del contexto se encuentra dentro de este objeto. Pero si este objeto se encuentra fuera del árbol, ¿cómo se actualiza? ¿Y cuál es realmente el papel de este proveedor aquí? Para que nuestra demostración sea completa, me gustaría profundizar un poco más si les parece bien, y realmente entender cómo se actualiza un valor de contexto, cómo funciona un valor de contexto por debajo.

Bueno, chicos, los próximos minutos van a ser bastante intensos. Para entender cómo se actualiza un valor de contexto, primero necesitaremos entender cómo se actualiza cualquier valor regular. Así que vamos a tener un poco de teoría aquí sobre el comportamiento de renderizado de React. Así que tengan paciencia conmigo. Bien, ¿cómo se actualiza un valor de contexto? Hagamos clic en nuestro botón aquí y cambiemos nuestro valor de contexto. Veamos qué pasa. Vamos a volver a renderizar. Activamos un set state. Lo que va a pasar es que vamos a calcular una nueva versión de nuestro árbol de fibra que corresponde al cambio que hemos hecho a nuestro nuevo estado, nuestro nuevo renderizado. Una vez que se ha hecho, React va a comparar este nuevo árbol con el del orden anterior y aplicará las diferencias al DOM. Pero cuando calculamos este nuevo árbol de fibra, no renderizamos realmente todos los componentes de nuestra aplicación que podrían ser ineficientes, sólo los que pueden haber cambiado. Veamos cómo va este proceso de cálculo paso a paso.

Así que hacemos clic en este botón aquí para cambiar nuestro valor de contexto. Vamos a cambiar para activar un set state. Vamos a renderizar. En este punto, suceden varias cosas. Primero, como dijimos, vamos a duplicar nuestro árbol de fibra. Vamos a actualizar este nuevo árbol de fibra para que corresponda al cambio que hemos hecho. Pero hasta ahora, es lo mismo. Es sólo una copia. Segunda cosa, vamos a marcar la fibra que contiene el estado que acaba de cambiar como necesitada de renderizar. Así que a este componente de aplicación, esta fibra de aplicación, vamos a añadirle esta pequeña bandera de renderizado. Y finalmente, vamos a recorrer nuestro árbol. Vamos a visitar cada fibra. Y para cada una de ellas, nos vamos a preguntar, ¿deberíamos renderizar estos componentes? Si lo hacemos, renderizaremos. De lo contrario, nos retiramos. Esperamos, nos vamos.

8. Renderizando el Componente App

Short description:

Comenzamos en la parte superior de nuestro árbol con la primera fibra de la aplicación. La aplicación está marcada para un nuevo renderizado, así que la volvemos a renderizar.

No renderizamos. Y comenzamos en la parte superior de nuestro árbol con la primera fibra de la aplicación. Así que vamos a usar esta pequeña bandera de trabajo en progreso solo para tener en cuenta qué fibra estamos visitando actualmente. Así que la aplicación. ¿Deberíamos renderizar la aplicación? Hay dos criterios para que un componente sea renderizado. Y si cumple con alguno de ellos, renderizamos este componente. El primero es estar marcado para un nuevo renderizado. Y la aplicación fue marcada para un nuevo renderizado. Así que está bien. Volvemos a renderizar la aplicación. Añadamos algo de color en este esquema. Pongamos en azul las fibras que fueron renderizadas de nuevo solo para tenerlo en cuenta. Así que hemos vuelto a renderizar la aplicación.

9. Ejecución de Componentes de Función

Short description:

Ejecutar componentes de función significa ejecutar la aplicación y pasar los valores almacenados en la fibra. Al renderizar la aplicación, se crean nuevas fibras para todos los componentes instanciados con la sintaxis JSX.

¿Qué significa esto? Significa ejecutar sus componentes de función. Así que ejecutamos la aplicación y le pasamos los valores que se guardaron en la memoria dentro de la fibra. Así que en primer lugar, vamos a leer el último valor de nombre de usuario que acaba de cambiar. Y luego vamos a través de todo este JSX. Y aquí mira. Mira este componente de saludos, estamos utilizando la sintaxis JSX aquí. Y recuerda que JSX es equivalente a la llamada de esta función JSX que crea fibras. Así que lo que esto significa es que en nuestro nuevo árbol para estos componentes de saludos, vamos a descartar completamente la fibra anterior y añadir una completamente nueva. Este es un nuevo objeto. Y algo, sí, pongámoslo en naranja. Las nuevas fibras están en naranja sólo para tenerlo en cuenta. Algo que debes notar aquí y que será útil más tarde es que mientras estamos creando una nueva fibra para los saludos, también estamos creando un nuevo objeto de props. Este es un objeto completamente nuevo. Será útil más tarde. Así que mientras estamos renderizando la aplicación, vamos a crear nuevas fibras para todos los componentes que instancie con esta sintaxis JSX.

10. Renderizando el Proveedor de Contexto

Short description:

Renderizamos el proveedor, que es un proveedor de contexto y actualiza el valor del objeto de contexto basado en sus props.

Entonces, nuestro proveedor también, al que le estamos pasando el último valor de nombre de usuario en props y nuestro y hemos terminado con la aplicación. Así que podemos pasar a la siguiente fibra, nuestro proveedor de contexto. ¿Deberíamos renderizar el proveedor? Bueno, no fue marcado para renderizar pero hay un segundo criterio para ser renderizado y es basado en el valor de las props. Vamos a comparar estos objetos de props, el objeto de props de la fibra del nuevo árbol con el del árbol anterior. Vamos a comparar estos dos objetos a través de la igualdad superficial y si son iguales, no renderizamos, de lo contrario sí. Y en nuestro caso, son diferentes. Así que renderizamos el proveedor. Así que ejecutamos este componente de función pero eso no es todo. Verás, este componente es algo especial. No es solo un componente de función regular. Es un proveedor de contexto. Entonces, hace otras cosas también, como actualizar el valor del objeto de contexto, basado en el valor que obtuvo de sus props. Así que el proveedor actualiza el valor del objeto de contexto y hemos terminado con el proveedor. Así que podemos pasar a la siguiente fibra.

11. Renderizando Componentes y el Árbol de Fibra

Short description:

Cuando creamos una nueva fibra para saludos, creamos un nuevo objeto para sus props. Aunque los objetos pueden parecer similares, tienen diferentes referencias. La igualdad superficial de JavaScript considera que los objetos vacíos no son iguales. Por lo tanto, renderizamos saludos. Luego ejecutamos los componentes de función, leemos el último valor de nombre de usuario del objeto de contexto y creamos una nueva fibra para el párrafo. El párrafo y el botón también se renderizan. React compara el nuevo árbol con el anterior y aplica las diferencias al DOM. Es importante destacar que en realidad solo hay un árbol en la realidad, pero es más fácil pensar en él como dos árboles. El árbol de fibra, no el código, es la fuente de verdad para saber qué componentes pueden haber cambiado y deben renderizarse.

Saludos, ¿deberíamos renderizar saludos? Bueno, no fue como para renderizar pero, ¿han cambiado sus props? Bueno, en realidad sí, lo han hecho. Lo sé, dos objetos vacíos, parecen muy similares pero este es un objeto diferente. Así que cuando creamos una nueva fibra para saludos, también creamos un nuevo objeto para estas props también. Tiene la misma, no, diferente referencia, si quieres. Y en JavaScript, a través de la igualdad superficial, recuerda que objeto vacío igual a objeto vacío es falso a través de la igualdad superficial. Así que en nuestro caso, estos dos objetos son diferentes y sí renderizamos saludos.

Así que ejecutamos estos componentes de función. Leemos el último valor de nombre de usuario del objeto de contexto y creamos una nueva fibra para el párrafo al que pasamos el nuevo valor de nombre de usuario. Y hemos terminado con saludos. Así que pasamos al párrafo, que se renderiza, porque sus props han cambiado, igual que los saludos. Y pasamos al botón, que también se renderiza. Y hemos terminado de construir nuestro árbol. Ahora, React va a comparar este nuevo árbol con el del orden anterior y aplicar las diferencias al DOM. Y ahora hemos terminado. Esto fue algo mecánico. Así que vamos a dar un paso atrás de esto. Hay una o dos cosas que me gustaría discutir juntos. Primero sobre React y luego hablaremos sobre el contexto.

Sobre React, una pequeña advertencia. No es del todo cierto que tengamos estos dos árboles. En realidad, solo hay uno. Y cada fibra se aferra a toda su historia de estados. Pero simplemente me resulta más fácil pensar en él como dos árboles. Y quiero decir, es mi modelo mental. Así que si quiero tener dos árboles, tendré dos árboles. Segunda cosa aún sobre React. Hay un malentendido que tenía sobre React que quería compartir con ustedes. Solía pensar que la fuente de verdad, para saber qué componentes pueden haber cambiado y cuál debería ser renderizado era el code. Pero no lo es. El árbol de fibra lo es.

12. Entendiendo la Representación y el Uso del Contexto

Short description:

Cuando renderizamos la aplicación, se crea una nueva fibra para saludos, y se recorre todo el árbol. React renderiza saludos cuando detecta que sus props han cambiado. En el uso real, los primeros componentes debajo del proveedor rara vez son consumidores de contexto. Se pueden agregar componentes adicionales entre el proveedor y el primer consumidor de contexto. Cuando se cambia el valor del contexto, todos los componentes en la cascada se representan.

Solía pensar que cuando renderizábamos la aplicación, el hecho de que estemos llamando a este componente de saludos de esta manera significaba que lo estaríamos ejecutando de inmediato. Pero eso no es lo que está sucediendo. Lo que está sucediendo es que cuando renderizamos la aplicación, cuando ejecutamos esta línea, creamos una nueva fibra para saludos. Y luego estamos recorriendo todo el árbol. Y más tarde, cuando estamos visitando saludos, React está diciendo, oh, sus props han cambiado. Deberíamos renderizar eso. Y solo entonces ejecutamos estas líneas. La fuente de verdad es el árbol de fibra.

Ahora en tu vida diaria, sé que no estarás dibujando árboles de fibra. Así que lo que puedes recordar, lo que puedes llevar de esto es que cuando estás debajo, cuando el componente se renderiza, todas las instancias de los componentes también se renderizarán. Ahora sobre los contextos. Así es como funcionan los contextos. Cambiamos el valor del estado que se refiere a los estados establecidos. El proveedor se renderiza. Actualiza el valor del contexto, lo siento, problemas de animation. Actualiza el último contexto, los valores del contexto, el valor del contexto del objeto de contexto. Y luego todos estos componentes se van a renderizar en cascada y este componente de gradiente va a leer el último valor de contexto del objeto de contexto. Pero en realidad aún no hemos terminado. Esto no representa realmente un uso real del contexto. En la vida real, los primeros componentes ubicados justo debajo del proveedor casi nunca son un consumidor de contexto.

En la vida real, se parece más a esto. Agregamos algunos componentes extra entre el proveedor y el primer consumidor de contexto. Ahora en este caso, si echamos un vistazo a estos componentes A y B, ¿crees que ellos también se renderizarán si cambiamos nuestro valor de contexto si hacemos clic en este botón? Bueno, en realidad sí. Si hacemos clic en este botón aquí, vamos a renderizar la aplicación. Entonces la aplicación, cuando se ejecuta, creará una nueva fibra para A. Así que A se renderizará. Entonces creará una nueva fibra para B. Así que B se renderizará y así sucesivamente. Todos estos componentes se renderizan en cascada. Pero quiero decir que eso es demasiado malo.

13. Optimizando la Representación del Contexto

Short description:

Queremos evitar la representación de componentes que no dependen del contexto cuando el valor del contexto cambia. Una forma de lograr esto es memorizando el primer componente debajo del proveedor. Otra forma es extraer el proveedor en su propio componente personalizado y pasar el resto del árbol como prop de los hijos. Al hacer esto, cuando el valor del contexto cambia y se representa el proveedor, los componentes pasados como hijos no se volverán a representar. Vamos a demostrar esto cambiando el valor del contexto y observando el proceso de representación. Duplicamos el árbol de fibra, marcamos el componente que contiene el estado, y recorremos el árbol. No volvemos a representar la aplicación porque sus props no han cambiado. Esta optimización nos permite evitar representaciones innecesarias y mejorar el rendimiento.

Hemos representado porque cambiamos el valor del contexto pero A y B no dependen del contexto. No han cambiado. No deberíamos representarlos. Eso es demasiado malo. Y quiero decir que cuando llamas a useContext, estás tratando de llamarlo lo más bajo posible en tu árbol, lo más cerca posible de donde realmente lo necesitas. Así que si podemos, sería bastante bueno evitar la representación de todos los componentes ubicados entre el proveedor y el consumidor de contexto.

¿Entonces cómo podemos lograr esto? ¿Cómo podemos no volver a representar A y B si cambiamos nuestro valor de contexto? Bueno, una cosa que ya había escuchado antes es memorizar el primer componente ubicado justo debajo del proveedor. De esta manera, memorizamos este componente. De esta manera, detenemos la propagación de la representación. Esto debería funcionar pero en realidad, hay otra forma de lograr esto, que está incluso más cerca de un uso real del contexto. ¿Puedes adivinar cuál es? Es extraer tu proveedor en su propio componente personalizado y pasar el resto de el árbol como prop de los hijos. De esta manera, cuando cambiamos nuestro valor de contexto y se representa el proveedor de autenticación, cuando se representa el proveedor de autenticación, este componente A que se pasa como prop de los hijos no se representará y detendremos la propagación de la representación.

Vamos a hacer la demostración muy rápido. Vamos a hacer clic en este botón aquí y cambiar nuestro valor de contexto. Duplicamos nuestro árbol de fibra, vamos a marcar el componente que contiene el estado como necesitado para representar. Así que esta vez no es la aplicación, son estos componentes personalizados del proveedor de autenticación. Así que marcamos el proveedor de autenticación y comenzamos a recorrer nuestro árbol. Comenzamos con la aplicación, ¿deberíamos representar la aplicación? Bueno, no fue marcada para representar pero ¿han cambiado sus props? Bueno, en realidad no. Esta vez, este objeto de props es el mismo que este. Cuando duplicamos nuestro árbol, este árbol es la copia superficial de este. Es una copia directa de este, así que este objeto de props es una copia directa de este. Mantienen la misma referencia si se puede. En JavaScript, esta vez a través de la igualdad superficial, estos dos objetos son iguales. Así que no volvemos a representar la aplicación. ¿Te diste cuenta? Es el primer componente en los últimos 10 minutos que en realidad no representamos. Se siente genial. Muy bien. Pasemos al proveedor. Se representa ya que fue marcado, así que lo ejecutamos. Obtenemos el último valor de nombre de usuario y creamos nuevas fibras para el proveedor y el botón.

14. Entendiendo el Papel del Proveedor

Short description:

Pero aquí, children es solo una prop, es solo una variable. El proveedor se encargará de asegurar que los consumidores de contexto se rendericen. AuthProvider, nuestro proveedor de contexto, marcará las lecturas como necesarias para renderizar. Extraer el proveedor en sus propios componentes personalizados no solo conduce a una mejor separación de responsabilidades, sino que también asegura que todos los componentes ubicados entre el proveedor y el primer consumidor de contexto no se rendericen. El papel del proveedor es absolutamente crucial. Va a actualizar tanto el valor del objeto de contexto dentro de los objetos de contexto como asegurar que los consumidores se rendericen.

Pero, ¿qué pasa con esta prop children? ¿Qué pasa con este componente A que se pasó como prop children? ¿Deberíamos crear una nueva fibra para ello? Bueno, en realidad, no. La razón por la que estamos creando una nueva fibra para un botón es debido a esta sintaxis JSX que es equivalente a la función JSX que crea fibras. Pero aquí, children es solo una prop, es solo una variable. No hay JSX aquí, por lo que no hay razón para crear una nueva fibra para A. Así que no hay nueva fibra de A y hemos terminado con el proveedor. Podemos pasar al proveedor de contexto real, que se renderiza ya que sus props han cambiado. Actualiza el valor del contexto y pasamos a A, que tampoco se vuelve a renderizar. Ves que, al igual que para la aplicación, este objeto de props es el mismo que este, por lo que no renderizamos A, ni B, ni los saludos. Pero ahora tenemos un problema.

Saludos es un consumidor de contexto. Queremos que se renderice para leer el último valor de nombre de usuario, de lo contrario nuestra aplicación no tiene sentido. Queremos que los saludos se rendericen y en realidad lo harán. El proveedor se encargará de ello. Hay algo que no te conté. Volvamos a cuando estamos visitando al proveedor. Dijimos que cuando el proveedor se renderizaba, actualizaría el valor del objeto de contexto, pero eso no es todo lo que hace. También se va a asegurar de que los consumidores de contexto se rendericen. Va a recorrer todas las fibras que están ubicadas debajo de él y marcará a los consumidores de contexto como necesarios para renderizar. Tiene esta información dentro de las fibras porque cuando un componente se renderiza, si utiliza un contexto, useContext va a escribir esta dependencia hacia el contexto dentro de la fibra. Así que AuthProvider, nuestro proveedor de contexto, va a marcar las lecturas como necesarias para renderizar. De esta manera, incluso si un componente se memoriza en el medio y la propagación de renderizado se detiene, asegura que los consumidores se rendericen. Y puedes ver que no mentí. Este componente A no se renderizó cuando se renderizó AuthProvider porque se pasó como esta prop children. Entonces, en realidad, extraer el proveedor en sus propios componentes personalizados no solo conduce a una mejor separación de responsabilidades. También asegura que todos los componentes ubicados entre el proveedor y el primer consumidor de contexto no se rendericen.

Y esto es en realidad, oh sí, lo siento, una última cosa. Una vez que se renderiza el primer consumidor de contexto, por supuesto, si agregas algunos componentes extra debajo de él, todos ellos también se van a renderizar. Y así es como funciona el contexto. Y puedes ver que el papel del proveedor es absolutamente crucial. Va a actualizar tanto el valor del objeto de contexto dentro de los objetos de contexto y asegurar que los consumidores se rendericen para que puedan leer el último valor de contexto de los objetos de contexto.

15. Uso Condicional de useContext en Hooks

Short description:

Con esta imagen completa de cómo funciona el contexto, podemos confirmar que useContext puede usarse condicionalmente sin interferir con otros hooks. Sin embargo, se aconseja no llamar a useContext condicionalmente para evitar confusiones, especialmente para los desarrolladores inexpertos. Puede haber otros hooks además de useContext, como el hook de uso con Octobot, que también se pueden usar condicionalmente. ¡Gracias!

Con esta imagen completa de cómo funciona el contexto, podemos confirmar que, efectivamente, useContext puede usarse condicionalmente. No interfiere con otros hooks. Por eso es que useContext puede usarse condicionalmente. Y eso es todo lo que quería contarles sobre useContext, estos Curiosos Hooks.

¿Tengo un último minuto para hacer una advertencia? Tienes un último minuto para hacer una rápida advertencia, adelante. Gracias. Solo quería decir que no lo hagan. No llamen a useContext condicionalmente. Es mejor para los desarrolladores jóvenes mantenerlo de la misma manera que los demás para asegurarse de que no se pierdan.

Y también, una rápida pregunta. ¿Crees que puede haber otros hooks? ¿Es useContext el único? ¿Recuerdas, el hook de uso con Octobot? Dijimos que podríamos usarlo condicionalmente. ¿Por qué es eso? Y sí. Muchas gracias. Aquí hay algunos recursos si quieres seguir profundizando y seguir construyendo tu propio modelo mental del comportamiento de renderizado de amenazas. Eso fue increíble. Dame algo.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.