Consejos sobre React Hooks que solo los profesionales conocen

Entonces, bienvenidos a todos a esta masterclass sobre React Hooks Tips que solo los profesionales conocen. Esta es una masterclass interactiva, por lo que se espera que enciendas Visual Studio Code o cualquier editor que uses y escribas code. Compartiré el repositorio. De hecho, ya compartí el repositorio en la ventana de chat en Discord y en Zoom también. Pero, Discord es la ventana de chat principal, así que asegúrate de mantenerla abierta.

Entonces, ¿quién soy yo? Mi nombre es Boris De Beier, también conocido como The Problem Solver. Soy un desarrollador MVP de Microsoft, instructor, líder de equipo, hago todo tipo de cosas así. Mucho desarrollo de front-end con React. Eso es más o menos lo principal que hago. Mi nombre en Twitter, en borisdb. Si quieres seguirme, enviarme mensajes más tarde, o mi dirección de correo electrónico, en caso de que quieras hacer algo de eso. Así que, entre las muchas cosas que hago, también publico un boletín de noticias de React que se envía todos los miércoles. Así que, ayer, hubo otro. Siéntete libre de suscribirte. Solo haz clic en la imagen, o en el código QR, o escanea el código QR con tu teléfono. Si te registras, recibirás un correo electrónico a la semana con seis artículos de React y un video. ¿No te gusta? Puedes simplemente darte de baja. No voy a usar tu dirección de correo electrónico para nada más. No voy a venderla a dios sabe quién. No tiene sentido hacer eso con todas las fugas de data. Realmente no puedo competir con esas, aunque quisiera, y no quiero.

Entonces, ¿cuáles son los objetivos de esta masterclass? Bueno, vamos a echar un vistazo a los hooks. Vamos a saltarnos lo básico. Esta es una masterclass avanzada. Así que espero que todos estén familiarizados con React, familiarizados con los conceptos básicos de los hooks. Y vamos a ir más allá de eso. Vamos a ver cómo puedes equivocarte, porque incluso con los hooks simples, son bastante simples, pero aún puedes usarlos de la manera incorrecta y obtener un error o algún resultado no deseado o tal vez una degradación del rendimiento o algo así. Y luego vamos a ir más allá de los hooks básicos. ¿Cómo puedes usar los hooks más avanzados? ¿Cuándo querrías hacerlo? Y cuáles hay, por supuesto. No vamos a ver todos ellos, hay un par de casos bastante marginales, como el valor de uso debug. No vamos a usar eso, pero veremos la mayoría de ellos. Crearemos algunos hooks personalizados. Veremos las reglas de los hooks, por qué necesitas seguirlas, qué puede pasar si no lo haces, y cómo están realmente construidas. Parte de eso es que echaremos un vistazo detrás de las escenas a cómo funcionan las reglas de ESLint y cómo React realmente funciona bajo el capó con los hooks. Y luego, en la segunda parte de la masterclass, vamos a hacer un ejemplo más complejo. La primera parte son ejemplos bastante simples donde nos centramos en un hook a la vez. En la segunda parte, vamos a crear un poco de una biblioteca de UI o una biblioteca de formularios, tal vez estés familiarizado con formic, que es una biblioteca realmente agradable si quieres hacer formularios sobre data en React. Bueno, vamos a crear un clon simple, bastante, muy simplificado de eso. Ver cómo los hooks y el contexto y un par de diferentes características de React trabajarán juntos para crear una solución muy elegante para hacer algo así. Te proporcionaré todo el code que necesitas en el repositorio de Git, así que si quieres, puedes copiar todo. Pero te recomendaría que escribas tanto como puedas. Como hay algunos fragmentos más grandes donde también voy a copiarlo, porque no tiene sentido verme escribir 25 líneas de code con un montón de errores de tipeo. Pero en su mayoría, te recomendaría que lo escribas porque cometerás errores. Yo cometo errores. Todos lo hacen. Y los cometerás en la vida real también cuando no sea una masterclass. Y si los has cometido ahora, has visto qué sale mal. Puedes obtener ayuda. Entonces los reconocerás cuando ocurran en algún otro escenario. Así que ayudar a cometer errores es una excelente manera de descubrir cosas. Los requisitos previos para el code necesitarás Node y NPM y el repositorio de GitHub. Con Node y NPM, prácticamente espero que todos estén bien allí. Dado que este es un curso avanzado, y espero que todos estén familiarizados con React. Tengo Node 12.18, en realidad tengo una versión más nueva de NPM. ¿Qué es? Tengo NPM 7.11 aquí. En realidad tengo Node 14.15, a diferencia de lo que dice en mi diapositiva. Supongo que es un poco antiguo, un poco anticuado, pero una versión relativamente nueva de Node debería funcionar y una versión relativamente nueva de NPM, no necesita ser exactamente esta versión. Lo otro que necesitarás es el repositorio de GitHub. Ahora he pegado enlaces a él, tanto en Discord como en la ventana de chat de Zoom. Así que puedes llegar allí. También deberías haber recibido un correo electrónico con enlaces a él. Así que hay muchas formas de conseguirlo. Si tienes una copia de las diapositivas, que te recomiendo encarecidamente que tengas a mano porque hay muchos enlaces allí. Puedes hacer clic en el código QR aquí o en la imagen y te llevará directamente al repositorio, excepto que lo hace en mi otra pantalla. Así que aquí está. Básicamente, todo el código que vamos a escribir está aquí, hay un montón de ramas aquí. Cuando clones esto, simplemente déjalo en la rama principal para hacer la instalación de npm. Y después cambia a la rama de inicio cero cero. Esa es la que vamos a empezar, que no tiene todo el code que vamos a escribir. La rama principal está completa. Todas las demás ramas aquí están al final de un paso. Así que cero uno hook personalizado es después de que hemos hecho un hook personalizado, cero dos efectos de diseño es lo mismo, etc. Así que puedes ver que tenemos 14 pasos diferentes para pasar. ¿Eso es todo? Creo que sí. Todas las ramas aquí. Sí, 14 de ellas. Así que asegúrate de clonar eso y ejecutar NPM install en eso. Y eso no debería llevar mucho tiempo, pero obtendrás un montón de paquetes. Esto no se hace con create react app. Así que en realidad es un poco más pequeño que eso. Un poco de un experimento, pero estoy usando vita dos, o pies. Debería decir en realidad que así es como se pronuncia para construir y ejecutar la aplicación en modo de desarrollo. Tal vez has oído hablar de ello, tal vez no. Es una forma ligera de alojar aplicaciones o lo siento, desarrollar aplicaciones donde el servidor de desarrollo se inicia muy rápido. Utiliza módulos de ECMAScript para servir todo. Así que el code se compilará según sea necesario, pero no es como si todo tuviera que ser empaquetado con cada cambio. Así que los pasos de finalización son realmente pequeños y solo se compila según sea necesario, lo cual funciona realmente bien. No he usado esto en proyectos grandes todavía donde en realidad brilla aún más porque entonces el tiempo de inicio con create React se vuelve un poco lento. Pero los proyectos más pequeños en los que he usado esto, estaba realmente contento con ello. Así que lo usé para esta masterclass y funciona muy bien.

Y también lo recomendaría para otras cosas. Otra cosa que notarás con el code, todo el code está en TypeScript. Ahora, no todos son fanáticos de TypeScript, yo sí. No voy a disculparme por eso. Me gusta mucho TypeScript. Creo que es, bueno, una gran ventaja cuando estás haciendo aplicaciones serias. Con una pequeña aplicación de demostración o prueba de concepto, probablemente también usaría JavaScript solo para hacer las cosas rápidamente. Pero cualquier trabajo serio lo hago en TypeScript. Ahora, esta masterclass no es una aplicación seria, pero está destinada a ser realista aunque sea bastante pequeña. Así que decidí usar TypeScript. Ahora, si no estás acostumbrado a TypeScript, hay un archivo. Permíteme abrir primero Visual Studio Code, y mostrarte ¿dónde está? TS config aquí abajo. Esto controla cómo funciona TypeScript. Hay esta configuración aquí, strict es true. Eso significa que TypeScript hará muchas comprobaciones. Si realmente no quieres o tienes experiencia con TypeScript, puedes poner esto en false y entonces te molestará mucho menos. También está la palabra clave any. Puedes escribir cosas como any y deshacerte de muchas advertencias de compilación de esa manera también. Pero te recomendaría encarecidamente que te quedes con TypeScript y lo uses incluso en proyectos serios porque funciona muy bien. Otro par de enlaces al repositorio y estas diapositivas. Ese no es el punto de esta diapositiva. El punto es que verás muchas imágenes como esta donde tengo fragmentos de code, use person, function en este caso. Y si pasas el ratón por encima, notarás que en realidad es un enlace que se abre en mi otro monitor de nuevo. Entonces, el punto de este enlace y el code que aparece, es una diferencia de lo que estamos haciendo realmente en este paso. Entonces, en este paso, podemos ver que agregué a use ref aquí y cambié algo, etc., exactamente lo que eliminé, como eliminar algo de code aquí, cosas así. Útil si quieres hacer algo y no estás muy seguro de cuáles son los cambios. Hay algunos resaltados sutiles aquí donde puedes ver dónde se cambió el code, lo cual también ayudará, pero puedes abrir el code. Y por supuesto, si es un cambio más grande, siempre puedes entrar aquí y simplemente copiar cosas de aquí, lo cual haré ocasionalmente. También verás a este caballero. Jean-Luc Picard, el capitán del Enterprise. Y básicamente cada vez que lo veas aparecer, es una señal de que es tu turno de hacer algo. Entonces, básicamente, te voy a mostrar lo que vamos a hacer. Yo lo voy a hacer. Y luego, después de eso, es tu turno de hacer lo mismo. Por supuesto, te explicaré cómo y todo, cómo se supone que todo debe funcionar, etc. Pero durante esas partes interactivas donde estás codificando, voy a abrir las salas de Zoom. Voy a dividir, bueno, actualmente somos 23 personas. Así que voy a dividir eso en algo como siete, tal vez ocho salas, dependiendo del número real entonces. Así que habrá algo como tres a cuatro personas en una sala dada. Desafortunadamente, a veces en Zoom, las personas son expulsadas de una sala. En ese caso, te agregaré de nuevo. Pero normalmente no sé exactamente en qué sala estabas originalmente porque se crean al azar. Lo siento si saltas de una sala a otra como resultado de eso. No hay mucho que pueda hacer al respecto. Esa es la parte de la introducción.

Así que vamos a los verdaderos Hooks de React. Y comenzaremos con lo básico. Ahora, estos son los tres hooks básicos que se añadieron a React. Hay un montón más que veremos, pero estos eran los básicos. Y en realidad no voy a explicar mucho sobre ellos. Los voy a usar. Voy a explicar un poco sobre ellos, pero se supone que todos están familiarizados con eso. Y los tres Hooks básicos de React con los que supongo que todos están familiarizados son ustate o cómo hago la gestión del estado, gestionar algún estado en el ciclo de vida de un Componente de React. Use effects, cómo hago efectos secundarios a lo largo del ciclo de vida de un Componente de React y use context o cómo obtengo un valor proporcionado, valor de contexto, que se proporciona en algún lugar más arriba en la cadena de componentes.

Y, por supuesto, estoy asumiendo que todos ustedes están familiarizados con que React tiene tanto componentes funcionales como componentes basados en clases, pero los hooks solo se pueden utilizar en componentes funcionales, no en componentes basados en clases. Pero hemos tenido hooks durante un par de años. Y, para ser honesto, desde que se lanzaron los hooks, realmente no he escrito muchos componentes basados en clases y la mayoría de las personas en estos días solo están escribiendo componentes funcionales. En casi todos los escenarios, los encuentro más fáciles de trabajar que los componentes basados en clases. Así que hay pocas razones para escribir componentes basados en clases.

De hecho, solo hay dos características de las que estoy consciente que no puedes hacer con componentes funcionales y hooks que puedes hacer con componentes basados en clases. La primera es crear límites de error, pero hay algunos paquetes de MPM bastante buenos. Así que normalmente ya no escribo un límite de error, simplemente agrego el paquete de MPM de react error boundary. Y la otra es que en realidad olvidé qué ciclo de vida es. Creo que son los componentes que reciben props. Bueno, una de las funciones del ciclo de vida te dará una característica raramente utilizada donde obtienes una referencia a los objetos DOM reales justo antes de que se actualicen. Así puedes mantener algo como una posición de desplazamiento, etcétera. Y puedes recuperar ese valor justo después de que se renderizó y hacer algo con él. Pero de nuevo, eso es algo que se usa muy raramente solo en escenarios muy específicos. Y no creo que haya tenido que usar eso en los últimos dos años. Así que tampoco he escrito un componente basado en clases en los últimos dos años para hacer eso, excepto tal vez en alguna demostración, pero no en la vida real.

Así que primero, useState. Nos da un estado que está ligado al ciclo de vida de un componente de React y una función para actualizarlos. Básicamente, aquí en la línea cuatro, ves que llamamos al hook useState. Proporcionamos algún valor inicial, esto podría ser una función, o en este caso, es solo una cadena. Devuelve una tupla, que básicamente significa una matriz con un número fijo y tipo de parámetros. Así que el primero es el valor real. En este caso, solo una cadena. Y el segundo es una función que podemos usar para actualizar ese valor. Así que como aquí en el Unchanged, actualizamos un valor llamando a esa función setName con cualquiera que sea el nuevo nombre. Realmente simple, usado por muchos. Me sorprendería mucho escuchar a alguien decir, bueno, eso es agradable, useDate, nunca lo he usado antes. No, es prácticamente el primer hook que todos empiezan a usar. Resulta que es un poco más avanzado. Como acabo de decir con el useDate, cuando lo inicializas, puedes pasar una función en lugar de solo una fecha fija. Esto puede ser útil porque la inicialización puede ser costosa. Podrías tener que hacer algún trabajo computacional o en este caso realmente iterar o cambiar un objeto. En ese caso, esta función solo se llamará una vez para determinar el estado inicial, no después. Así que podría ser un poco más rápido. Otra característica agradable es la función de actualización. Puedes simplemente pasarle un nuevo valor como en la diapositiva anterior, pero también puedes pasarle una función de devolución de llamada que obtiene el estado actual correcto y devuelve el nuevo estado. Así que en este caso, el estado es una fecha y este es el botón del próximo mes. Así que tomamos las fechas actuales o el mes actual de la fecha le sumamos uno, lo añadimos o lo establecemos en la fecha y creamos una nueva y hemos cambiado la fecha. No todos saben sobre estos pero aún así son cosas bastante básicas y bastante útiles de usar.

