Las Cosas Extrañas de React

Suficiente sobre mí, bueno, no del todo. Comencemos de verdad. Mi viaje comenzó con, creo, la versión 0.12 o 0.13 de React. Y ese momento fue increíble. Sabes, tenías esta clase de creación de componentes y React era muy claro. Y todo estaba bien. Realmente lo disfruté.

Luego vino la versión 0.14. Y esos fueron buenos tiempos. Y luego llegó la primera señal de advertencia. ¿Qué? ¿Por qué no 1.0? Sí, pero hicieron esta publicación en el blog, este blog realmente, realmente largo sobre por qué están haciendo esto y básicamente explicando Semver y demás. Y sentí como, OK, así que probablemente, quiero decir, por qué están haciendo esto, deben sentirse culpables. O deben ver que están haciendo algo mal. Y están poniendo mucho empeño en ello. Y así que estoy bien con eso. Sigamos adelante. Y después de eso, el mundo estaba bien de nuevo. 16, 17, 18, las cosas están bien. Sí, el mundo es increíble.

Y una cosa que realmente me encantó de React fue la documentación oficial en twitter.com. Y realmente puedes encontrar mucho contenido genial allí que no encuentras en React.js o IG o algo así. Permíteme darte tres ejemplos. Voy a pasar rápidamente por esto y luego pasar a cosas más extrañas. ¿Sabías que en realidad puedes usar la propiedad Key para volver a montar componentes? Esto es fantástico. No encontrarás esto en ningún otro lugar. Bueno, hay un lugar. Entonces, ¿qué significa esto? Un ejemplo breve y conciso. Si interactúas con esta aplicación, es muy simple. Tiene un botón. Puedes generar IDs aleatorios.

Y lo colocamos directamente en algún componente, sea cual sea, como un Keyprop. Y le asignamos este ID que cambia. Pero la cosa es, si cambiamos, digamos, el contenido, el contenido real es A, B, C, y lo cambiamos a GHI, lo que sucede es que el componente se volverá a montar. Y cuando me di cuenta de esto, no sé si alguien me lo dijo o algo así, me quedé asombrado, esta es una herramienta mágica. Quiero decir, probablemente no deberías usarla todo el tiempo, pero a veces es realmente útil. Si tienes el componente de otra persona y han arruinado el useEffect, puedes usar esto para darle un nuevo enfoque. Y por supuesto, en la documentación oficial, aprendí que esto en realidad está bien hacerlo. No está documentado, pero piensan que este es un caso de uso en el que está bien. Así que Sebastian Markbash mencionó que si tienes esta situación principal de detalle, es bueno usarlo. Aún no estoy seguro, porque creo que como no está documentado, sí, no sé. Creo que la gente no entendería lo que está sucediendo y luego podrían sentirse extraños. Pero lo bueno es que respondieron, oye, ¿por qué no agregarlo a la documentación? Y gracias a nuestro ángel Dan, él respondió, oye, probablemente lo esté haciendo, sí. Y no sé si los has visto, pero los nuevos documentos beta, son increíbles. Son tan buenos y tienen tantos ejemplos y tutoriales que puedes revisar. Realmente profundizan un nivel más y te enseñan mucho. Y esto es básicamente la mitad de la solución de cómo usar React.

En otro ejemplo, hay otra forma de evitar el useEffect que David, por la mañana, no mostró. Y esto es como flush sync. Tú, sí, lo que puedes hacer con él es ejecutar flush sync y luego establecer algún set state actualización allí. Y lo que hará es confirmarlo realmente al DOM. Pero nuevamente, es como antes de pintarlo. Entonces lo que puedes hacer es usarlo en lugar de solo usar layout effect y scroll, por ejemplo, al último mensaje si tienes una aplicación de chat. Es bastante bueno. Viene de React DOM, por lo que si estás usando React Native, no funciona. Pero es un pequeño truco interesante.

Entonces la pregunta principal es cómo David no sabía sobre esto. Y la cosa es que no estaba en Twitter. Estaba en YouTube. Pero fue una sesión de codificación que hizo Dan. Sí, eso fue grabado. Y luego alguien en mi taller de React me lo contó y lo descubrí. Así que me sentí obligado a ponerlo aquí. Así que le pregunté a Dan por qué no estamos agregando esto a los nuevos beta documentos. Y él respondió que hay un par de buenas razones por las que realmente no quieres hacerlo. Entonces FlushSync podría no ser la herramienta adecuada para el trabajo. Pero al menos ahora está en Twitter y puedes encontrarlo.

