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

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.

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.

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.

¿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.

¿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.

¿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.

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.

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.

¿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.

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.

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.

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.

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.

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.

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.