Probablemente el segundo hook que todos empiezan a usar es useEffect. También bastante básico y muy pocas aplicaciones no van a usar useEffect. Así que useEffect está básicamente destinado a cualquier efecto secundario que hagas dentro de tu componente cuando se renderiza como cuando se monta cuando se desmonta o tal vez cuando se actualizan los valores props, etc. Hay un par de formas diferentes de hacerlo. Así es como funciona useEffect. Llamas al hook useEffect, pasas una función de devolución de llamada y esa función de devolución de llamada se ejecutará después de que se monte el componente y potencialmente muchas más veces. Cuántas veces depende del segundo parámetro que tengo como una matriz vacía aquí. Eso es opcional, pero en la práctica creo que siempre deberías incluirlo porque si no lo haces, tu efecto secundario va a correr con cada renderizado. Ahora eso podría ser válido. Podría ser lo que quieres, pero casi nunca lo es. Así que si lo pasas, pasas una matriz como segundo argumento cualquier dependencia que pongas allí determina cuántas veces se vuelve a ejecutar ese useEffect. Así que en este caso, es una matriz vacía, eso significa que no hay dependencias. Así que este useEffect comienza o se inicializa cuando este componente se monta, luego terminamos con él. Si hay algún valor aquí, entonces el efecto se reinicializará si alguno de esos valores cambia. También puedes tener una función de limpieza. Como en la función de devolución de llamada useEffect, puedes devolver una función y no como hice aquí. Lo siento por eso, pero no debería simplemente escribir code y ponerlo en la diapositiva. Debería probar realmente mi code, ups. Pero esto debería ser una función esa función se ejecutará cada vez que este efecto se reinicie o cuando el componente se desmonte. Así que si este componente de demostración se desmonta, la función clearInterval se asegurará de que este setInterval deje de funcionar. Porque en el caso de un setInterval de lo contrario seguiría funcionando y seguiría cambiando estados para algo que en realidad no proporciona ninguna UI más, lo cual sería un desperdicio. Aquí hay un ejemplo con una dependencia. Así que ahora el intervalo es en realidad parte de la definición de prop. Así que se proporciona desde alguna fuente externa. Así que lo proporcionamos en la dependencia. Y mientras el intervalo sea el mismo, digamos mil milisegundos, entonces vamos a seguir con el mismo setInterval durante el ciclo de vida de este componente. Pero si se vuelve a renderizar con un intervalo diferente entonces el primer setInterval se borra usando clearInterval y se inicia uno nuevo y el segundo se eliminará cuando este componente se desmonte. De nuevo, todavía cosas bastante básicas, pero útiles.

Y, por supuesto, esto también debería haber sido una función. Así que el tercer hook que probablemente no se usa tan comúnmente pero aún es bastante común y básico es useContext. Esto significa que en algún lugar de la cadena de componentes más arriba en la cadena de componentes alguien ha usado un proveedor de contexto para proporcionar algún tipo de valor de contexto. Y luego usamos el contexto. Puedes obtener una referencia a ese valor. Así que lo usas así. Hay un authContext para autorización en algún lugar más arriba que se proporcionó. Y ahora necesito saber los valores actuales para el usuario y obtener una referencia a las funciones de inicio de sesión y cierre de sesión, por ejemplo. Bueno, llamo a useContext pasando ese objeto de contexto y obtengo lo que se proporcionó o los valores predeterminados si no se proporcionó ninguno. Y luego puedo hacer algo como en este caso basado en si hay un usuario actual renderizo un botón de cierre de sesión o si no lo hay ejecuto el botón de inicio de sesión que hará lo que se supone que debe hacer. Probablemente no se usa tan a menudo como los dos primeros useData, hooks de useEffect pero aún así porque es tan fácil este se considera uno de los hooks básicos. La mayoría de las personas habrán usado useContext y en realidad no hay mucho más que decir al respecto. La razón por la que la mayoría de las personas al menos han usado useContext es porque hay tantas bibliotecas diferentes que lo usan. Si dices Redux, por ejemplo, hay un contexto allí y puedes echarle mano. Y lo mismo es cierto con muchas otras bibliotecas. Ahora, a veces usan useContext y en realidad lo envuelven dentro de otro hook, así que un hook personalizado de React y eso es lo que realmente estaremos haciendo más adelante. Pero todavía estamos usando useContext entonces.

Bueno, lo primero que vamos a hacer es que vamos a empezar con los hooks personalizados. Y antes de hacer eso, déjame mostrarte la aplicación con la que vamos a empezar, NPM start. Si puedo escribir start. Ups, ¿dónde fue? Ahí está. Así que esta es la aplicación que vamos a usar. Hay un par de elementos de menú aquí.

Hay un editor de personas, que es básicamente un formulario de entrada simple donde podemos editar una persona. Y luego, después de haber realizado algunos cambios, podemos enviar eso y ver los resultados. Podemos agregar un correo electrónico. Podemos agregar un enlace personalizado. Podemos agregar un nuevo tema. En realidad, podemos ver el objeto persona aquí. Podemos eliminar una vez más. Kim Rolf es ese clon de Formic, que mencioné. Y hay un par de otras cosas, que usaremos y un enlace a la documentación de Formic. Pero por ahora, el editor de personas es el que nos interesa.

Si observamos el código, hay este formulario de editor de personas, para carpetas están aquí y los componentes de editor de personas. Hay un index.ts, pero eso no hace nada más que exportar ese editor de personas solo para facilitar un poco la vida. Todo el formulario está prácticamente aquí, excepto que hay este componente de entrada etiquetado, que se utiliza, que realmente obtiene la etiqueta en una entrada. Así que eso es básicamente responsable de estas partes. Pero aparte de eso, es completamente, ese no es el que quería cerrar, este. Quiero mantenerlo abierto. Este es el componente completo. También puedes notar, está utilizando state, el estado del usuario y el estado es una persona o NULL, lo que normalmente obtienes cuando obtienes algunos datos del servidor o algo así. No estoy obteniendo realmente datos del servidor, en realidad tengo algunos datos en IndexedDB o potencialmente está en IndexedDB. Así que estoy usando esta biblioteca, local forge, que es un envoltorio realmente agradable y fácil de usar alrededor de IndexedDB, hace la vida un poco más simple. Es asíncrono porque toda la API de IndexedDB es muy asincrónica. Así que usa el peso y una vez que encuentra una persona allí, carga eso o si no lo ha hecho, carga esta persona inicial, que es en realidad lo que vimos la primera vez. Pero si hago algunos cambios aquí, agrego algunos valores y presiono F5, simplemente actualizo la pantalla o lo hago de nuevo, verás que en realidad guarda esos valores y los recupera porque aquí en mi pestaña de Aplicación, si voy a Index DB, local forge y luego los pares clave-valor aquí mismo, puedes ver que ese valor está realmente allí, y también hay un poco de código que cada vez que hago un cambio, puedes ver que en realidad guardó ese objeto en Index DB. Ahora, eso es con lo que vamos a comenzar, y lo primero que vamos a hacer es crear un hook personalizado porque todo está dentro de ese componente, y bueno, en este momento, eso no es tan malo en realidad porque es prácticamente solo la UI, la parte no UI real es solo esto, cargar un poco de código, pero vamos a agregar bastante a eso, y se va a volver más complejo, y realmente no pertenece dentro del componente de UI. Y en los viejos tiempos, probablemente habrías creado algún tipo de componente envolvente, tener componentes de presentación y otros componentes para contener esto, pero hoy en día, podemos hacer eso con hooks mucho mejor. Así que vamos a extraer este código, ponerlo en el hook personalizado y simplemente usarlo. A menudo, cuando creo hooks personalizados, lo hago porque eso hace que todo el código sea reutilizable. En este caso, no va a ser tan reutilizable, podría hacer esto más reutilizable, pero no lo voy a hacer. Va a estar muy codificado sobre cómo obtener una persona de IndexedDB o la inicial. En la segunda parte, haremos cosas como esta con hooks personalizados donde será mucho más reutilizable. Pero vamos a empezar, cosas simples. Básicamente, lo que voy a hacer es decir, bueno, este hook se trata de personas o una persona. Así que voy a crear un hook usePerson, que guardará y cargará una persona y la devolverá al componente. Y en el componente en sí, básicamente voy a decir, ok, dame una persona, dame una función para cambiar esa persona para que todavía podamos cambiarla desde todas las funciones no modificadas. Y obtén eso del hook y pasaremos esa persona inicial. Hacerlo es bastante simple. Todo lo que hacemos es crear una nueva función, usePerson.ts. Así que con TypeScript, y el componente de React necesita ser un archivo tsx, pero esto es solo una función normal de TypeScript. Es algo especial para React, pero para TypeScript, no lo es. Así que podemos seguir usando un archivo normal de TypeScript. Aunque, si usas un archivo tsx, eso tampoco está mal. Copié todas las importaciones en la función de guardado. Haremos una función de exportación, usePerson. Pegaré todo el código que queríamos allí. Y esto es básicamente lo que vamos a devolver. Aún no va a funcionar del todo. Necesitaremos hacer algunos cambios más, pero primero hagamos el uso. Obtendremos una tupla con esas mismas cosas. Y diremos, obtendremos eso también. Y diremos, obtendremos eso de usePerson. Ahora estamos obteniendo algunos errores de compilación. Necesitamos solucionar eso. Básicamente, estoy devolviendo solo una matriz con una persona y una función y TypeScript no es realmente consciente de que eso es una tupla con exactamente los mismos tipos a lo largo del tiempo. Así que lo que voy a hacer es ayudar a TypeScript un poco, hay un par de formas diferentes de hacerlo. Pero voy a decir, bueno, esto va a ser una persona o no, el primer argumento. Y el segundo va a ser una función que no devuelve nada, por lo que es void. Y eso toma un objeto persona que es de tipo persona o no nuevamente. Y eso debería solucionar mis errores de compilación. Aún tengo esa persona inicial importada. Quería eso como un parámetro. Así que vamos a tomar eso y simplemente definir esto como parámetro que nuevamente es de tipo persona. Así que ahora si vuelvo a mi componente tengo el error de compilación aquí que dice, bueno, esperaba un argumento pero obtuve cero. Así que queremos pasar initialPerson aquí. Podemos hacer algo de limpieza aquí. Hay muchas cosas que no necesitamos. Esa función de guardado está en el hook. Veamos qué más. En realidad, dejemos que Visual Studio lo resuelva por mí. Limpiemos esas importaciones. Lo mismo aquí, hay muchas importaciones que no necesitamos. Eliminar eso. Eliminar esos. Así que ahora tengo un hook usePerson. Recuerda que todos los hooks deben comenzar con la clave use. Así que siempre es use esto, use eso, no solo los hooks estándar. Siempre debe comenzar con use. Explicaré más por qué es así en un momento. Primero, asegurémonos de que todo siga funcionando. ¿Todavía puedo guardar? Y después de actualizar, ¿sigue ahí? Sí. Y si envío, todavía vemos que aparecen los valores. Así que sigue siendo completamente funcional. Ese es tu primer paso que vas a hacer. Así que voy a abrir las salas de discusión. Si piensas, espera, esto no parece tan avanzado todavía. No te preocupes, estamos empezando fácil. Lo vamos a hacer más complejo a medida que avanzamos y las cosas se vuelven más desafiantes. Así que ahora hay 23 participantes. Así que voy a abrir siete salas de discusión. La mayoría de ustedes debería estar en una sala de discusión con tres personas.

Entonces, cuando llegues a la sala de desglose, preséntate a los demás. Esperemos que estés en la sala de desglose con las mismas personas todo el tiempo. Voy a abrir esta sala de desglose durante cinco minutos. Después de cinco minutos, recibirás un mensaje, una notificación de que la sala de desglose está a punto de cerrarse. Tendrás otro minuto de período de gracia donde obtendrás un temporizador de cuenta regresiva que dice que se cerrará en 50 segundos, 49, etc. Así que puedes terminar las cosas. Y después de eso, se cerrará automáticamente y todos volverán a la sala principal aquí. Si te quedas atascado por cualquier motivo, puedes invitarme a tu sala de desglose para que pueda ayudarte allí, o puedes hacer preguntas en discord, o puedes volver a la zona principal y simplemente hacerme una pregunta ya sea por voz o, bueno, con chat o algo así. Lo que funcione mejor para ti. Somos flexibles en ese tipo de cosas.

Antes de abrirlo, veo que había una pregunta sobre el cambio a la rama. Entonces, la rama con la que vas a empezar es esa rama 00start. Así que solo ve a 00start origin y llegas a la rama que tenía todo en el editor de personas. Recuerda que las otras ramas aquí son si te quedas atascado. Supongamos que te quedas atascado aquí, entonces el hook personalizado 0 1 es el final de este paso, que también será el comienzo del siguiente paso. Por eso están aquí todas esas ramas intermedias. Así que con eso, déjame abrir las salas de desglose y nos vemos a todos de vuelta aquí en la sala principal en cinco minutos.

Pregunta. ¿Cómo comprobamos si nuestro code es válido? ¿Podrías demostrar en tu navegador, cómo debería funcionar realmente el comportamiento si el code es correcto? Si el code es correcto, si inicias la aplicación aquí y vas al Editor de Personas así, puedes escribir algo y verás los cambios reflejados aquí. Supongamos, déjame romper esto por un momento. Supongamos que no hago esto, pero paso una función ficticia así, en realidad no le gusta eso. Ahora sí, así que estoy de vuelta aquí. Y ahora, por ejemplo, ya no puedo escribir. Lo mismo si envías, deberías ver los cambios que hiciste en la ventana emergente, en la ventana de alerta. Otra cosa que puedes hacer es comprobar la ventana de la console aquí, si ves algún error. Cada vez que haces un cambio, deberías ver un mensaje de guardado como este. Así que ahora no puedo, pero si hago mis cambios, si deshago mis cambios, debería poder guardar de nuevo. Así que ahora si hago cambios, ves mensajes de guardado. ¿Sí? Excelente, gracias. ¿Otras preguntas? No, vale, nos vemos en cinco minutos.