Sí, el último ejemplo es sobre cómo desde React 18 puedes retornar undefined en tus componentes. Entonces básicamente esto sería una aplicación válida. Ahora este es un componente válido de React. Y cuando esto salió hubo esta línea, creo que fue un párrafo y luego una línea y un registro de confirmación y así sucesivamente. Y sentí como OK, pero ¿por qué? Realmente quiero saber por qué me estás haciendo esto. Como retornar null era completamente válido. Realmente disfruté la experiencia aquí y la API y tenía total sentido y no había nada. Ningún razonamiento como qué diablos está pasando. Afortunadamente, Ricky, un par de días después en Twitter publicó porque la gente realmente estaba preguntando qué estaba pasando. Él respondió, sí, responderé esto y luego, nuevamente, un par de días después, realmente lo hizo. Y cuando lo hizo en la segunda cosa que comienzas a leer porque aquí es donde a menudo se explica el por qué, el grupo de trabajo. Entonces creo que el grupo de trabajo es básicamente donde hacen las propuestas pero también encuentras mucho contenido y luego en las discusiones del razonamiento por qué son ciertas cosas, por qué los cambios en la API son como son y cuál es el razonamiento detrás de ello. Entonces lo bueno es que todo el tema de la documentación fue extraño, pero creo que estamos llegando allí resolviendo en los mejores, los beta docks son geniales y el grupo de trabajo es una solución increíble para entender el por qué más.

Entonces pasemos a otro tema completamente diferente, la composición. Y la historia de la composición en React también es realmente extraña. Comenzó para mí con los mixins. ¿Quiénes de ustedes estaban allí cuando existían los mixins? Wow, no tantos. Bueno, los mixins eran esta cosa que podías poner en tu componente de clase creado y permitía características increíbles como las de Angular, o creo que tuvimos que hacerlo por Angular, la vinculación bidireccional de datos. Así que podías conectar directamente el estado a tu entrada y no tenías que pasar por este ciclo. Sí, era un poco extraño. En realidad, no lo usé demasiado, pero en algunos casos.

Y teníamos memo antes de memo, un mixin aleatorio puro era increíble. Pero luego sucedió algo, otro artículo de blog. ¿Y qué significa? Bueno, se fue. Así que descubrieron que los mixins son perjudiciales y adiós mixins, los vamos a deprecar. Genial. Actualicemos la base de código. ¿A dónde deberíamos ir? La solución, componentes de orden superior. En ese momento estaba totalmente emocionado. Los amaba. Esto fue exactamente en el momento en que realmente nos adentramos en la programación funcional. Así que funciones de orden superior y todo ese tipo de cosas, ¡wow! El único problema es que si construyes aplicaciones grandes con esto, se vuelve tan complicado y enredado que básicamente es completamente inmantenible. Y era bueno para consultoría. Tenía trabajos en los que los desarrolladores abandonaban el proyecto dos semanas antes del lanzamiento y luego podías ganar buen dinero con eso. Pero tal vez no para tus propios proyectos.

Así que no hubo publicación en el blog, pero al menos hay una actualización en el Readme de recompose donde se anunció que no deberías usarlo y deberías seguir adelante. Nos deshicimos de todos los hooks nuevamente, bueno, casi todos. Aún conservamos memo y forward ref. Memo, lo entiendo. Forward ref. Ojalá fuera parte de ello, pero está bien. Lo entiendo. No queremos serlo. En realidad no lo sé. Tengo que preguntarles a algunos en Twitter, y luego aprenderemos por qué forward ref todavía existe. Lo busqué. No lo he encontrado. Entonces, ¿a dónde nos movemos desde los componentes de orden superior? Todavía tenemos que resolver este problema de composición, bueno, tuvimos que resolver este problema de composición. Y luego pasamos a algo que realmente, realmente, realmente odiaba, y eso eran las render props. Oh chico. El anidamiento allí, era tan doloroso. Y sí, estoy muy contento de habernos deshecho de eso. Y la única parte buena que recuerdo, o que queda de ese tiempo, al menos para mí, es que instalé este complemento en VS Code que colorea todos mis paréntesis y corchetes, porque esta es la única forma de gestionar la estructura enredada de mis componentes en ese entonces.