Bien, ya están todos de vuelta. Así que un paso bastante simple y fácil, solo extrae el code en una función separada. Ahora, mencioné que los Hooks Personalizados deben ser usados o deben ser nombrados use algo. En este caso, use person. Y al igual que los hooks estándar, useState, useEffect, useContext, useReducer, useCallback, veremos un montón de ellos. Todos se llaman use. ¿Pero por qué es eso? ¿Por qué tenemos que nombrarlos use? ¿Y romperíamos realmente React si no lo hiciéramos? Bueno, echemos un vistazo. En primer lugar, podrías notar que hay algunas líneas aquí. Tengo una advertencia de profundidad exhaustiva del hook de React por una dependencia faltante. Falta esa persona inicial, que realmente debería estar allí. Pero supongamos que no llamé a esto usePerson sino que simplemente lo llamé un hook de persona o algo así. Y vuelvo a este editor y digo, ahora mismo aquí en la parte superior, estoy llamando al hook de persona. Hay un par de, advertencias de linting aquí diciendo, nuevo estado llamado en la función hook de persona que no es ni un componente de función de React ni una función de hook personalizado de React. Así que hay algunas quejas pero ¿está realmente rota mi aplicación? Si miro la ventana de la console donde se está ejecutando el servidor no hay mensajes de error de compilación en absoluto. Si vuelvo a la aplicación, todavía puedo refrescarla perfectamente. Todavía puedo hacer cambios en ella perfectamente. Puedo enviar. De hecho estaba guardando esos cambios. Así que en realidad parece que todo está bien. Entonces, ¿por qué tenemos que hacer eso? Bueno, echemos un vistazo a algunos de los códigos fuente reales de React. Para ser exactos, estoy dentro de los códigos fuente de React en el plugin ESLint de React Hooks. Así que esto es parte del código fuente de React pero es un plugin para ESLint. Y para ser más específico, estoy en las reglas del hook de hooks o regla debería decir. Y primero esta pequeña función aquí que verifica en el ASD. Así que el árbol de sintaxis abstracta que se crea cuando se analiza tu código fuente. Y luego la regla de ESLint trabaja en eso. Y básicamente comprueba, bueno, ¿es este nodo, es eso un hook o no? Así que mira si el tipo es un identificador y el nombre es un nombre de hook. Y esa función de nombre de hook está definida aquí arriba. Y eso básicamente dice, bueno algo se considera un hook. Así que si es un identificador y está nombrado, use algo con una letra mayúscula A a Z o un número, y luego algunas otras letras cero o más. Entonces es un hook. De lo contrario no es un hook. Así que el resultado de eso es que obtenemos errores aquí diciendo, bueno, declaras que eso es un hook que sólo puede ser usado dentro de un hook porque esto no es use algo. Tan pronto como cambio esto de nuevo a use algo y luego tiene que ser usado digamos así, use y luego una letra mayúscula. Ahora esas comprobaciones están perfectamente bien de nuevo. Todavía tengo esa advertencia aquí porque eso es realmente algo que necesito arreglar. Pero eso es básicamente todo lo que hay en ello. Es sólo una función y las convenciones de nomenclatura lo convierten en un hook para las reglas de ESLint pero técnicamente hablando, no necesita ser cualquier función funcionará. Si no se llama use, todavía funcionará. Ahora, ¿de qué otra manera puedes saber eso con seguridad? ¿Qué pasa con este archivo si creo una construcción de producción? Bueno, este code va a ser minimizado. Y estoy exportando esta función pero es sólo un nombre local dentro de este módulo. Así que, si hago una construcción de producción, este hook de uso va a ser algo como X o algo así. Ya no se va a llamar use nada más. Va a ser llamado lo que sea un nombre corto. Así que incluso entonces todavía funciona. Ahora, ¿dónde puedes equivocarte con esto? Déjame deshacer estos cambios. ¿Qué fue lo que se deshizo aquí? Sí, inspecciona a use person. Así que estamos bien. Podrías haber notado que hago exportaciones de funciones, así que uso exportaciones nombradas. Pero lo que sucede bastante a menudo es que la gente hace esto, exportar por defecto. Y eso no es malo per se. Tengo que cambiar un poco mi importación, porque ahora es una importación por defecto. Todo sigue funcionando perfectamente bien. Como todo esto todavía funciona, no hay problema. Pero, ¿qué veo a veces que la gente hace? Bueno, son perezosos. No, piensan, bueno, va a ser una exportación por defecto. Realmente no me importa este nombre. Haremos una función anónima y haremos esto. Exportar por defecto así sin la cita. Una función anónima. ¿Es esto un hook? Bueno, según las reglas de React, realmente no lo es. No es un hook. Todavía piensa que está bien. Tal vez eso se base en el nombre del archivo. No estoy muy seguro de por qué no se queja de used state. Pero esto es sólo una función anónima aleatoria. Así que una razón para no usar exportaciones por defecto porque puedes empezar a hacer cosas y puedes limitar el número de reglas de ESLint ejecutadas y perder posibles grandes problemas allí. Así que voy a deshacer estos cambios de nuevo. Así que realmente por eso tenemos que nombrarlos no tanto por el tiempo de ejecución sino por las tooling. Ahora veamos algunos otros hooks que pueden ser útiles.

Usa useLayoutEffect. Y si miras la documentación, dice, bueno, es como useEffect, pero se dispara de forma síncrona después de todas las mutaciones del DOM. Lo que implica que useEffect se dispara de forma asíncrona, lo cual es cierto. useEffect se dispara de forma asíncrona un poco más tarde, y useLayoutEffect se dispara un poco antes, pero aún después de que el componente se haya renderizado.

Ahora, básicamente, cuando te preguntas si deberías usar useLayoutEffect o useEffect, si no tienes una razón específica para usar useLayoutEffect, entonces siempre debes usar useEffect. Ese debería ser tu hook predeterminado para los efectos secundarios. Pero el hecho de que useLayoutEffect se dispare antes puede ser útil en algunos escenarios. Permíteme mostrarte un caso. Ahora mismo, ¿dónde está mi code aquí? Ahora mismo, estamos cargando la persona aquí. Y eso puede ser una llamada asíncrona, por lo que podría llevar algún tiempo cuando el componente se carga por primera vez y luego queremos que se muestre. Lo cual funciona más o menos. Pero, ¿qué sucede si esto es lento? Digamos que tenemos una función de espera y voy a esperar dos segundos y medio. Y lo vamos a esperar porque estamos en una función asíncrona. Así que ahora, si este componente se carga por primera vez, vamos a ver el spinner durante dos segundos y medio y luego se carga el formulario. Algo así como lo que sucede con una solicitud AJAX en una red lenta. Pero vamos a borrar esto y ver qué puede suceder. Así que voy a hacer clic en Editor de Personas para cargar el componente, pero antes de que pasen los dos segundos y medio, voy a presionar Alt-Flecha Izquierda, que básicamente es lo mismo que presionar este botón. Y voy a volver a la lista. Y en ese caso, veremos aparecer un error. Así que la espera todavía se está ejecutando. Y en realidad, esperaba ver un error. ¿Por qué no estoy viendo un error? Eso es interesante. Veamos. No, no estoy viendo un error aquí. Pero parece que algo está sucediendo. Así es, creo que está atascado. No, no estoy viendo un error. Continuemos. Y luego noto algo sobre esto así como esto. No puedo establecer esta persona... No puedo llamar a la función de configuración en un nuevo estado después de que un componente se haya desmontado, pero por alguna razón eso no está sucediendo. Permíteme comenzar de nuevo para asegurarme de que no tengo nada raro. Ese es el error que esperaba. No estoy seguro de por qué no sucedió antes. Es posible que hayas visto esto cuando estabas desarrollando una aplicación de React. No puedo realizar una actualización de estado de React en componentes no montados. Entonces, ¿por qué sucede eso? Bueno, si volvemos al code, el componente se monta, este useEffect se dispara, llamamos a getPerson. Entonces getPerson es una función asíncrona aquí. Permíteme hacer zoom un poco. Y luego comienza a hacer esto. Así que primero espera dos segundos y medio, luego obtiene la persona de la base de datos, y luego modifica el estado del componente llamando a esa setPerson, que viene aquí desde el useState, lo cual está bien en el flujo normal de las cosas. Pero si este componente se desmonta antes de que ocurra realmente esta setPerson, entonces estamos llamando a esto en un componente no montado y eso podría ser potencialmente una fuga de memoria. Ahora, en este caso, no lo sería porque no estamos guardando una referencia, no es algún tipo de setInterval. Entonces no será un problema, pero podría serlo si esto estuviera en un setInterval que sigue disparando, mantendrá una referencia a esa setPerson, que mantiene una referencia al estado subyacente en el componente de React, etc., y tenemos una fuga de memoria. Porque React no sabe si tenemos una fuga de memoria o no, pero es potencialmente cierto, nos advierte al respecto. Ahora, eso está bien. No hay nada malo. Esta advertencia está justificada. Y en este caso, podríamos ignorarla, pero si comenzamos a hacer eso, es como, bueno, comenzamos a ignorar advertencias, que potencialmente podrían ser una verdadera fuga de memoria en un problema. Entonces es mucho mejor prevenir esto y no ignorarlo por completo. Entonces, de alguna manera, necesitamos saber aquí si nuestro componente ya se desmontó. Bueno, si hago otro useEffect, entonces es como, bueno, todos se disparan al mismo tiempo y es difícil saber si está desmontado, pero con useLayoutEffect, sé que tanto el montaje como el desmontaje se disparan primero. Entonces, aquí abajo, podría decir useLayoutEffect, y el uso es exactamente el mismo que useEffect. Entonces, aquí puedo hacer algo que diga que está montado. Así que voy a hacer algo malo primero. Lo arreglaremos más tarde. mounted es falso. Aquí, voy a decir que mounted es verdadero, y luego voy a devolver una función de limpieza. Establecer mounted en falso nuevamente. Y ahora solo voy a hacer esta actualización si realmente estamos montados. Ahora esta parte está bien. Lo malo está aquí, pero lo arreglaremos más tarde. Pero solo para explicar por qué es malo, esto está a nivel de módulo. Entonces esta bandera mounted se compartirá entre todas las instancias de este hook usedPerson. Entonces, si se usa 10 veces, la primera vez mounted pasará de falso a verdadero. Cuando se desmonte, volverá a falso. Pero si se montó una segunda vez, bueno, comenzaría en verdadero. Entonces no es la forma correcta. Pero, como dije, lo arreglaremos en un momento. Entonces, si hago lo mismo y me aseguro de que todo esté en buen estado, ahora, si voy a Editor de Personas y vuelvo, no hay errores, nada. Y solo para asegurarme de que no sea por la misma razón que antes, vamos a comentar esto. Refrescar de nuevo. Y ahora deberíamos ver que aparece ese mismo error nuevamente. Y ahí está de nuevo. Entonces aprovechamos el hecho de que el layout effect se dispara antes. Entonces podemos establecer la bandera mounted en verdadero y falso y usarla en otros efectos secundarios. Potencialmente, querríamos envolver esto aquí también. Para no guardar cuando estamos desmontados, etc. Pero no voy a hacer eso ahora mismo. Entonces, usando useLayoutEffect para rastrear el estado. Así que ese es otro cambio bastante pequeño. Así que voy a abrir las salas de desglose durante cinco minutos nuevamente, como antes. Y luego, en el próximo conjunto de cambios, vamos a solucionar el problema donde usamos una variable de ámbito de módulo para rastrear si un hook se cargó o no. Pero haremos eso después de esto. Así que déjame encontrar las salas de desglose porque por alguna razón mi ventana de salas de desglose ha desaparecido. Ahí está, ha vuelto. Así que nos vemos en cinco minutos.

Bien, ya están todos de vuelta. Entonces, veamos cómo podemos solucionar esa variable cargada que estaba en el ámbito equivocado, el ámbito del módulo, en lugar del ámbito del hook y el ciclo de vida real de la función asociada. Y vamos a usar otro hook para eso, el hook useRef. Si miras la documentación, dice que useRef devuelve un objeto ref mutable cuya propiedad actual se inicializa al argumento pasado, que es algo así como, bueno, eso está bien. Bueno, ¿qué es? ¿De dónde viene? Bueno, useRef, su propósito principal es llegar a los elementos del DOM u otros componentes. La parte ref significa referencias. Y es una forma en la que puedes obtener fácilmente una referencia a algo más. Creas un objeto usando useRef y luego lo pasas a tu JSX, a un elemento del DOM u otro componente, y obtendrás una referencia a eso. Entonces, un ejemplo podría ser algo como esto. Entonces, en la línea cuatro, decimos, bueno, useRef de algún elemento de entrada HTML, y lo inicializaremos en nulo, y luego en la línea 14, usingRef es igual a la referencia a ese objeto ref que creamos en la línea cuatro. Lo pasamos, y luego después está esta propiedad ref.current en useEffect que está disponible porque eso sucede después de que el componente se monta, después de que este JSX se ha agregado realmente al DOM. Entonces ref.current apunta al objeto DOM real para esta entrada, por lo que puedes obtener ese valor o cualquiera de las otras propiedades que hay. Entonces, en este caso, simplemente estamos estableciendo el valor. Podrías recuperarlo o tal vez agregar un manejador de eventos o cualquiera de esas cosas, lo que quieras hacer. Entonces, bastante simple, útil. Para ser honesto, uso useRef bastante, pero casi nunca hago esto. Ocasionalmente sucede, pero no muy a menudo. También puedes pasarlo a un componente hijo de esta manera. Tengo un componente de demostración que renderiza un componente de campo de entrada, en la línea 5, creé ref de exactamente la misma manera, y en la línea 20, lo estoy pasando de exactamente la misma manera. Ahora, lo que obtengo realmente depende de cómo se ha configurado el campo de entrada. Si fuera solo un componente regular, obtendría una referencia a ese componente. Pero lo que puedes hacer es aquí con React forward ref, puedes decir, bueno, voy a envolver el componente con un forward ref, obtendré el ref de eso y podré usarlo, y obtendré todas las demás propiedades también. Entonces, los primeros argumentos aquí son todas las propiedades, y el segundo es el ref actual que se pasa. Ahora, aquí en la entrada, lo estoy pasando de nuevo. Entonces, el ref original en realidad se reenvía a este elemento de entrada, y eso es lo que obtengo, por eso podría decir ref.currents.value de nuevo y hacer algo con él. Ahora, estos son útiles, y ciertamente son cosas que ocasionalmente necesitas hacer, pero resulta que usar refs es mucho más poderoso de diferentes maneras, porque básicamente cada vez que llamas al hook useRef en un componente o en otro hook, obtienes este objeto con la propiedad actual de vuelta, y puedes comenzar a usar esa propiedad actual para lo que quieras. Puedes almacenar un objeto allí, una función, un valor simple como una cadena o un booleano o un número, lo que quieras. Y una cosa realmente agradable es que useRef es considerado estable por React, por lo que no tienes que incluirlo en las dependencias de los efectos. Entonces, si usas efecto, el segundo argumento, la matriz de dependencias, bueno, todo lo que no está referenciado debería ir allí o casi todo. Una referencia de useRef no necesita ir allí, por lo que puedes manipular ese current y hacer lo que quieras y no necesitas preocuparte por los efectos secundarios que se reinician o como lo harías con useState. Si llamas a la función setter, entonces desencadenas un rerenderizado en ese componente porque su estado cambió. Nuevamente, con el ref eso no sucede. Entonces, útil para todo tipo de cosas. Y podemos usar eso aquí mismo para ese estado cargado. Entonces, en la línea 16, puedes decir, bueno, en lugar de tener algún tipo de variable fuera del ámbito de este hook, simplemente vamos a usar useRef e inicializarlo en falso. Entonces, loaded.current va a ser falso. En el useLayoutEffect, lo establecemos en verdadero. En la limpieza del efecto de diseño, lo establecemos en falso. Y ahora podemos usar eso donde queramos. Realmente agradable. Entonces, deshagámonos de este montado porque eso está mal. Y haremos const. Montado es useRef. Quiere algún valor inicial. Lo llamaremos, le daremos falso porque aún no está montado. Montado ahora es un objeto ref mutable de tipo Boolean. No tengo que especificar el tipo como lo hice con useState porque todos estos hooks intentan determinar el tipo de sus estados. En este caso, si dejara el tipo real fuera, diría, bueno, es un estado de nulo. Aquí, falso está bien. Entonces, no necesito hacer eso. Entonces, montado no va a ser verdadero pero montado.current va a ser verdadero, lo mismo con montado.current volviendo a ser falso. Y montado siempre es un objeto. Entonces, necesitamos verificar ahora, montado.current. Y eso debería darnos exactamente el mismo comportamiento que antes. Entonces, puedo ir al editor de personas, volver atrás y no obtenemos ningún error sobre el cambio de estado cuando el componente ya se había descargado. Y no hay errores ni advertencias de ESLint sobre dependencias faltantes, a pesar de que estoy usando ese montado. Entonces, estoy usando esa referencia montada aquí ahora. Por qué eso es lo dejaremos hasta la próxima parte. Entonces, lo primero que vamos a hacer ahora es realmente cambiar nuestro usedPerson y agregar ese useRef a él y rastrear el estado cargado usando eso. Entonces, eso es.

Esa es una pregunta. Sí, adelante. No soy nuevo en useRef, pero tengo una pregunta, ¿cómo puedo entender esto mejor? Entonces, el useRef utilizado en realidad establece una variable dentro del ámbito de este hook. Sí. Y no, pero ¿hay algún caso de uso para transmitir esa referencia a otro lugar? ¿Podemos exportarla desde el hook y usarla fuera o no hay casos de uso para eso? Oh no, definitivamente puede haber y es solo otra variable. Entonces, supongamos que quiero exportarla, puedo agregarla aquí. De acuerdo, pero es. No, lo siento, se llamaba montado. Entonces, pero seguirá siendo, si mutamos el valor exportado, no hará referencia a esta referencia dentro del ámbito de esta función. Si en otro lugar haces montado.current es algún valor nuevo, aún mutas esa misma referencia, que está vinculada a esto. Y no desencadena un rerenderizado, etc. Entonces, no estás seguro si sería una buena idea, porque no hay seguimiento de dependencias allí. No es como si este código estuviera consciente de eso, por lo que comenzaría a ejecutarse. Entendido, gracias. En ese caso, necesitarías usar algo como useState, para que el componente se vuelva a renderizar. El punto principal aquí no es hacer que el componente se renderice. Estoy manteniendo un proyecto que no es nuestro en la empresa, así que tenemos muchos errores heredados. Y estamos tratando de entender varias cosas, así que esa es mi pregunta. Sé que es un caso excepcional, pero necesitaba cubrir eso en mi mente. Sí, está bien. Gracias.

Bien, déjenme abrir las salas de grupos. Las abriré durante tres minutos porque este es un cambio trivial. Y luego, en tres minutos, veremos por qué en realidad no tuvimos que cambiar esas dependencias para ese useEffect. Nos vemos en tres minutos. Tengo otra pregunta sobre los useRef. Sí, adelante. Entonces, ¿mi comprensión es correcta de que cada vez que llamo a este hook, se crea una referencia diferente para eso, digamos, componente, que llama al hook? Sí, al final, la referencia está vinculada a los componentes, que inicializan esto, por lo que este useRef se usa dentro de otro hook, pero el estado real al final está vinculado al componente, que comienza a usar el primer hook. De acuerdo, gracias. De nada.

Todos están de vuelta, de acuerdo. Entonces mencioné que el objeto ref no necesita ser agregado a una matriz de dependencias, y de hecho, lo mismo es cierto para otra cosa. Puedes ver aquí que estoy usando usedStates, y tengo esta dependencia o esta función setPerson que se devuelve de eso, y la estoy usando dentro de este hook useEffect, pero eso no necesita ser agregado aquí. Ahora, está bien si quiero. Si lo agrego, no hay problema, no hay errores. Pero si no lo hago, tampoco obtengo ninguna advertencia. Pero para initialPerson, sí. Si lo elimino, aparece diciendo, bueno, tiene una dependencia faltante initialPerson. Y si digo, actualizar las dependencias a lo que debería ser, solo aparece initialPerson. Entonces, ¿de dónde viene eso? ¿Qué hace que se comporte así? Entonces vamos a volver al código fuente de React. Y, puedes ver aquí, en realidad estoy en el repositorio de GitHub de React en Facebook. Nuevamente, en el complemento ESLint, react-hooks. Pero ahora estoy en una regla diferente. La regla de dependencias exhaustivas. Y hay esta función, isStableKnownHookValue. Se pasa una nota desde el árbol de sintaxis abstracta, que se analiza. Entonces, básicamente esta función y estamos dentro de useEffect. Entonces, básicamente ve todas estas cosas aquí como LocalForge, mountedPerson, initialPerson, etc. Entonces, va a echar un vistazo a todas esas y básicamente va a decidir si eso es estable o no. Y puedes ver cosas como si es una matriz, entonces es falso. Si no, lo siento, ni siquiera estoy seguro de qué son estos, pero si es algún tipo de variable, devuelve falso. Entonces, básicamente todas son valores de hook no estables hasta que desplazo un poco hacia abajo. Aquí hay uno sobre literales, que pueden ser verdaderos, pero el que estaba buscando está justo aquí. Entonces, si esto fue creado por algo llamado useref y es un identificador, entonces es, como dice el comentario el valor de retorno de useref y eso se considera estable. Entonces, en realidad no mira lo que realmente es, solo mira cómo se creó. Y si fue creado por algo que se parece al hook useref, entonces se considera estable. Lo mismo es cierto con, no voy a hacer esto completamente visible, pero si el nombre es useState o useReducer, va a mirar los argumentos y en algún lugar aquí, justo aquí. Determina que si esto es el segundo argumento de la tupla que se devuelve, entonces la función setter, el setState o la función reductora en el caso de useReducer, entonces se considera estable. Lo que nuevamente significa que esta persona, la función setPerson aquí se puede usar sin tener que agregarla aquí. Ahora, ten en cuenta que también la estoy exponiendo. Lo interesante es que si vuelvo aquí, tengo una referencia exactamente a ese mismo setPerson. Supongamos que creo otro useEffectHook aquí, paso la función de devolución de llamada, y llamo a setPerson aquí con algo, solo lo llamaré con no, y pongo una matriz de dependencias vacía. Ahora, de repente, comienza a quejarse, se debe incluir setPerson. Pero si copio este mismo código exacto aquí, no hay quejas aquí, está bien. Es el mismo hook o una misma referencia de función. Pero como puedes ver en la regla, en realidad no mira lo que es la función, cómo se creó. Solo mira cómo llegamos a ella. Y aquí, mira, setPerson, vamos desde setPerson, que es el segundo argumento de las tuplas. Tupla devuelta por useState. Y sabe, bueno, el segundo argumento es estable. Aquí dice, bueno, tenemos este setPerson y déjame resolver esto para que el error desaparezca. Tenemos este setPerson. Es el segundo argumento de algún hook llamado usePerson. Las reglas de Linting no tienen idea de lo que es usePerson por lo que no hace referencia a lo que realmente es setPerson. Entonces dice, bueno, en ese caso debes agregarlo como una dependencia. Por eso tengo que agregarlo aquí. Ahora, ¿tiene algún efecto negativo en tiempo de ejecución? No lo tiene. setPerson sigue siendo esa misma función setPerson o función setPerson de useState. Es estable, por lo que aunque tengo que especificar esta dependencia aquí, nunca cambiará. Entonces, al final, no significa que este hook se dispare con más frecuencia o se comporte de manera diferente. Es un poco molesto tener que especificarlo allí. Y también explica algo que ocasionalmente me preguntan ¿Puedo crear mi propio hook y puedo especificar que esta función setPerson es estable que no necesito usarla en algún tipo de hook? Bueno, no, no puedo porque eso está realmente vinculado al hook de React. Está realmente vinculado a una función llamada useState. Entonces, supongo que si creo mi propio hook llamado useState y no importo useState de React sino que uso eso, entonces las reglas de limitación realmente comenzarían a pensar que el useState que estoy usando es el de React. En realidad no verifica eso. Y podrías obtener un comportamiento interesante de esa manera. Ciertamente no se recomienda hacer eso. Permíteme eliminar esa importación nuevamente porque no la necesitamos.

Pero por eso algunos valores son estables. Básicamente, están codificados en estas reglas nuevamente. Al igual que la parte original del nombre estaba codificada en las reglas de ESLint. No es un problema, pero es algo de lo que hay que ser consciente.

Ahora hay algo más que podría querer cambiar. Permítanme cerrar estos. No los necesito. Si vuelvo a mi Editor de Personas, y por cierto, elimino ese sleep porque solo hace que las cosas sean más lentas y no lo necesitamos. Lo que querría cambiar aquí para un escenario más realista es el guardado. En este momento, si borro esto y comienzo a escribir en la primera noche, básicamente cada pulsación de tecla activa una acción de guardado. Ahora, actualmente, la acción de guardado es local. Va al índice db y eso es bastante rápido así que no estoy demasiado preocupado por eso, pero es un poco derrochador. En un escenario realista, esto probablemente significaría que se hizo una solicitud HTTP a un servidor y se hizo una actualización de database. Bueno, ¿realmente queremos hacer eso en cada pulsación de tecla? No, queremos agrupar esas acciones y no hacerlo tan a menudo. Ahí es donde entra en juego el efecto de debounce. A menudo se habla de debounce y throttle. Son bastante similares. La diferencia entre debounce y throttle es que si tienes una función y la limitas con throttle a una vez por segundo, puedes llamarla tantas veces como quieras. Pero en realidad, la función real se ejecutará como máximo una vez por segundo. Entonces, si sigues escribiendo, verás aquí y está limitado a un segundo, verás un guardado cada segundo. Por otro lado, el debounce espera un cierto tiempo de inactividad. Entonces, si limito el guardado a un segundo, el code realmente esperará hasta que deje de escribir en el medio de dejar de escribir durante un segundo completo y luego ejecutará la acción de guardado. Ambos son perfectamente válidos, diferentes usos o diferentes escenarios de diferentes casos de uso. En este caso, guardar cuando realmente dejo de escribir es perfectamente razonable. Así que usaré un efecto de debounce. Y los términos son crear un hook de debounce reutilizable es realmente, realmente simple, casi no requiere code en absoluto y es completamente reutilizable, que es básicamente el resultado de un hook personalizado muy simple. Usando use effect y usando set timeout con clear timeouts. Si el efecto se reinicializa. Entonces, todo lo que necesitamos hacer se ve así. Hemos usado el hook de debounce. Pasamos alguna función de devolución de llamada, que es el code real que queremos ejecutar. Pasamos el tiempo de espera. Usamos use effect para desencadenar ese efecto secundario. Usamos set timeout para lograr el retraso. Entonces decimos, está bien, espera hasta cierto retraso. Pero si pasamos nuevos valores para la función o un tiempo de espera, antes de que expire ese retraso, este efecto se cancela. Se llama a clear timeout. Deteniendo el set timeout original, e inicializamos uno nuevo. Entonces veamos, veamos cómo funciona realmente. Así que crearé un nuevo hook. Use debounce.ts. Función de exportación. Use debounce. No con mayúsculas. Recuerda, es un hook, por lo que aún debe llamarse use algo. Entonces toma dos argumentos. Primero, la función de devolución de llamada a ejecutar. Que es solo alguna función que no necesita devolver nada. Y toma un tiempo de espera. Que es un número. Y esto en realidad no devuelve nada, por lo que podemos definirlo como void. Entonces aquí usamos use effect. E inicializamos la matriz de dependencias. Que necesitaremos completar más adelante. Entonces, tomaremos el identificador de, y setTimeout. Entonces, después de que haya pasado algún tiempo, llamamos a esa función que se pasa, y especificamos el tiempo de espera. Ahora, podemos hacer que ESLint determine las dependencias que necesitamos, especificar la función de limpieza para cancelar el setTimeout. Oops, eso debería ser un error gordo. Clear timeout con el identificador, y deberíamos tener un hook useDebounce completamente funcional. Entonces, usemos eso para guardar. Ahora, el guardado se realiza actualmente aquí, dentro del hook useEffect, que básicamente dice, está bien, cada vez que cambia el objeto persona, queremos guardarlo. Bueno, ya no queremos hacerlo en cada cambio. Queremos usar el hook useDebounce, básicamente. Oops, estoy haciendo lo mismo, con mi función FedError(). Y pongamos eso en un segundo, de lo contrario, aún guarda con bastante frecuencia, y todavía necesito resolver eso. Un hook bastante pequeño para crear y muy fácil de usar. Ahora asegurémonos de que realmente funcione. Entonces, ahora, si voy al nombre y comienzo a escribir, en realidad no sucede nada hasta que dejo de escribir durante un segundo y luego guardamos. Así que parece perfectamente bueno y perfectamente válido para usar. Sin embargo, hay un ligero problema, en este momento estamos llamando a una función que se definió en línea. y dentro del hook usedebounce, básicamente estamos diciendo, bueno, tenemos esa función pero cada vez que cambia la función y cambia la referencia de la función, es decir, inicializamos un nuevo efecto. En este caso, en realidad funciona como se pretende pero supongamos que el componente se volvió a representar por alguna otra razón, este hook se llamaría en este caso, predeterminado, llamaría a usedebounce nuevamente, llamaría a safePerson nuevamente o al menos crearía esta función nuevamente. Sería una nueva función. Entonces obtendríamos una nueva función. El ciclo de debounce anterior se cancelaría, se iniciaría uno nuevo. Seguiremos guardando, pero potencialmente un poco más tarde. Y si algo más actualiza este componente, digamos cada 500 milisegundos, en realidad nunca llegaríamos a guardar. Entonces eso es algo que necesitamos solucionar. Lo solucionaremos en un momento. El primer paso es que realmente hagamos esto. Entonces creamos el hook usedebounce y lo usamos para guardar realmente a la persona. Así que abriré las salas de grupos durante otros cinco minutos para hacer esto. Y después de eso, echaremos un vistazo a cómo mejorar esto un poco. Aunque ya es bastante utilizable. Disculpenme.

Sí, adelante. ¿Vamos a hacer un descanso para tomar café o ir al baño en algún momento? Sí, lo haremos. A mitad de camino, haremos un descanso. Ya lo agregué en la ventana de chat. Oh, gracias. Alguien preguntó, tal vez ya lo hiciste. No estoy seguro. Fui yo. De acuerdo, respondí a eso, pero fue mientras estabas haciendo el ejercicio de laboratorio. Por eso probablemente no lo viste. Pero eso es cuando suelo responder a los mensajes de chat. De acuerdo, gracias. De acuerdo, nos vemos en cinco minutos.

De acuerdo, vamos a hacer que todos vuelvan. Así que mencioné que teníamos un pequeño problema o un problema potencial con el cambio o tener una nueva función que se pasa en useDebounce. Bueno, resulta que eso es relativamente fácil de solucionar y tenemos otro buen hook para hacer exactamente eso, que es useCallback. Entonces, useCallback es un hook especial utilizado para crear una función de devolución de llamada, que puede tomar algunas dependencias, pero nuevamente, crea una función estable si esas dependencias no cambian. Y actualmente en el code, si este objeto persona sigue siendo el mismo, pero el componente se vuelve a representar por alguna razón, todavía obtenemos una función completamente nueva aquí. Bueno, useCallback se encargará de eso. No voy a investigar por separado useMemo, pero useMemo es prácticamente lo mismo. useCallback se utiliza para crear una versión memorizada de una función de devolución de llamada. useMemo se utiliza para crear un valor memorizado de algún objeto o valor, un valor simple, algo así, pero típicamente objetos. Pero funcionan de la misma manera, solo son casos de uso ligeramente diferentes. Entonces, ¿cómo lo hacemos realmente? En lugar de simplemente llamar a use o useDebounce con una función estándar, voy a llamar a useCallback. Esto toma la función real que quiero llamar. También toma una matriz de dependencias, y por alguna razón aún no se queja de eso, lo cual es interesante. Esto devuelve una función de devolución de llamada memorizada. Entonces... Y pasamos eso aquí. Y ahora comienza a quejarse. Eso se debe a errores de compilación, supongo. Entonces, si digo actualizar la matriz de dependencias, dice, bueno, esto depende de ese objeto personal. Mientras se use el mismo objeto personal, esta referencia de función va a ser la misma. Y no tendremos problemas con el debounce sobre una función diferente con los mismos valores reales. Ahora, sería bueno si pudiéramos hacer eso dentro de useDebounce, y por supuesto, es un hook, así que no hay problema en llamar a useCallback allí. Pero si queremos hacer eso, tendríamos que llamar a esta función y todas sus dependencias, etc., allí. Y eso haría que esta llamada de función sea realmente compleja o que pierda el propósito. Así que eso realmente no funciona, tienes que usarlo de esta manera. Pero eso no es tan malo. Y en este caso, en realidad estoy creando una función diferente porque quiero reutilizarla más tarde en otro lugar, de lo contrario, simplemente la incluiría dentro de useDebounce. Así que hagamos ese pequeño cambio aquí. Puedes ver la versión en línea. Use throttle, puedes hacerlo de la misma manera que useDebounce. En realidad, no lo voy a hacer ahora, pero el code es un poco más complejo. De hecho, este use throttle está un poco roto porque debería borrar el intervalo actual. Esto seguirá disparándose incluso si ya no es necesario. Pero aparte de eso, es realmente, realmente simple. Pensé que íbamos a hacer esto primero, pero en realidad hagamos esto primero. Hagamos ese pequeño cambio y no empecemos a combinar demasiados cambios. Entonces, introduzcamos useCallback en la función useDebounce. Un cambio bastante pequeño, así que voy a abrir la sala de grupos durante dos minutos y luego, en dos minutos, en realidad vamos a solucionar otro problema que hemos introducido ahora, que te mostraré en un momento. Así que nos vemos en dos minutos.