Así que tenemos a nuestro salvador. Todos lo recuerdan, con suerte. Los hooks. Quiero decir, ¿qué no es increíble de ellos? Funciones con estado. ¿Quién no quiere tener funciones con estado? ¿Sabes? Es, sí. No puedes hacer bucles con ellos. No puedes tenerlos condicionalmente. Así que, bueno, hay algunas desventajas. Pero sí, en general, son bastante buenos. Excepto cuando intentas explicárselo a alguien como un ingeniero de backend que generalmente trabaja con funciones sin estado, que es lo normal por defecto. Sí, y no están muy contentos al respecto, pero luego ya estás muy emocionado con la conversación y les hablas sobre tus clases no extensibles que has deprecado con tus funciones con estado. Y sí, si luego pasas a JSX, básicamente pierdes a un amigo porque ellos no entienden en absoluto lo que estamos haciendo allí. Pero los hooks son geniales. Son muy claros. Deben usarse en una función React. Deben comenzar con use y no deben usarse condicionalmente. Bueno, excepto que en Twitter aprendes que todo es una mentira porque puedes usar use context, en realidad de forma condicional. Te gritarán, pero puedes hacerlo. No deberías hacerlo. Y no te animo a hacerlo, pero puedes.

OK, entonces los documentos están resueltos. Como, la historia de la composición, no sé, como que estoy contento con los hooks. Me gusta. Y la nueva propuesta, como acabamos de escuchar, también parece interesante. Veamos a dónde llegamos. Pero parece que aún no hemos terminado. El cambio aún está por venir. Pasemos a algo completamente diferente. Nint exports, ya sabes. Amo mis nint exports y amo la consistencia.

Me encanta que todos los equipos con los que trabajé hace un par de años, todos estuvimos de acuerdo, como, las exportaciones de nint son la mejor experiencia. La autocompletación para importar cosas es increíble porque VS Code realmente, simplemente comienzas a escribirlo y puede encontrarlo en otros módulos e importa automáticamente tu componente o tu función o lo que sea. Y teníamos una base de código consistente, y luego llegó React Lazy. Y todo se arruinó de nuevo porque React Lazy en realidad requiere que uses la exportación por defecto. Y sí, en este punto, básicamente lo que sucedió es nuevamente, mucha discusión en los equipos. ¿Cómo lo hacemos? ¿Movemos todo de vuelta a las exportaciones por defecto porque ahora tenemos consistencia o solo los componentes de React? Y, y, y, y, y, muchas discusiones. Pero esta vez, sientes que, OK, el césped debe ser más verde al otro lado. Así que comienzas a mirar a Angular. Y comienzas a preguntarte, ¿qué versión están usando en realidad? Y luego ves uno, dos, cuatro. Y sientes que, OK, es la misma historia. Volvamos a React. Y profundizas. Y descubres que en realidad puedes usar React Lazy con exportaciones nombradas. Es solo que es muy torpe. Pero es posible. Así que tal vez aún tengas tu discusión sobre las exportaciones por defecto en los componentes. Y al menos en nuestro caso, esto es lo que sucedió. Pero incluso si quieres cargar de forma perezosa un componente externo que es solo una exportación nombrada, al menos puedes hacerlo. Es increíble. Impresionante. Pero la exportación por defecto aún tiene sentido. Porque quiero decir, si usas Next o Remix, todavía quieren que uses la exportación por defecto. Así que tiene sentido mantener al menos la consistencia. Pero este pequeño truco al menos resolvió mi problema en ese caso. Es extraño, pero está bien. Sigamos adelante.

Siguiente gran tema, TypeScript. Me encantan los tipos. Soy un gran fan de TypeScript.

Me encantan otras cosas, pero TypeScript es genial. Así que hablemos de los tipos de React. Bueno, ¿cómo tipamos un componente de React? Obviamente, es muy claro. Tienes React.componente de función. En los parámetros de tipo genérico, colocas las props. Eso es increíble. Pero en realidad es molesto y demasiado largo, así que preferirías usar React.fc. Y realmente, realmente, realmente disfruto cuando hay múltiples formas de hacer lo mismo. Esto es genial. Pronto presentaré una propuesta en JavaScript que también agrega alias para función, como fun, funky, y puedes agregar los tuyos si quieres. Sí.