Lo siento, ¿puedes repetir el razonamiento para usar useCallback en lugar de simplemente llamar a la función? Sí, por supuesto. Si miras dentro de la función useDebounce, puedes ver que este efecto depende de la función que se pasa. Y cada vez que esto cambia, cualquiera de estos dos valores cambia, este efecto se desmonta por lo que se llama a clearTimeout y se llama a setTimeout nuevamente con la nueva referencia de función. Ahora, si en línea una función aquí como teníamos antes, significa que cada vez que esto se ejecuta, se crea una nueva función, por lo que la referencia de función aquí es una nueva referencia de función cada vez. Entonces esta dependencia cambia cada vez. Incluso si el objeto persona actual que estamos tratando de guardar aún no ha cambiado. Se vuelve a representar por alguna otra razón. Tal vez haya un reloj que esté corriendo allí. Entonces, al usar useCallback, podemos decir, bueno, ahora obtenemos una función de devolución de llamada estable que solo depende del cambio del objeto persona. Si este componente al que se agrega esto se vuelve a representar por alguna otra razón, entonces el cambio de persona entonces Fn seguirá apuntando a la misma función y useDebounce no notará la diferencia. Pero cuando la persona cambie, obtendremos la nueva función. Y useDebounce se dará cuenta.

Entendido, gracias. ¿Puedes mostrarnos el code en ejecución? Me gustaría ver cómo se ejecuta, el efecto nuevamente. ¿La parte de useDebounce? Sí, sí, me gustaría verlo. Sí, déjame agregar algunos comentarios, console.logs aquí para que podamos ver comenzar useEffect. UseEffect así. Vamos a convertir esto en, no. Quiero el console.log, llamando a FN y aquí estamos haciendo clearTimeout. Usaremos el guardado. Entonces, si actualizo eso, déjame borrar todo. Ahora, si comienzo a escribir, verás que cada pulsación de tecla que hago, ves dos mensajes, clearTimeout, comenzando UseEffect. Y si hago una pausa por un momento, luego puedes ver que se guarda comp, va a llamar a la función y guarda. Genial, gracias. Sí, eso ayuda, está bien. Oh, podemos dejar eso. Ahora, déjame mostrarte una cosa que hemos roto ahora. Porque ahora, si estoy cambiando, en realidad no se guarda nada hasta que dejo de escribir y dejo de escribir durante un segundo. Entonces, si estoy eliminando esto y en realidad estoy navegando antes de llegar al tiempo de espera, verás que no hay mensaje de guardado. Entonces vuelvo a la persona y vemos a Frieda con todas esas cosas apagadas. Ahora se guarda de manera limpia, así que si me voy, vuelvo, tengo a Frieda, pero si comienzo a escribir un montón de unos, salgo del componente antes de que se guarde durante ese segundo de gracia. Vuelvo, hemos perdido nuestros cambios. Bueno, eso no es tan agradable, pero es un resultado de decir, bueno, queremos desactivar el guardado durante un segundo. Entonces, ¿cómo podemos solucionar eso? Bueno, bastante simple, usamos otro hook y creamos un hook simple para detectar el hecho de que vamos a desmontar el componente y hacer eso es realmente simple nuevamente usando useEffect. Entonces, vamos a, en realidad, solo escribir el code. Vamos a crear otro hook, useWillUnmount. Entonces, export function useWillUnmount. Toma la misma función de devolución de llamada que antes, que no devuelve nada.

Y aquí queremos ejecutar algo. Así que queremos hacerlo cuando hayamos terminado. Entonces queremos usar useEffect cuando el componente se desmonta es cuando queremos hacerlo. Así que pasamos un array de dependencias vacío, y luego no queremos hacer nada cuando se inicializa el efecto, pero cuando ocurre la limpieza, queremos hacer algo. Así que pasamos una función de limpieza. Y aquí queremos llamar a esa función de devolución de llamada. Volvemos aquí y decimos, también queremos usar el hook useWillUnmount, y pasar la misma función allí. Ahora, esto debería funcionar, aunque todavía está mal. Así que si empiezo a escribir y hago clic en React Hook para profesionales, en realidad vemos que hay un mensaje de guardado, pero dice guardando null, no el objeto que estaba editando. Así que supongo que funciona, pero no del todo. Entonces, ¿cuál es el problema con que no funcione? Bueno, las líneas onduladas aquí de la regla eslint me muestran el problema. Quiere algo arreglado y ¿qué quiere? Bueno, en realidad quiere que esa función se pase como una referencia. Pero si hago esto, significa que cada vez que se crea una nueva función, empezamos a ejecutarla, o ejecutamos la anterior como resultado de la limpieza. Así que si vuelvo aquí y empiezo a escribir, ves que estamos guardando de nuevo en cada pulsación de tecla, lo cual no queremos. Así que no queremos usar esto como una dependencia. Bueno, ya usamos otro hook. Podemos mantener el estado durante la vida útil de un componente sin que afecte a nuestros use effects etc. Que era useRef. Así que podemos decir, bueno, vamos a llamar a useRef. Vamos a pasar esa función y guardarla de esa manera. functionRef es y aquí en lugar de llamar a fn, llamamos a fn.Current. Porque ahora en realidad todavía se queja de algo. Porque al igual que el estado, este parámetro. En realidad, solo se usa para la primera vez. No en ningún momento después. Así que para capturar el último. función que se pasa. Tengo que añadir esto fnRef.Current es fn. Así que ahora. Cada vez que se llama a este hook guardamos una referencia a la función y solo una vez que se desmonta. En realidad llamamos a esa función. Así que otro uso para useRef, que no tiene nada que ver con su intención original. Obtener una referencia a un objeto DOM, pero donde todavía es realmente bien, realmente fácil de hacer. Así que veamos si funciona ahora. Empiezo a escribir ninguna acción de guardar, pero me voy. Y tan pronto como dejo el componente, se desmonta. En realidad guarda y volvemos allí y todos los valores que tenemos se mantienen. Así que, bastante simple y aún así un hook bastante útil para tener a mano. Nos da el ciclo de vida del componente se desmontará que tenemos en los componentes basados en clases, pero ahora en un hook.

Vale. Verás, esto se está añadiendo a los componentes que ya hice, así que no hay nada que hacer allí. Así que por favor añade el hook de desmontaje habitual. Así que un cambio bastante pequeño pero un poco más grande que el anterior. Así que voy a abrir las salas de breakout por cuatro minutos y en cuatro minutos, nos vemos a todos aquí.

Vale, creo que ya han vuelto todos. Una pregunta rápida, Maurice. Sí, adelante. ¿Puede esta implementación de will unmount ser más generalizada? Quiero decir, para poder usarla en toda la aplicación. Así que no sólo para esta función de rebote. Así que tenemos aquí todo el hook de desmontaje está recibiendo una función. ¿Podemos usar esto para cualquier cosa o sólo para campos de entrada? No, puedes usar esto para cualquier cosa. No está vinculado a los campos de entrada. No está vinculado al uso de rebote para el caso. Es sólo un hook independiente. Le pasas alguna función de callback y ejecutará la última función de callback pasada cuando los componentes con los que está asociado se desmonten.

Vale, así que tengo problemas para entender ¿cómo sabe que el componente se desmontará? Use effect se lo dice. Así que, use effect aquí toma un array de dependencias, que está vacío. Y si está vacío, entonces los efectos de uso se inicializan justo después de que los componentes se monten por primera vez. Debido a las dependencias vacías, nunca se vuelve a inicializar, pero se desmonta cuando se desmonta el componente. El componente al que pertenece. Así que esto es un comienzo un poco, que es nada, no hacer nada. La función de retorno es la parte de limpieza, que dice, vale, simplemente ejecutaremos cualquier función que se haya pasado. Y ejecutará la función anterior que hayas recibido, así que sí, ahora lo entiendo. Así que no está vinculado al uso de rebote, es completamente independiente. Puedes usar esto donde quieras con cualquier componente que quieras o en cualquier otro hook que quieras. La pregunta principal era, ¿cómo sabe que se desmontará? Porque supuse que tenía algo que ver con el rebote o lo que sea la implementación anterior, pero entiendo que el hecho de usar el usuario realmente se lo dice. Sí. Los hechos del usuario se lo dicen, eso ya es más viejo, lo que hace que estos hooks sean tan agradables. Son tan agradables y pequeños y autocontenidos y simplemente hacen cosas. Así que estamos a mitad de camino. Lo siguiente que quiero hacer es echar un vistazo a las reglas de los hooks y qué pasa realmente si empiezas a romperlas y por qué son como son. Pero primero vamos a hacer una pequeña pausa. Hagamos un descanso de café de 10 minutos y volvamos todos aquí en 10 minutos. De hecho, voy a empezar un pequeño temporizador de cuenta atrás para que puedas ver que estoy contando y nos vemos a todos aquí en 10 minutos.

Bien, todos de vuelta del descanso. Así que quería echar un vistazo a las reglas de los hooks. ¿Por qué las tenemos? ¿Y qué sucede si realmente las rompes? Porque eso nos dirá bastante sobre cómo funcionan los hooks bajo el capó y por qué son como son, lo cual puede ser bastante útil saber. Así que las reglas para los hooks son realmente bastante simples. Si quieres llamar a una función hook, tiene que estar dentro de otro hook o desde un componente de React, así que esos dos son los únicos lugares donde puedes llamar a un hook. Entonces, nuestros componentes de React, el editor de personas, podría llamar a un hook personalizado usePerson, que podría llamar a useEffect y useDebounce, que llama a useEffect de nuevo. Todo eso está bien, pero en alguna otra función, no puedes llamar a un hook. Así que eso es simple. La otra regla es, no puedes llamar a los hooks desde bucles, o condicionales, o ese tipo de lugares. Eso es realmente interesante. Y veamos qué sucede si no te ciñes a eso. Tengo otra página aquí. Y veamos realmente qué sucede. Realmente quiero mantener esto abierto. Veamos qué sucede si no nos ciñimos a eso. Y hay un pequeño botón de incremento. Y ahora todo está bien. No estoy haciendo nada extraño. Así que hago clic en incrementos, el contador se incrementa. No hay problema. Funciona exactamente como esperarías. Al menos eso espero. Entonces, ¿cómo se ve realmente el code? Y busquemos los componentes. Ahí, contador. Solo tiene un simple, you state, comienza con cero. Y luego cada vez que hacemos clic, llamamos a la función setter, set counter aquí incrementa el conteo en uno. Simple. Sin condicionales, nada. Y eso funciona perfectamente bien. Así que cambiemos eso. Introduzcamos un bucle. Básicamente tienes un pequeño bucle for donde estoy recorriendo hasta la cantidad de contador y creando otro use state. Ahora no estoy haciendo nada con el resultado. Solo estoy llamando a use state con un valor inicial. El valor real tampoco importa. Asegúrate de que esto se refresque y esté limpio. Y pulsemos incremento. Ahora, de repente estamos mirando la gran pantalla blanca, lo que significa que algo salió mal. Y si miramos en console, podemos ver realmente qué salió mal. React ha detectado un cambio en el orden de los hooks llamados por el contador. Y luego realmente enumera los hooks que detectó. Entonces el renderizado anterior, que fue el primero, dice, bueno, se llamó a un hook use state y no se llamó a un segundo hook. Y el siguiente renderizado, dice, bueno, hubo un use state y luego otro use state. Bueno, el primero está bien, use state, use state. Pero el segundo significa que pasamos de tener un hook a tener dos. Eso no está bien. Así que dice aquí que esto llevará a bugs y errores si no se arregla. Eso también sucederá si empiezas a cambiar los hooks. Déjame descomentar el segundo bit. Entonces, de nuevo, tengo diferentes hooks. Comenzamos con ese hook inicial use state que está bien, y luego dependiendo de si el contador es par o impar, estamos agregando un segundo use ref o hook use state. Así que borremos todo esto, así que estamos en una situación limpia. Pulsemos incrementos, y vemos exactamente lo mismo suceder. Oop, quería hacer zoom aquí. El mismo tipo de mensaje de error, pero ahora dice el primer renderizado fue primero un use state, luego un use ref, y el siguiente renderizado fue use state, luego use state. No siempre obtendrás un error como este, pero es bastante probable que suceda si haces algo mal como esto. ¿Pero cuándo no lo obtendrás? Supongamos que uso dos use refs aquí. Quería convertir esto en use ref. Por ejemplo, cambio esto a falso. No se va a quejar tan fuerte ahora. Puedo pulsar incremento, y en realidad no está contento, pero está más o menos contento. ¿Por qué no se queja? Bueno, no detecta que estos son dos use refs diferentes, porque son del mismo tipo. Si hice use effects, ambos, o use state en ambos, tampoco se habría quejado. Tengo dos valores iniciales aquí, verdadero y falso. ¿Cuál se usará? Bueno, eso realmente depende de cuál se ejecute primero. Entonces, en este caso, estamos comenzando con el valor cero, así que va a comenzar con use ref verdadero, así que verdadero va a ser el valor inicial, y este falso nunca se va a usar en absoluto. No se queja aquí, pero esto sigue siendo malo. Todavía va a llevar a problemas, así que voy a deshacer esto, y mantenerlo así, y comentarlo de nuevo. Es malo. Ahora, ¿por qué es tan malo esto? Veamos el error una vez más. Resulta que estos números tienen mucho que ver con la forma en que React está implementado internamente. La forma en que debes pensar en los hooks es que son cosas de estado incluso si a veces no parecen ser de estado, que están ligadas al ciclo de vida del componente propietario. ¿Qué es el componente propietario? Bueno, ese es el componente que primero comienza todo. Entonces, en este caso tengo un componente aquí, Counter. Crea hooks useState, useRef, useState de nuevo, etc. Posee lo que sean estos. Si estos son hooks personalizados y comienzan a hacer useState o useRef, etc., sigue siendo este componente Counter el que posee el estado de todos esos hooks. Ahora, ¿cómo funciona eso bajo los hooks? Es sorprendentemente simple. Lo que hace React, rastrea las llamadas a los hooks. Entonces, básicamente dice, bueno, el primer hook que se llama hace algo. Necesita mantener un estado específicamente aquí porque es el hook useState. Devolverá o conseguirá un lugar para almacenar ese estado como el primer hook que se llama. Luego tenemos otro hook que se llama. Hagámoslo de la manera en que realmente es correcto. Como esto y no roto. Entonces, este es el segundo hook que se llama, obtendrá la segunda ranura en el espacio de almacenamiento para guardar eso. Ahora, ¿cómo podemos ver eso en acción? Bueno, podríamos empezar a sumergirnos en el código fuente de React. Es relativamente fácil de entender. El código fuente de React no es fácil de entender. Es bastante complejo, altamente optimizado.

Especialmente si eres nuevo en esto, es realmente difícil de entender. Para ser honesto, no entiendo la mayor parte de lo que está sucediendo allí. Pero cuando me sumergí en los hooks y cómo funcionan bajo el capó, en realidad fue sorprendentemente simple. Permíteme deshacerme de todo esto por un momento. Permíteme mostrarte cómo funciona eso.

Componentes, hooks explicados aquí. Aquí tengo algo así. Se llama fake React porque eso es lo que es. No es React, no funciona realmente de la forma en que lo hace React, pero es una simplificación de lo que hace. Um, en realidad, ese no es el... Sí, ese es el que quería. Así que creo componentes como lo hago en React, excepto que solo me importan los hooks. Así que dejé fuera todo el JSX. Así que tengo un componente de aplicación aquí, pero en lugar de devolver JSX, simplemente devuelve una matriz de componentes secundarios. Simplificado de esa manera, pero aún así la misma estructura lógica allí. ¿Cómo se ven estos? Veamos. Eso no funciona. Contador. Bueno, esto se parece a un componente React normal. Nuevamente, ignora la parte de retorno, pero vemos que es un componente funcional. Utiliza el hook useState, tiene un valor inicial y cambia las cosas en función del valor. Básicamente, el contador simple, el primer hook de estado, sigue aumentando en uno hasta que alcanza el valor de 16, y ese es uno de mis gatos que quiere unirse a la conversación, lo siento por eso. Luego, si su valor es 12, básicamente dice, está bien, tomaré el contador al cuadrado, por lo que el segundo useState lo cuadrará, y una vez que llegue a 14, volverá a hacer lo mismo. Y en realidad imprime esos valores también. Y justo en la parte inferior, puedes ver que devuelve una matriz vacía, no tiene componentes secundarios. Entonces, lo otro en el componente de la aplicación fue que renderiza a Arthurdent y a un componente ZaevoldBiebelbrocks. Bueno, ambos son instancias de un componente saludo que utiliza un nombre inicial diferente. Y nuevamente, utilizan setState. Y en el caso de ZaevoldBiebelbrocks, en realidad dice, bueno, si soy, cambiaré mi nombre a forPrefect. Y Arthurdent simplemente dice, bueno, no importa, me quedaré como Arthurdent. Y ambos imprimen su nombre inicial y su nombre actual. Ahora, ¿cómo funciona esto realmente cuando lo ejecuto? ¿Añadí un script para esto o no? ¿Dónde están mis scripts? No, no lo hice. Así que simplemente los ejecutemos con Node. ¿Cuál era la carpeta? elsewhere.index.js Así que básicamente puedes ver que los componentes se renderizan. Así que tenemos el primer ciclo de renderizado donde Arthur Dent se renderiza, Seyfold Biebelbrox se renderiza, y el contador se renderiza con Simple y Square en 10. Luego ves que Arthur Dent se queda como Arthur Dent, pero Seyfold Biebelbrox en realidad se ha cambiado el nombre a four prefix y vemos que ese contador Simple comienza a aumentar a 11, Square se mantiene en 10, y Simple es 12, y Square comenzará a actualizarse. Así que si hago zoom de nuevo, obtendremos todos los valores actualizados. Aquí puedes ver que el contador Simple ha llegado a 13 y el Square ha llegado a 100 y ese Square se ha vuelto a cuadrar, justo ahí. Ahora, ¿cómo se vería eso realmente bajo el capó? ¿Cómo se ve algo como useState en realidad? Así que eso sale de este fake React. Y la función useState es en realidad bastante simple. Dice, bien, monta algún trabajo en progreso con el estado inicial que se pasa y eso obtiene un objeto hook. Y resulta que hay algo llamado estado memoizado en eso. Y crea una función donde realmente podemos modificar el estado memoizado. Y si se ha llamado a eso, establece esta pequeña bandera de re-renderizado, lo que significa, bien, se ha cambiado algún estado, necesitamos volver a renderizar. Y luego simplemente devuelve eso. Así que bastante simple. El useState real es un poco más complejo, pero no mucho más. Así que comienza renderizando componentes. Bueno, ¿cómo funciona eso? Bueno, en primer lugar, establece la bandera de re-renderizado en falso porque asumimos que todo se está renderizando después de que se haya hecho este render component. Pero si hubo algún tipo de llamada a setState, entonces estoy usando un setTimeout aquí para volver a renderizar todo de nuevo. Así que básicamente estamos recorriendo el estado equivalente, así que básicamente estamos volviendo a entrar en esta función, estableciendo render en falso, renderizando todos los componentes y comprobando si hubo otro cambio. Así que la API pública, que en este caso es un hook y una función de renderizado, es bastante simple.

Ahora, ¿de dónde obtiene realmente ese montaje de trabajo en progreso? ¿Cómo lo obtiene realmente? Así que no quería cubrir eso, como este código, así. Aquí comienza a buscar en una matriz. Así que hay un objeto llamado currently rendering fiber que se configura de alguna manera. Mostraré cómo se configuró en un momento. Y eso contiene una matriz de estado de hook y tenemos este índice donde indexamos en eso para obtener el hook actual. Genial. Básicamente, eso significa que debido a este índice, el primer useState obtiene la primera ranura cero, el segundo obtiene la ranura uno, etc. Y solo he implementado useState aquí, pero con diferentes hooks, es solo cuestión de incrementar ese índice y almacenar el estado apropiado para ese tipo de hook. Cada vez que hacemos esto, en realidad incrementamos ese hook. Así que la próxima vez que llamemos a mount work in progress hook, obtendremos el siguiente hook con su estado. Ahora, por supuesto, es posible que obtengas un hook que no sea la primera vez, la primera vez no hay nada allí. Así que la primera vez creamos un nuevo estado, tomamos ese estado inicial, lo almacenamos en ese estado memoizado que vimos antes y lo almacenamos en ese estado de hook de currently rendering Fiber. Así es como se mantiene el estado en esta matriz. Ahora, en el verdadero React, eso no es una matriz. En realidad, es una lista enlazada. Usé una matriz porque es un poco más simple, pero es prácticamente el mismo efecto. Recorren la lista enlazada y hacen lo mismo. ¿De dónde viene este currently rendering fiber? Bueno, en ese caso tenemos que empezar a mirar render components. Porque ¿dónde comienza? Bueno, renderiza un componente cuando se llama al componente, comenzará a llamar a los hooks. Así que React realmente utiliza ese flujo diciendo, bueno, en este caso, se nos llama a render con hooks. Así que tenemos una instancia de componente para la función render con hooks. Encontramos ese objeto currently rendering fiber buscando work in progress nuevamente en función de ese componente. Y ese componente llama a algún tipo de colección de trabajo en progreso para componente. Y resulta que al menos en mi implementación, eso es solo un mapa débil donde la instancia del componente es una clave. El valor que realmente se almacena en él es el estado del componente. Así que esto está muy vinculado a la instancia de un componente, si el componente sale del ámbito, entonces la referencia débil recogerá la basura y se recogerá el estado asociado con él. Nuevamente, la implementación real de React es un poco más compleja que eso, pero no mucho, no utiliza los mismos componentes, no utiliza un mapa débil como este. Utiliza cosas un poco más complejas, pero el flujo principal es el mismo. Y si comienzas a mirarlo y miras el código, realmente verás un objeto llamado currently rendering fiber. Y realmente verás un estado de componente como este que tiene, bueno, no una matriz de estado de hook, pero tendrá una lista enlazada en su interior. Por lo tanto, encontrarás prácticamente todo esto igual con memoIState para mantenerlo simple hice algunos cambios pero mantuve la mayoría de estos nombres igual que estaban en el código real de React. Resulta que en 81 líneas de código, incluso con algunos comentarios, bueno, no muy útiles, pero algunos comentarios, he creado la versión simulada simple de prueba de concepto de los hooks de React con el hook useState. Quiero agregar useEffect. Bueno, en realidad es bastante simple. Agrega useEffect aquí, la implementación, esta parte será diferente pero el resto de las cosas, mount work in progress hook, obtener el hook real, etc., sería lo mismo. Lo que se almacena allí, por supuesto, no sería memoIState, porque eso es para el hook setState. Pero sería bastante trivial de agregar. Así es como funcionan los hooks de React bajo el capó, lo cual es bastante útil.

Entonces, ¿qué hay de los estados más complejos? Hasta ahora hemos utilizado useState. Y en nuestro ejemplo, volvamos a ese ejemplo. usePerson. Aquí, usar useState está bien, porque no estamos haciendo cosas muy complejas con el estado y no hay mucho de qué preocuparse, ni ninguna razón para complicarlo más. Pero hay casos en los que sí lo necesitarás. Y uno de ellos podría ser cuando comienzas a almacenar múltiples piezas de estado relacionadas, que tal vez no estén completamente relacionadas, como un objeto de persona y algo más, pero están vinculadas entre sí. Y eso podría ser que estés almacenando un objeto personal, pero también quieres almacenar el estado de un formulario, como ¿es válido el formulario? ¿Está sucio el formulario? ¿Ha sido modificado o no? No es parte del objeto de persona, por lo que no debería ir allí, pero de alguna manera pertenece juntos. Un cambio en la persona afectará a ese estado sucio y potencialmente también al estado válido.

Bueno, podrías hacerlo de esta manera, agregando múltiples hooks useState. Y en este caso es relativamente simple, y podríamos salirnos con la nuestra haciéndolo de esa manera. Y podríamos hacer algo como esto, donde la persona, el conjunto de persona o la función que exponemos, en realidad no es la función original de establecimiento de estado de persona, sino una que es un poco más compleja y que cambia múltiples piezas de estado. Funciona. Y en este caso, es lo suficientemente simple como para salirse con la nuestra. Pero si tu escenario se vuelve más complejo, será más difícil mantener esas diferentes piezas de estado y trabajar con ellas. Insights son un componente. Todavía usamos ese mismo use-person. Este set person es una función diferente, una implementación bastante diferente, pero nunca necesita darse cuenta. Y ahora, de repente, obtiene información adicional, como en este caso, está sucio, por lo que podemos deshabilitar el botón de envío, por ejemplo, si el formulario no está sucio y potencialmente si no es válido o algo así. Así que podríamos hacer algo así. Eso está perfectamente bien. Y en realidad vamos a omitir esta parte del laboratorio porque estamos un poco atrasados en el esquema, lo haremos de una manera diferente, y eso es usando useReducer.

Entonces, bajo el capó, useState es en realidad un caso especial de useReducer. Ahora, si piensas en useReducer, espera, he usado Redux que usa reductores, ¿verdad? Bueno, tienes razón, y useReducer es muy similar a usar algo como Redux. No es lo mismo, no es tan poderoso como Redux, pero utiliza exactamente los mismos principios. Y resulta que, si comienzas a mirar el código fuente de React, useState es solo un caso especial con un reductor especial, con otro capó, simplemente llama a useReducer. Entonces, si miras la implementación real de los hooks, no hay un hook real useState, que se administra, es solo un pequeño envoltorio alrededor de useReducer, y useReducer es en realidad el único hook realmente con estado que administra componentes y desencadena re-renderizaciones. Ahora, ¿cómo se usa useReducer? En realidad es bastante simple de usar. Llamas a useReducer con una función reductora. Una función reductora, al igual que con Redux, es una función que toma dos argumentos. El estado actual y la acción actual que se está despachando. ¿Cómo se despacha una función? Bueno, useReducer devuelve una tupla, al igual que useState, excepto que con useState, la segunda función es una función simple que toma un nuevo estado o una función de mutación de estado. En este caso, obtienes una función de despacho y ahí puedes comenzar a despachar acciones. El primer argumento que devuelve, la primera parte de la tupla, sigue siendo el estado actual. Entonces, ya sea useState, useReducer, no importa, sigue siendo el estado actual. Aunque useReducer, ese estado suele ser más complejo, pero no es necesario que lo sea. Y aún está vinculado a un componente. Redux es similar en estructura a Redux, pero Redux es una gestión global de estado que se elimina de tu componente y diferentes componentes pueden compartir el mismo estado suscribiéndose a él mediante useSelector o algo así. Pero con useReducer, todavía está muy vinculado a un solo componente. Si comienzas a usar context y useReducer, en realidad puedes crear una especie de Redux ligero. No lo aconsejaría. Todavía recomendaría usar Redux si quieres hacer eso. Ahora, si quieres hacer eso, lo primero que debes hacer es crear un reductor. Y esta es la primera parte de ese reductor, que es solo un montón de declaraciones que necesitamos. Y la implementación real está aquí. Tenemos una función, PersonEditorReducer. Toma dos parámetros, el estado y la acción. El estado es lo que necesita ser para este useReducer. La acción es típicamente un objeto con un tipo y opcionalmente una carga útil. Por lo general, tiene una carga útil, pero no todas las acciones la necesitan. Y el tipo generalmente decide qué es. Entonces, en este caso, tenemos un tipo de set initial person, que carga un objeto personal, que se almacena en la carga útil. Y tenemos la acción set property, que realmente cambia la persona usando la carga útil, que tiene un nombre y el valor real. Y todo el código en el medio aquí es porque la persona podría ser nula. Entonces, si comenzamos a extender la persona como nula, obtendríamos una persona parcial y TypeScript no le gusta eso. De esta manera, lo solucionamos. Vamos a omitir esto porque en la siguiente parte, vamos a crear otro reductor. No es necesario crear un segundo. Solo voy a explicar esta parte. Dentro de nuestro gancho usePerson o gancho personalizado, en lugar de useState, ahora vamos a usar useReducer y pasamos esa función reductora, que encontramos. Y aquí hay una diferencia con Redux, normalmente configuras tu estado inicial usando la primera llamada al reductor donde el estado es indefinido. En este caso, el segundo argumento para useReducer es en realidad tu estado inicial. Entonces pasamos el objeto. Tiene una persona en ese estado, que por defecto es nulo. Hay un estado de formulario, que por defecto no está sucio y es válido. Entonces, esto configura eso. Devuelve el estado que tiene esta persona en el estado del formulario, y tiene un despacho donde podemos despachar una de esas acciones. Luego, para despachar algo, hacemos algo como esto. En lugar de exportar un objeto setPerson, ahora establecemos, exportamos un setProperty. Y en setProperty, decimos, bueno, queremos despachar algo en este caso, un tipo de setProperty y la carga útil con el nombre y el valor. Y lo mismo sucede, pero eso está un poco fuera de la pantalla ahora, con el despacho setInitialPerson. Ahora, si estás acostumbrado a JavaScript y Redux, es posible que estés acostumbrado a tener creadores de acciones aquí, no despachando objetos como este. Si estás usando JavaScript con useReducer, te recomendaría que hagas exactamente lo mismo. Con TypeScript, realmente no tienes que hacerlo, porque si cometo un error tipográfico aquí en setProperty, en realidad comenzará a quejarse porque el tipo está definido como uno de estos tipos conocidos. Si vuelvo por un segundo aquí con los diferentes tipos, los he establecido ligeramente más abajo. Dos acciones diferentes. Un tipo de setInitialPerson y un tipo de setProperty con su carga útil asociada. Y la acción que espero es una acción setPerson o una acción setProperty. Entonces, si intento despachar un objeto con el tipo, digamos foo, entonces dirá, bueno, foo no es un tipo conocido aquí. Realmente debe ser una de estas dos cadenas exactas. Y una vez que sabe cuál de esas dos es, en realidad conoce la forma de la carga útil. Entonces, si intento despachar setInitialPayload con la forma de la carga útil de setProperty, volveré a obtener un error de compilación de TypeScript que dice, bueno, no coincide. Esa no es una acción adecuada. Debería ser esta forma o esta forma, no alguna combinación o algo más que no coincida con eso. Entonces, TypeScript realmente simplifica casos como ese. Aquí, puedes ver el otro despacho para setInitialPerson. Como dije, vamos a omitir esta parte. En realidad vamos a hacer esto con la segunda parte donde creamos el clon de Foramic. Nuestros componentes han cambiado ligeramente. En lugar de setPerson aquí, obtenemos un setProperty.