Entonces, así es como tipas un componente de React, excepto cuando te das cuenta de que muchos expertos en TypeScript que trabajan con React te dicen que no lo hagas. No lo hagas de esta manera. No uses React.fc. Y tú piensas, vale. Y lo interesante es que el principal problema es, quiero decir, hay algunos otros problemas menores. Todos tienen sus preocupaciones. Pero lo que siempre surge es el tema de los hijos implícitos. Lo explicaré en un momento. Pero básicamente te dicen que deberías hacer esto en su lugar. Simplemente tipa la función con 'if props' como tus props. Y ya está. Vale. Hasta aquí todo bien. ¿Cuál es el problema entonces?

Bueno, el problema es si estás trabajando con desarrolladores junior, por ejemplo, y ves en tu código base que simplemente hacen lo que todos los demás hacen en el código base. Y luego, eventualmente, aprenden, lo descubren. Existe React.fc. Así que se acercan a ti, y están realmente emocionados. Están felices porque tienen una propuesta para mejorar el código base. Y luego encuentran algo. Y entonces puedes desalentarlos. Es lo único que puedes hacer. Bueno, no deberías usarlo. Y comienzas a explicarlo, y yada, yada, yada. Y sí, perdiste otra media hora en nada. Pero lo que sucede es que luego viene esta pregunta, ¿pero por qué existe entonces? Y lo único que puedes hacer es esto. Pasemos a otro tema. Pero luego ocurrió lo impensable.

¿Qué pasó? Con los tipos de React 18, también hicieron un cambio que rompe la compatibilidad, y eliminaron los hijos implícitos. Wow. Estaba emocionado.

Es fantástico. Estaba realmente, realmente feliz. ¿Por qué es esto importante? ¿Por qué es relevante? Digamos que tienes un componente, y ahora puedes usar React.fc de nuevo. Y estás usando hijos allí. Ahora debes mencionarlo explícitamente. Quiero decir, aún puedes hacerlo opcional si deseas tener hijos opcionales, pero también puedes hacerlo obligatorio. Entonces, ¿qué significa esto, básicamente aquí?

Tengo hijos en mi componente. Bastante bien, pero si haces esto aquí, si alguien está usando tu componente, y están haciendo esto aquí, TypeScript les mostrará un error. Como, necesitas pasar hijos, y, por supuesto, no siempre tiene sentido, pero si estás creando un componente como un popover o un modal, todo el asunto sin hijos no tiene mucho sentido. Entonces, aquí es donde es útil, y especialmente al revés, es aún mejor. Si no esperas tener hijos, no haces nada con ellos, básicamente puedes decir explícitamente, hey, no quiero hijos. Si los pasas, muestra un error. Entonces, si haces esto, todo está bien. Si haces esto, como alguien que está usando este componente, TypeScript te mostrará un error. Ta-dah, no pases hijos. Ah-ha. Y esto es exactamente como mi modelo mental de un sistema de tipos, y quiero decir, también puedes, me siento validado al leer Wikipedia. El objetivo es prevenir que las operaciones esperen un cierto tipo de valor y se usen con valores que no tienen sentido para la operación. Sí. Queremos asegurarnos de que todo tenga sentido. Increíble.

Entonces, este cambio fue increíble. Lo disfruté. Perfecto. Sigamos adelante. Y la mejor parte de esto es que incluso crearon un code mod. ¿Quién ha oído hablar de un code mod o simplemente un code shift? No muchas personas, así que básicamente esto es un script que puedes ejecutar en todo tu código, y soluciona todos los cambios que rompen. Esta es la idea. Y en realidad no son solo expresiones regulares, sino que funciona en el EST, por lo que es bastante inteligente, y esto lo hace realmente, realmente agradable de usar. Y eso también significa que funciona casi el 100% del tiempo. O debería ser en realidad el 100% del tiempo, excepto si estás haciendo algo realmente, realmente extraño. Y lo que hizo esto, así que ejecuté esto en mi código después de actualizar a React 18, increíble, increíble, increíble, y luego esto sucedió. Entonces, el script hizo esto. Básicamente, pasamos de React fc props a React, así que hacemos un parámetro de tipo con un parámetro de tipo. Está bien, puedo vivir con eso. Probablemente sea la forma más fácil para ellos de seguir adelante y solucionarlo. Pero hay una pequeña cosa que realmente me molestó. No estoy usando children aquí. ¿Qué quieres decir con que estás agregando props con children aquí? Está bien, debe ser un error, obviamente, como que el code mod está roto o algo así. Y empiezas a investigar un poco y ves props con children como children opcionales de nuevo. Y siento como si no hubieras aprendido nada. Es como, ¿por qué? ¿Por qué me haces esto de nuevo? Es como, al menos nómbralo props con children opcionales. Esto habría sido solo una pequeña cosa. Son solo muchos, muchos detalles pequeños, pequeños. Entonces no tengo que emocionarme por esto, ¿sabes? Prometí no hablar sobre use effects, pero hagamos una cosa más sobre use effects.