En la segunda parte de esta masterclass, vamos a combinar todos los diferentes hooks en algo más avanzado. Crearemos un componente proveedor que mantenga el estado y proporcione valores a diferentes partes del sistema. Tendremos un objeto de contexto de React para definir cómo el proveedor hace que las cosas estén disponibles para los hijos. También crearemos diferentes hooks, incluyendo uno para el formulario y otro para los campos de entrada. Comenzaremos construyendo el contexto creando un objeto de contexto usando la función createContext de React. Definiremos los valores iniciales y exportaremos el contexto y los tipos de interfaz. Luego, usaremos el proveedor de contexto para proporcionar los valores a otros componentes. El valor proporcionado será de tipo kimRofContext, que incluye una propiedad de valores.

Y en el onChanged, llamamos a setProperty, diciendo, bueno, queremos cambiar la propiedad firstName a esto, y queremos cambiar el apellido a este valor, etc. Y nuestro reductor se encargará de eso, y también se encargará de establecer la propiedad dirty. Y no hay una validación real en este código, pero suponiendo que hubiera validación, se encargaría de ejecutarla y establecer la propiedad isValid, etc.

Entonces, bastante simple de usar, y lo haremos en un segundo. Así que cierro todos estos, porque ya no vamos a usar este ejemplo. También hago push o stageStatChange, porque en la segunda parte de esta masterclass, en realidad vamos a combinar todos los diferentes hooks en algo más avanzado, donde combinamos diferentes funcionalidades en algo útil. Y lo que quiero combinar es Formlink, o al menos lo mencioné, un clon simplificado de Formlink. Formlink es realmente útil si quieres hacer formularios sobre datos, y si piensas en un editor como este, realmente son formularios sobre datos. Tenemos algún formulario y presumiblemente esto volverá al servidor y se almacenará allí y luego se servirá nuevamente en algún otro lugar. Y aparentemente no reinicié la aplicación. Hagámoslo para que funcione de nuevo. Así que, funcionando de nuevo.

Ahora, tengo esta demostración donde vamos a hacer lo mismo de una manera similar a Formik. Renderiza un formulario, pero aún no hay valores, no hay gestión de estado ni nada. Y solo para mostrarte por qué me gusta tanto Formik, vamos a cerrar estos. Gitmore de Person Editor. Si creas un formulario de entrada como este y tienes tus componentes de entrada configurados, entonces todo el formulario podría ser tan simple como esto. Donde básicamente dices, bueno, ve y renderiza algún componente y el nombre aquí realmente se enlaza a un objeto subyacente. Entonces hay un objeto persona con una propiedad de nombre. Tener el nombre significa que obtiene el primer nombre de ese objeto y lo actualiza cada vez que haces cambios. Pero como mencioné, este es un ejemplo simplificado. No podrás hacer todo lo que puedes hacer con Formik. Con Formik, en realidad podrías tener algo como persona.nombre en aquí, o incluso con matrices y recorrer cosas, etc. Muy poderoso, muy fácil de usar. Voy a mantener esto mucho más simple, pero aún mostraré cómo hacerlo. Nos enfocaremos más en cómo funcionan juntos los diferentes hooks.

Entonces, la arquitectura que vamos a seguir se verá algo así. Crearemos un componente proveedor que mantenga los estados y proporcione diferentes valores a diferentes partes de todo el sistema. Tendremos useReducer allí para rastrear el estado y hacer actualizaciones allí. Tendremos un objeto de contexto de React, que en realidad hará que las cosas del proveedor estén disponibles o definirá cómo el proveedor debe hacer que las cosas estén disponibles para los hijos. Tendremos diferentes hooks. Aquí hay dos, pero en realidad crearemos más. Crearemos tres. Hay uno para el formulario, que mantiene las cosas que queremos agregar a un formulario. Como el hecho de que se haya enviado. Tendremos un useFieldHook, que mantendrá las cosas para los campos de entrada, que toma el nombre con el que queremos enlazar y luego devuelve cosas como el valor y el controlador onChanged o onChange, debería decir. Y eso llama al proveedor, al useReducer con un despacho, actualizando el estado, haciendo que las cosas se vuelvan a renderizar, etc. Entonces, ¿cómo comenzaríamos a construir eso? Ya tengo algunos componentes aquí. Tenemos un editor de persona, que dejaremos prácticamente como está por ahora. Lo actualizaremos al final, pero en su mayor parte no necesitaremos hacer cambios en él. Tengo un componente envoltorio, KimrovPersonEditor, y por cierto, si te preguntas por Kimrov, es para micrófono, pero al revés, eso es realmente lo que invertí aquí. Ahora mismo realmente no agrega nada. Comenzaremos a agregar un poco más, pero no mucho. Aquí hay una carpeta Kimrov, y hay un montón de archivos aquí que en su mayoría están vacíos. Como hay un gancho de campo Kimrov usado aquí, pero en realidad aún no hay nada aquí. Así que comenzaremos a agregar cosas allí. Hay un KimrovContexto, cosas así, nada aquí. Un componente Kimrov, que será el proveedor real, que actualmente no hace nada más que renderizar los hijos. Así que eso es lo que vamos a implementar para obtener una solución de trabajo más compleja. El corazón latiente es el contexto y proporcionar algún valor. Así que eso es lo primero que debemos hacer, porque si no lo tenemos, las diferentes partes no pueden comunicarse entre sí. Porque el contexto define qué está disponible y el proveedor realmente hace que las cosas estén disponibles. Por lo tanto, crear un contexto no tiene nada que ver con los hooks en sí. Es realmente simple. Llamas a createContext de React, crea un objeto de contexto y he especificado el tipo real aquí, que es útil hacer. Y comenzaremos con algo realmente simple y un objeto de valores vacío. Así que agreguemos eso. Así que tengo este archivo, kimRofContext. Creamos un objeto kimRofContext con una O en minúscula, es createContext. Y recuerda, no estamos usando un hook de contexto, sino que createContext es solo una función estándar de createContext de React. Usaremos el gancho para recuperar este contexto más adelante. Necesitaremos definir un tipo para esto. Así que creamos una interfaz, y usamos una K mayúscula allí porque es un tipo. Y diremos que tendremos una colección de valores aquí, que es un tipo objeto kimRof. Ya he definido algunos tipos y creado algunos tipos. No es un taller de TypeScript aquí, así que no necesito hacer todo eso. Se proporcionan. El tipo que queremos no es objeto kimRof, sino kimRofContext. Y de inmediato obtenemos una advertencia de compilación que dice, bueno, eso es inválido porque falta valores. Así que configuramos un objeto de valores iniciales como una matriz vacía. Necesitaremos usar tanto esta interfaz como este objeto de contexto en diferentes lugares. Así que comenzaremos exportándolos a ambos. Y lo siguiente que debemos hacer es, en función de este objeto de contexto, comenzar a proporcionar sus valores a otros lugares. Aquí puedo usar use kimroffcontext.provider. Entonces, cada contexto de React tiene un proveedor, consumidor, etc. No vamos a usar el consumidor, pero usaremos el proveedor. Aún tiene un error de compilación que dice que falta la propiedad value. Y el valor es lo que realmente proporcionas para los hijos. Entonces, cada vez que usas el contexto, el gancho para recuperar el valor que se proporciona, lo que sea que se empuje aquí es lo que realmente obtienes. Así que queremos que sea de esta forma. Así que creemos el contexto aquí. Úsalo primero y luego defínelo. Será una forma de proveedor de contexto. Necesito resolver eso, y eso debe tener una propiedad de valores. Necesitamos obtener ese valor de algún lugar. Queremos obtenerlo como un problema aquí, así que. Quien sea, si puedo escribir value. Quien sea que esté proporcionando esto puede proporcionarlo. Así que eso será de tipo un objeto más.

¿Por qué esto, si convertimos el en una persona de dos o una paracluseball no funciona intellisense, porque estoy en el lugar equivocado. Debería estar agregando eso aquí con el tipo. Y este será realmente el valor. Así que esto compila bien, pero ahora todavía necesitamos usarlo. ¿Dónde está mi formulario? Así que este editor necesita ser envuelto dentro de ese proveedor de contexto. Así. Y ahora eso dice, está bien, pero quiero ese valor inicial en el que tengo un error tipográfico, pero eso no va a ser demasiado problema. Y resulta que ya tengo los tipos allí. Así que esta es la misma persona inicial que usamos antes, pero tengo que causarlo como el tipo correcto. Así que eso es solo para mantener a TypeScript contento. Si dejara eso fuera, diría que la persona inicial no es exactamente el tipo correcto. Así que ahora todo debería compilar. Y si actualizo, todo debería estar bien. No hay errores de compilación, nada. Aún no vemos ningún valor porque acabamos de conectar lo básico. Necesitamos hacer un poco más de trabajo antes de eso. En realidad vamos a hacer eso el próximo paso, pero por ahora hagamos este paso y asegurémonos de que esto funcione. Así que voy a abrir la sala de breakout durante 10 minutos para hacer esto. Y luego después de los 10 minutos, haremos el próximo paso donde en realidad vamos a hacer visibles los diferentes valores. Así que déjame cambiar el tiempo en la sala de breakout a 10 minutos. Y luego, a menos que haya alguna pregunta, las abriré. No hay preguntas. Y nos vemos todos en 10 minutos.

Así que hemos dado un paso inicial. Aún no hemos usado un solo hook para esto, pero lo haremos ahora mismo porque el próximo paso que vamos a hacer es hacer visibles los valores actuales. Así que ahora mismo en el editor, nombre, apellido, etc., todos están vacíos. Puedo actualizar y no aparece nada. Bueno, eso es lo primero que vamos a hacer, hacer visibles esos valores. Y tenemos un contexto que contiene los valores. No pueden cambiarlo, lo haremos más tarde. Pero los valores iniciales están ahí. Justo como lo harías. Y tenemos un componente aquí que Gimruf labeled field, que va a renderizarlos. Así que hay un nombre en esta prop, en realidad lo hice obligatorio. Supongamos que dejé el nombre aquí, lo eliminé. En realidad obtengo un error de compilación allí. Así que, sé que tengo un nombre, de alguna manera aquí en realidad quiero obtener ese valor. Bueno, si tenemos un contexto y queremos obtener algo de ese contexto, podemos usar un hook. Y para hacerlo reutilizable, no quiero poner ese code aquí, en realidad quiero poner eso dentro de otro hook personalizado que puedo reutilizar para diferentes componentes de entrada. Así que, tengo un marcador de posición, use Kimroff field. Y en realidad voy a crear otro hook personalizado aquí. Export function. Use Kimroff fields. Tomará el nombre que queremos como entrada obligatoria. Y va a devolver un objeto. Y por ahora queremos el valor ahí, así que. Vamos a codificarlo en uno, dos, tres por un momento. Ahora puedo ir a, ya no tengo eso abierto, de vuelta aquí, puedo decir que quiero usar este campo, pasar el nombre actual. Así que, props dots name. Eso me devolverá un objeto. Y eso es básicamente las props adicionales que quiero propagar en esa entrada. En este caso solo hay un valor todavía, pero habrá más. Así que, props de entrada, o props de campo, como quieras llamarlos. Props de entrada. Y vemos 1, 2, 3 en todos los campos. Todavía 1, 2, 3 porque básicamente está codificado. ¿Y dónde estaba mi hook? Justo aquí. Entonces, ¿cómo obtenemos el valor real? Bueno, tenemos esos objetos de contexto. Así que, con useContext, podemos obtener el valor proporcionado real. Así que, parse en Kimmer de contexto... y const. Obtenemos un objeto de allí, y en este caso, solo estamos interesados, al menos por ahora, en los valores. Así que, los valores son todos los valores iniciales que se pasaron. Y podemos usar un índice con el nombre para obtener el valor real que necesitamos de allí. Así que ahora el valor debería ser el valor real del nombre inicial, así que Frida, Lauri, etc. Todavía ves un error aquí. Deberías proporcionar una prop de valor sin... O no deberías proporcionar una prop de valor sin un manejador de cambios o hacerlo de solo lectura. Como resultado, aún no podemos hacer ningún cambio. Lo haremos más tarde, pero deberíamos poder hacerlo ahora. Lo haremos más tarde, pero este es un primer paso agradable. Así que implementa ese hook useChemeraFields, usa los useContexts para obtener realmente el valor. Y en la diapositiva, el nombre es opcional, pero en realidad lo cambié más tarde para que sea obligatorio. Así que en realidad no necesitas preocuparte de que sea nulo. Así que deja fuera ese signo de interrogación allí, solo defínelo, así que nombre, dos puntos, cadena, y eso simplifica las cosas. Así que añádelo a kimrovLabeledFields, obtén las props de campo de allí, propágalo. Más tarde, en realidad expandiremos esos con más, pero por ahora solo añadirá el valor a la entrada y estará contento. Así que es un cambio bastante pequeño. Voy a abrir las salas de breakout durante cinco minutos para hacer eso. Y en cinco minutos, veré todo eso y luego continuaremos expandiendo esto. Nos vemos en cinco minutos.

Bien, todos están de vuelta en la sala principal. Así que estamos mostrando valores, pero si queremos ver valores, también queremos poder cambiarlos. Después de todo, estamos mostrando valores en un componente de entradas y realmente debería permitirnos hacer cambios. Así que lo primero que necesitamos hacer es añadir un use reducer y luego reducir su función para que podamos empezar a hacer algunos cambios.

Así que el estado se mantiene dentro de ese proveedor así que ahí es donde querríamos usar un Hook Reducer. Así que aquí, en lugar de simplemente pasar los valores iniciales, queremos introducir useReducer. Necesita una función reducer. Así que ya tengo la plantilla para eso así que vamos a pegar eso. Ya tengo la forma, el estado del reducer así que vamos a definir eso. Y asegúrate de que todos esos estén resueltos. Así que eso nos devolverá el estado actual y una función de despacho. esta parte.