Todos sabemos que debemos limpiar nuestro useEffect porque puede causar problemas ahora, especialmente en el futuro. Quiero mostrarte algo que aún no he propuesto a mi equipo, pero quiero hacerlo, pero el tiempo, y definitivamente lo haré.

Entonces investigué y una cosa que se me ocurrió es que tal vez podamos obligar a las personas a siempre escribir la función de limpieza, porque entonces se vuelve más obvio que realmente deberías hacerlo. Investigué cómo puedo sobrescribir los tipos de React, y encontré esto. Básicamente copié los tipos de React directamente de los tipos de React, y creé un archivo index.d.ts, y esto te permite sobrescribir el módulo React, useEffect. Y esta es básicamente la firma. Y lo que quiero hacer ahora es, quiero eliminar la opción de no devolver una función en useEffect. Así que simplemente eliminamos el void, y sí, te mostraré en un segundo lo que esto significa. Y luego me sentí obligado a corregir el nombre, porque, quiero decir, en todas partes en la documentación dice una función de limpieza, y aquí dice destructor. La gente estará tan confundida por esto. Así que llamémoslo Función de Limpieza. Y llamémoslo useEffectCallback y no EffectCallback. OK. Y lo que hace esto, si tienes esta función que has visto antes que no devuelve este useEffect, que no devuelve una función en la función, esto realmente te gritará de nuevo. Y sí, a veces tienes useEffect donde realmente no quieres hacer nada en la Función de Limpieza. Pero al menos en nuestro caso, el código es tan raro que creo que sería mejor. Entonces obligas a las personas a hacerlo realmente. Y sí, podrían hacer esto aquí. Pero en una revisión de código, es más fácil señalarlo y más fácil de encontrar, y puedes encontrar cosas. Así que creo que esto, no sé si funcionará. Pero al menos quiero intentarlo. Sabes, me divierto parcheando cosas.

Y luego sentí que tenía que hacer algo al respecto. Investigé un poco y ¿sabías que realmente puedes parchear console.log? Me encanta esto. Y una vez que descubrí esto, en realidad debería haber hecho lo adulto y hablar con mi equipo y discutir con ellos cómo podemos solucionar nuestras advertencias y ocultarlas, al menos por un tiempo. Pero luego creé este script. Esto es mucho más divertido. Entonces, si colocas esto en tu base de código, ¿qué hace? Sí, luego puedes copiarlo y pegarlo más tarde. Solo acércate a mí y te lo enviaré o lo publicaré en Twitter. Entonces, este script sobrescribe el registro de la consola y después de 702 milisegundos, lo borra. OK, esto no es perfecto. Pero una buena broma debe ser lo suficientemente larga para que puedan verla y no tomen medidas de inmediato, pero lo suficientemente molesta como para que sea exactamente eso, que no tomen medidas. Es realmente molesto. Y esto es parte de una buena broma. Y por supuesto, invertí más porque realmente quería asegurarme de que la gente no lo encontrara. Entonces, este es el mismo script, pero escrito de una manera que si buscan console, log o clear, no lo encontrarán. Sí, así que por favor toma esto. Puse algo de esfuerzo, ¿sabes? Por favor, toma esto y molesta a tu equipo con ello. Y si haces mejoras, tengo algunas ideas. Como si el contenido del registro es más largo, entonces puedes mantenerlo por un poco más de tiempo. Y si es más corto, entonces el temporizador debería ser más corto. Entonces, si haces esto, siéntete libre de acercarte a mí. Y podemos compartir código. Aceptemos el código abierto. Sí, así que con licencia MIT. Siéntete libre de tomarlo. Y luego volví a lo adulto, ¿sabes? Así que encontré, OK, hablemos con el equipo. Y vamos a parchear nuestro registro de la consola, y console uno, y console error. Y luego sentí, OK, debería hacer algo para ti también. Y realmente necesito lanzar algo en conferencias este otoño. Así que creé React Reduce Stress. En realidad, hoy lanzamos la versión 2.0.