Ahora, este reducer no hace nada todavía, así que necesitamos implementarlo. En este caso, todas las posibles acciones son en realidad bastante simples. Sólo hay una simple y única. Así que es relativamente fácil de hacer, pero seguirá los mismos principios que normalmente haces. Así que creas una declaración switch o una forma similar de mapear con diferentes funciones para diferentes acciones. Así que basado en el action.type. En caso de que sea una propiedad establecida, vamos a hacer algo. En este caso, vamos a devolver un nuevo objeto de estado. Empezamos por extender los estados actuales. Bueno, ¿qué queremos cambiar? Queremos cambiar. que tenemos una coma allí. Pero queremos cambiar los valores actuales. Así. Extendemos los valores actuales de nuevo. Así que tenemos una copia de los valores actuales y queremos sobrescribir uno. Que es. Action dot payload dot name. Y el nuevo valor es action dot payload dot value. Así que eso nos da un nuevo objeto de valores. También queremos cambiar el hecho de que nuestros objetos se vuelven sucios. Así que tenemos un objeto de estado de formulario aquí. Queremos hacer el mismo tipo de cosa. Extender el estado actual del formulario. Y establecer is dirty a verdadero. Así que podemos usar eso para habilitar el botón de guardar. Y eso es todo para nosotros. La razón es válida aquí. No voy a implementar esa parte, pero seguiría las mismas líneas con una acción de validation estableciendo el válido y probablemente un mensaje de validation por campo. Básicamente para el uso del micrófono es un mecanismo donde es una estructura de valores con todos los diferentes valores y hay una estructura de error que tiene exactamente la misma forma, pero la presencia de una cadena allí significa que ese campo tiene un error. Pero como dije, no voy a hacer eso. Lo dejaré para que lo hagas más tarde. Así que tenemos eso. Así que ahora necesitamos pasar el valor inicial. Así que los valores son el valor inicial y el estado del formulario es sucio. ¿Por qué no estoy obteniendo la finalización aquí? Es falso, es válido, es verdadero por defecto. Estado genérico del reducer. Ah. No, ¿necesito pasar en? Dice que el estado del reducer tiene un argumento genérico, pero eso es... Debido a una importación incorrecta. Estado del reducer de react. ¿Tengo un error de tipeo? No, me falta una exportación aquí. Por eso se resolvió al equivocado. Y ahora todavía no está contento. ¿Qué está mal? Google está trabajando en un nuevo software allí. ¿Qué estoy haciendo mal aquí? Y. Echemos un vistazo a las diapositivas. Voy a hacer una prueba rápida aquí. Vale. Así que hemos terminado la página de bienestar y vamos a hacer clic en el botón de publicar aquí. Por ahora, dices que queremos los valores de allí. Y ahora tenemos un conjunto de valores. Así que tenemos los medios para cambiar los valores, pero aún no podemos hacerlo. Así que para hacerlo, queremos añadir algo aquí. Queremos añadir un onChange. Y ese manejador onChange obtendrá un argumento, que es un React.ChangeEvent de un elemento de entrada HTML. Y aquí, queremos hacer algo con e.target.name. Y tenemos e.target.value. Queremos desencadenar algo para cambiar el nombre. Así que para llegar a ese reducer, tenemos que pasar por el contexto. Así que queremos algo más que estos valores de ese contexto. ¿Y por qué se está quejando aquí? Probablemente sea por esto. No, eso es un corchete que falta. Así que queremos otra cosa aquí. Así que vamos a añadir una función, setFieldValue. Donde tomamos un nombre, que es algún tipo de cadena. Y un valor, que es uno de esos...... propiedad. Dale más propiedades. Así que aquí, he definido una propiedad específica diciendo, bueno, todas las propiedades pueden ser cadenas o números. En un escenario real, eso será más complejo pero para esto, eso es suficiente. Así que queremos eso y eso no necesita devolver nada. Así que devuelve un void. Um, si mi sintaxis es correcta. Casi, ahora es correcta. Así que necesitamos incluir eso en la implementación y esta es sólo una implementación por defecto, no hace nada, así que esto puede no devolver nada. Un null en este caso, y no le gusta eso porque eso debería ser una coma y en realidad podemos dejar esos también porque no van a ser usados de todos modos. La implementación real tiene que ir aquí.

Entonces, ¿qué queremos hacer aquí? Bueno, aquí, queremos usar la función de despacho y enviar una acción. Ups, sin las comillas. El tipo es una propiedad establecida, lo cual es realmente agradable con TypeScript. Como, sabes exactamente qué tipos están ahí. Y luego la carga útil es un objeto que tiene ese nombre y ese valor. Así que eso asegurará que cada vez que llame a este valor de campo establecido, se envíe una acción al reducer. Actualizará el estado. Los valores devueltos de eso se actualizan y se proporcionan de nuevo a través de ese contexto a todos los hijos. Así que casi estamos allí. Lo que necesitamos agregar es que recuperamos este valor de campo establecido del contexto. Y realmente llamar a eso con el objetivo del evento y el valor del evento, el nombre del objetivo del evento y el valor del objetivo del evento. Y ahora deberíamos poder cambiar los valores. Así que echemos un vistazo. Y realmente podemos cambiarlos. No veo realmente el efecto. Así que déjame añadir un rápido console dot log. Y hagámoslo en el reducer. En realidad, hagámoslo aquí, para que podamos ver el valor. El valor son los valores. Los valores. Así que ahora cada vez que hago un cambio vemos ese cambio aparecer en la console. Así que algunos cambios en diferentes lugares, reducer, y contextos, objetos y un hook. Pero con esos diferentes cambios juntos puedes empezar a editar dentro de este editor. Así que voy a abrir la sala de breakout de nuevo para hacer esto durante 10 minutos porque hay bastantes pasos diferentes involucrados en tener que hacer eso. Nos vemos a todos en 10 minutos.

Bien, todos están de vuelta en la sala principal. En realidad, acabo de darme cuenta de que fui un poco rápido. Este paso fue en realidad sobre agregar el reducer e inmediatamente hice el siguiente paso sobre editar realmente los data y agregar el controlador onChange, pero no hay problema, vamos a hacer eso, solo lo hice un poco más rápido. Así que podemos saltar eso como hecho. Así que podemos ver data, podemos editar data, lo siguiente que queremos asegurarnos es que podemos enviar el formulario cuando esté completo y recopilar esos data. Así que queremos agregar otro hook y queremos agregar algo al elemento de formulario real. Entonces, el que está bien, ¿dónde está el formulario? Correcto, correcto, correcto. Aquí, este objeto de formulario. Así que normalmente queremos agregar un onSubmit aquí, pero lo haremos de la misma manera que lo hicimos con ese campo agregando un hook y haciéndolo reutilizable por lo que no está específicamente vinculado al formulario. Un poco más que necesitamos hacer allí es prevenir el comportamiento predeterminado también, porque ahora mismo si yo realmente, tengo que habilitarlo primero, para poder enviar. Pero ahora si envío, obtenemos el comportamiento predeterminado del navegador donde todos los valores se agregan a la URL. Así que no queremos eso. Así que vamos a agregar eso. Entonces, lo primero que queremos hacer es poder agregar un onSubmit aquí de una manera reutilizable. Entonces, de nuevo, usaremos un hook personalizado muy parecido a lo que hicimos con los campos de Kim Ruff, pero ahora Kim Ruff form. Exportar función Kim Ruff Form. Devuelve un objeto y eso tendrá un onSubmit. Entonces allí queremos hacer algo. Bueno, al final, queremos llamar a la función onSubmit proporcionada por el usuario. Entonces, ¿dónde trabaja realmente el usuario a este nivel? Entonces, al final, queremos algo como un onSubmit aquí, que es una función, que hace algo, y esto debería obtener los valores actuales. Y hagamos una alerta con esos. cadena de valores, y dale un poco de formato valores Ahora, eso aún no se compila, porque todavía necesitamos definirlos. Así que definiremos esas propiedades. Una propiedad onSubmit, que es una función que toma valores de tipo Tdata, que es el tipo genérico que se pasa y no devuelve nada. Así que queremos el mismo onSubmit aquí. Así que podemos empezar a llamarlo más tarde. Para llamarlo, queremos proporcionar otra función en el contexto. Así que encuentra otra función allí. También llamamos a esto onSubmit. En este caso, es una función que toma un evento de formulario de react. React. Sin retorno. Lo mismo por defecto. Así que onSubmit allí. Luego defaultplaceholder. Esto aún no hace nada. La implementación real que necesitamos irá aquí. Lo primero que necesitamos hacer es prevenir el predeterminado. El comportamiento predeterminado del navegador donde se envía de vuelta a la URL y cambia eso. Y luego lo siguiente que queremos hacer es llamar a la función onSubmit proporcionada por el usuario de esta biblioteca. Así que llamaremos a eso y queremos llamar a eso con un conjunto de valores. Excepto que estos son de tipo ligeramente diferente. Así que aquí necesitamos typecostStData. Así que casi funciona. Todavía necesitamos una implementación aquí. Así que const es useContext. skimOrgContext por lo que podemos obtener esa función onSubmit aquí. Y podemos proporcionar eso porque esto ya toma ese evento de formulario como argumento. Así que eso casi funciona. Tenemos que volver a este componente y ahora realmente llamar a esto. Quiero ir allí. Quiero resolver esto. Así que esas son propiedades adicionales que queremos agregar al formulario. Así que podemos extenderlos aquí y ahora deberíamos poder enviar el formulario. Así que si hago algunos cambios aquí, hago clic en guardar. Vemos que se envía y vemos que nuestros cambios aparecen aquí. Así que eso permite al usuario hacer cambios, guardarlos donde necesiten ir, un servidor, lo que sea. Así que un par de cosas que hacer. Hagamos esto primero antes de hacer el último bit. Creo que los combiné aquí, pero sí, los combiné aquí pero haremos esto con el isdirty, etc, en un pequeño próximo paso. Así que aquí está la asignación del formulario, isdirty, etc. en un pequeño próximo paso. Así que abriré la sala de breakout durante cinco minutos donde podemos implementar la función de envío. Déjame cambiar el tiempo y abrir todas las salas y te veré en cinco minutos y luego haremos los últimos cambios. Bien, todos están de vuelta, así que un pequeño cambio final que hacer. Como tenemos una solución que funciona en su mayoría y lo único que no tenemos es que si vengo a la pantalla este botón de guardar está deshabilitado no se habilita hasta que realmente hicimos un cambio y también lo que tenía antes es que estaba mostrando todos los valores aquí. Bueno, dos pequeñas cosas que hacer. Entonces, para hacer eso, podríamos combinar eso en un libro existente con I normalmente creo un hook separado para eso, por lo que el crecimiento de la piel que solo obtendrá todos los data genéricos. En este caso, solo los valores y es sucio que se necesita para eso. Podría hacer eso en el formulario. Usted Skin Reform hook también porque especialmente eso es sucio, está asociado con eso. Pero lo haremos de esta manera por ahora. Entonces. Crear otro hook bastante simple. Exportar función de crecimiento de la piel. Utiliza el mismo contexto de nuevo. Eso debería ser const. Obtendremos un par de cosas de él. En realidad, solo obtendremos los valores ahora porque este estado sucio aún no se proporciona. Lo agregaremos en un segundo. Agregar eso en un segundo. Así que tenemos los valores. Volvemos al Editor de Personas. Llamamos al hook useGimRough, y podemos obtener los valores de allí. Así que de vuelta en el editor, deberían aparecer como lo hacen. Y si hago cambios, vemos los cambios que se hacen aquí. Así que todavía quiero obtener la bandera sucia de allí, pero eso aún no se proporciona. Así que agreguemos eso. Así que lo predeterminaremos a falso. Eso significa que tenemos que proporcionarlo aquí.

Pero eso ya debería estar disponible aquí. Así que tenemos los valores, tenemos el estado del formulario. Eso es dirtyflag. Ya se está estableciendo en el reducer, así que con esto debería funcionar. Así que entramos en los forms. El botón de guardar está desactivado y empiezo a editar y sigue desactivado. Así que aparentemente me falta algo. Veamos. En el reducer estoy estableciendo este dirty a true. Hmm, hmm, hmm, ¿alguien ve lo que me perdí? No le gusta eso, porque ese es el paso que me perdí. Intentemos de nuevo. Está desactivado, empiezo a escribir y se activa. Olvidé exportarlo, por lo que en realidad estaba indefinido, lo cual es falso, por lo que nunca estaba sucio. Así que otro cambio bastante pequeño, y con eso todo lo que necesitábamos hacer está completo. Así que abriré las salas de breakout durante tres minutos para hacer esto. Oops, tres minutos. Y luego después de eso, hemos terminado. Solo lo resumiré y habremos terminado con la masterclass. Así que nos vemos a todos en tres minutos.

Bueno, todos han vuelto, así que ese fue el último ejercicio, es hora de concluir. De hecho, me pasé un poco de tiempo, así que lo siento por eso. Espero que no sea un problema. Así que conclusión. Los Hooks son típicamente muy simples de usar, pero tienes que conocer las reglas para cumplirlas. Existen por buenas razones. No es que haya tantas reglas y que sean tan difíciles o restrictivas, así que normalmente no es un problema. Los Hooks son realmente muy simples y realmente elegantes, lo cual es realmente agradable. Bonito detalle de la implementación de los Hooks cuando el equipo de React lanzó por primera vez los Hooks. Otras bibliotecas como Preact y Vue en realidad tenían implementaciones de prototipos similares en un día o unos pocos días. Así que fácil de implementar y realmente útil. Los Hooks personalizados son geniales. Los Hooks estándar son poderosamente útiles, pero crear tus propios Hooks personalizados o encontrarlos en internet porque hay muchos paquetes de NPM o repositorios de GitHub con muchos Hooks útiles. Así que es muy recomendable hacer eso. Crea tu propio conjunto de Hooks para su uso. Cosas como eso, use debunks, etc., son pequeños Hooks de utilidad para tener a mano. Y en general, los Hooks son una excelente manera de agregar la funcionalidad que necesitas para tus componentes que no es exactamente UI en sí. Así que crea componentes para la funcionalidad de UI, crea Hooks para toda la funcionalidad no relacionada con la UI, y conéctalo todo de una manera realmente agradable. Espero que la segunda parte del laboratorio donde creamos ese clon de formulario mostró una buena manera de cómo puedes combinar todas estas cosas. Gracias por estar aquí. Gracias por asistir. Espero que hayas aprendido algo útil y algo que puedas usar en tu trabajo diario con React. Recuerda, puedes encontrarme en Twitter, en MauriceDB, o puedes enviarme un correo electrónico si tienes preguntas sobre esto. Todos recibirán una grabación de esta sesión. Tienes todos los materiales, tienes las diapositivas, tienes el repositorio de GitHub con todos los códigos. Así que todo eso es útil para referencia si quieres. Así que eso es el final. Gracias a todos por estar aquí. Si alguien tiene alguna última pregunta, ahora es un buen momento para hacerlas. Muchas gracias. De nada, gracias por estar aquí. Fue una gran masterclass, muchas gracias. Gracias por las amables palabras. Maravilloso, gracias. Gracias. Realmente útil, gracias. Sí, gracias, adiós.