Y lo que te permite hacer es que hay una API. Puedes obtener esto, puedes ingresar esta función. Así que está realmente en NPM. Es una cosa, ¿sabes? Puedes obtener advertencias de consola suprimidas. Y luego puedes, para los hooks, ordenar una clave única en una lista, usar el controlador nativo. Esto es React Native. En set native props, puedes suprimir las advertencias. ¿Y qué te da? Tranquilidad en tu consola. Excelente.

Entonces, lo último, de verdad. ¿Quién de ustedes usa el modo estricto? Bueno, ¿por qué? OK, no te preocupes. Solo bromeo. Pero en realidad, ¿cuáles son las razones? Entonces, los primeros son como, vamos a parar. OK, nos deshicimos del vamos a parar ya, así que ¿por qué me importa? Bueno, por este doble renderizado. Y sí, entiendo. Quieren introducir esta cosa fuera de pantalla, y no pudieron hacer el cambio rompedor en el medio. De lo contrario, tendríamos la versión 19. Así que es mejor hacerlo de inmediato con la 18 y bla, bla, bla. Pero el problema, básicamente, son los dos últimos puntos.

El problema es que la gente no lo entiende. Esto es como una conversación real entre un amigo mío y yo tratando de explicarme que React y React 18 ahora se renderizan dos veces. Y él perdió un día, y luego algunas palabras malsonantes que tuve que censurar. Y estaba frustrado. Él solo usa React, y no lee los posts del blog y demás y así sucesivamente. Y él es solo un usuario. Y sentí como si, quiero decir, ¿no podríamos haber hecho su experiencia más fácil? ¿Qué? Console lock habría resuelto esto. Y tenemos console locks para todo, pero no para esto. Vamos. Vamos. Quiero decir, incluso si no tienes las herramientas de desarrollo, directamente te indicamos que deberías instalar las herramientas de desarrollo.

Vamos. Y no una advertencia. Así que esta vez, hice lo correcto. Creé un problema en el repositorio de React. Está ahí desde hace un poco más de un mes y no ha habido reacción. Pero está bien. Puedo vivir con eso porque tengo React-reduced stress.

Entonces, lo que puedo hacer es, obviamente, crear una nueva función en React-reduced stress, vamos a importarla, y luego la verás. Obtenemos React-reduced stress como un componente de React-reduced stress. Podemos editarla como un componente ahí, y lo que hace es darte exactamente esta advertencia. Te dice, hey, hay este doble renderizado. Y hay un enlace a la documentación oficial que explica por qué esto es realmente relevante. Y sí, espero que esto ayude a muchos principiantes a no perder un día, o dos, o tres.

Hablemos de las características de esto, porque, una vez más, le puse amor. Viene con SMDS. ¿Nunca has oído hablar de eso? Sí. Sistema de detección de modo estricto. Sistema de detección de modo estricto, lo robé, o como, es de código abierto, lo obtuve directamente del código base de React. ¿Qué están haciendo? Están capturando los console logs para averiguar si realmente estás en estas pruebas, si el modo estricto está activo. Así que tomé todo eso, básicamente lo usé en reduce stress. Y sí, le puse más amor. En realidad tiene soporte para modo oscuro, por lo que el color rojo en el log es diferente. Y tiene soporte para navegadores modernos, así que no Internet Explorer ni Safari.

Sí, y eso básicamente me lleva a la conclusión de hoy. ¿Qué deberías sacar de toda esta charla extraña que se me ocurrió aquí? Deberías leer la nueva documentación. Deberías unirte al grupo de trabajo, porque es realmente, realmente útil. Definitivamente deberías honrarme gastando una broma a tu equipo con una actualización de console log. Y deberías instalar reduce stress. Esto te dará beneficios. Y en cuanto a mí personalmente, quiero decir, React es realmente extraño en algunos casos, pero he aprendido mucho en el camino. Y ha sido un viaje bastante interesante. Y seguiré aquí en el futuro previsible y seguiré mejorando y solucionando cosas y divirtiéndome. Soy Nic Graf. Espero que hayas disfrutado esta charla y gracias muchas gracias por escuchar. Gracias.