Problemas de representación condicional en JSX, forwardRef, varias formas de crear refs, render props (sí, todavía existen), componentes de orden superior (¿todavía existen?), act, clases no extensibles, SuspenseList (bueno, tal vez en 10 años), React.FC y, por supuesto, nuestro buen amigo useEffect. Todas estas cosas extrañas son parte de nuestra biblioteca favorita (no un framework™) y aún así la usamos y amamos. ¿Por qué en realidad? Vamos a hablar de ello. Descargo de responsabilidad: Esta no es una charla muy seria, en su mayoría...
This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.
FAQ
Serenity es una herramienta similar a Notion o Confluence, pero se diferencia principalmente porque ofrece cifrado de extremo a extremo para proteger los datos de los usuarios.
Serenity utiliza React y React Native para el desarrollo de sus aplicaciones, permitiendo la compilación tanto para la web como para aplicaciones móviles iOS y Android.
Sí, Nick es tutor en ACAD y ofrece cursos que pueden ser de interés para quien desee aprender más sobre las tecnologías que maneja.
La propiedad Key en React se utiliza para controlar el proceso de montaje y desmontaje de componentes. Asignar un nuevo ID a Key hace que el componente se remonte, lo cual es útil para forzar un reinicio en ciertos escenarios, como cuando useEffect no se comporta como se espera.
Flush sync es una función en React DOM que permite actualizar el estado y confirmar los cambios al DOM antes de que se realice el repintado. Esto es útil para casos como mantener el scroll en la última posición en una aplicación de chat.
Permitir que los componentes de React retornen undefined facilita ciertas prácticas de desarrollo y composición de componentes, aunque este cambio inicialmente generó confusión entre los desarrolladores.
La composición en React ha evolucionado desde el uso de mixins, pasando por componentes de orden superior y render props, hasta llegar a la adopción de hooks, que simplifican el manejo del estado y el ciclo de vida en funciones.
Aunque React.FC es comúnmente utilizado para tipar componentes en React con TypeScript, algunos expertos recomiendan evitarlo debido a problemas como los hijos implícitos, sugiriendo en su lugar tipar las props directamente en la función del componente.
La charla de hoy cubrió varios aspectos interesantes de React, incluyendo el uso de Keyprop para volver a montar componentes, el truco de flush sync para confirmar actualizaciones al DOM, la evolución de la historia de composición de React, los beneficios de usar hooks y React Lazy, las mejoras en el sistema de tipos de React, el código mod para solucionar cambios que rompen, lidiar con advertencias molestas y la introducción de React-reduced stress. El orador también animó a los lectores a explorar la nueva documentación de React, unirse al grupo de trabajo y contribuir a la comunidad de React.
Hoy vamos a hablar sobre las cosas extrañas de React. Trabajo en Serenity, una herramienta similar a Notion que está cifrada de extremo a extremo. Utilizamos React y React Native para el desarrollo web, iOS y Android. También soy tutor de ACAD y estoy disponible para consultas o trabajos freelance. No dudes en contactarme.
Soy Nick, una breve introducción. Sí, trabajo en Serenity. Básicamente, piensa en esto como una versión similar a Notion o Confluence, pero en realidad está cifrada de extremo a extremo. Y por supuesto, utilizamos React, React Native, en este caso. Así que compilamos para la web y React Native o aplicaciones iOS y Android. También soy tutor de ACAD, así que puedes encontrar algunos cursos míos. Y dependiendo de quién pregunte, soy consultor o trabajo como freelance, así que sí. Si necesitas ayuda, no dudes en contactarme.
2. Viaje con React y características interesantes
Short description:
Mi viaje con React comenzó con la versión 0.12 o 0.13. Disfruté usando React y la documentación oficial en twitter.com. Permíteme darte tres ejemplos de cosas interesantes que quizás no conozcas sobre React. Un ejemplo es usar la propiedad Key para volver a montar componentes.
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.
3. Usando Keyprop para volver a montar componentes
Short description:
Puedes usar el Keyprop para volver a montar componentes en React. No está documentado, pero se considera un caso de uso válido. Sebastian Markbash recomienda usarlo en ciertas situaciones. Los nuevos documentos beta de React son increíbles, con muchos ejemplos y tutoriales. Proporcionan una comprensión más profunda de React.
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.
4. Flush Sync y Retornar Undefined en React
Short description:
Hay un truco muy interesante llamado flush sync que te permite confirmar las actualizaciones al DOM antes de pintar. No está documentado en los nuevos documentos beta, pero puedes encontrarlo en Twitter. Otra característica interesante en React 18 es la capacidad de retornar undefined en los componentes. Esto fue explicado por Ricky en un hilo de Twitter y discutido en el grupo de trabajo. El grupo de trabajo proporciona información valiosa sobre el razonamiento detrás de los cambios en la API.
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.
5. Historia de la Composición en React
Short description:
La historia de la composición en React comenzó con mixins, que permitían características como la vinculación bidireccional de datos. Sin embargo, fueron deprecados debido a considerarse perjudiciales. A continuación, se introdujeron los componentes de orden superior, que inicialmente eran emocionantes pero se volvieron complicados y difíciles de mantener en aplicaciones grandes.
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.
6. Desafíos de la Composición en React
Short description:
Antes teníamos memo antes de memo, un mixin aleatorio puro. Pero luego los mixins fueron deprecados y pasamos a los componentes de orden superior. Sin embargo, se volvieron complicados y difíciles de mantener en aplicaciones grandes.
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.
7. Transición de HOC a Hooks
Short description:
Nos deshicimos de todos los hooks nuevamente, excepto memo y forward ref. Aún no entiendo por qué existe forward ref. Pasamos de componentes de orden superior a render props, lo cual odiaba debido al anidamiento doloroso. Lo único bueno fue usar un complemento en VS Code para gestionar la estructura enredada de mis componentes.
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.
8. Hooks, JSX y Nint Exports
Short description:
¡Los hooks son increíbles! Las funciones con estado son geniales, excepto cuando se las explica a los ingenieros de backend. JSX puede ser confuso, pero los hooks brindan claridad. Sin embargo, hay excepciones, como usar el contexto de forma condicional. La historia de la composición con hooks es satisfactoria y la nueva propuesta es intrigante. El cambio aún está por venir. Hablemos sobre los nint exports y la consistencia.
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.
9. React Exports and TypeScript
Short description:
Me encanta que todos los equipos estén de acuerdo en que las exportaciones de nint son la mejor experiencia. La autocompletación en VS Code es increíble. React Lazy causó algunos problemas con las exportaciones por defecto, lo que llevó a discusiones y exploración de otros frameworks. Sin embargo, React Lazy aún se puede usar con exportaciones nombradas. TypeScript es otro tema de interés para los fanáticos de TypeScript.
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.
10. Tipos y Alias de React
Short description:
Me encantan otras cosas, pero TypeScript es genial. Hablemos de los tipos de React. Tienes React.componente de función, pero es molesto y demasiado largo, así que preferirías usar React.fc. Y realmente disfruto cuando hay múltiples formas de hacer lo mismo.
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í.
11. Tipado de Componentes de React e Hijos Implícitos
Short description:
Muchos expertos en TypeScript desaconsejan el uso de React.fc y recomiendan tipar la función con 'if props' en su lugar. El principal problema de usar React.fc son los hijos implícitos. Cuando trabajas con desarrolladores junior, pueden descubrir react.fc y proponerlo como una mejora, pero debes desalentarlos. Lo impensable ocurrió con los tipos de React 18: eliminaron los hijos implícitos.
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.
12. React Children and Type System
Short description:
Ahora puedes mencionar explícitamente si deseas tener hijos en tu componente de React. Si estás creando un componente de popover o modal, tiene sentido tener hijos. Por otro lado, si no esperas tener hijos, puedes indicarlo explícitamente y TypeScript mostrará un error si se pasan hijos. Esto se alinea con el objetivo de un sistema de tipos de prevenir el uso de operaciones con valores que no tienen sentido.
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.
13. React Code Mod and Unexpected Changes
Short description:
Este cambio fue increíble. Crearon un code mod que soluciona los cambios que rompen tu código. Funciona casi el 100% del tiempo, excepto en casos raros. Sin embargo, hubo una cosa que me molestó. El code mod agregó props con children aunque no estaba usando children. Es frustrante cuando se pasan por alto pequeños detalles como este.
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.
14. Enforcing Cleanup Function in useEffect
Short description:
Quiero hacer cumplir la escritura de la función de limpieza en useEffect eliminando la opción de no devolver una función. También corregí el nombre para que sea más consistente. De esta manera, se recordará a las personas que incluyan la función de limpieza y será más fácil encontrar problemas durante las revisiones de código.
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.
15. Dealing with Annoying Warnings
Short description:
Me divierto parcheando cosas, pero las advertencias pueden ser molestas, especialmente cuando provienen de paquetes y no se puede hacer nada al respecto. Es frustrante cuando llenan la consola mientras se depura. Esta ha sido nuestra experiencia durante semanas. Ojalá hubiera una forma de solucionarlo.
Lo que me hace, estoy atrasado pero pronto terminamos. Una cosa más, las advertencias. Mi relación de amor y odio con las advertencias. ¿Quién de ustedes ha visto esto aquí? Sabes, estás haciendo una actualización de estado en un componente que en realidad ya ha sido desmontado y así sucesivamente. Y creo que esto es realmente útil. Realmente disfruto esto. Me gusta esto. Esto es genial. Pero no es genial si viene de un paquete. Porque no puedes hacer nada al respecto. Si ya estás en la última versión, por supuesto que puedes crear un problema reproducible al respecto y bla, bla, bla. Pero sigue molestando tu consola. Y quiero decir que esta es una situación del mundo real. Hemos estado así durante semanas. Estábamos en las últimas versiones de los paquetes con todo y así sucesivamente. Y esta fue nuestra experiencia cada vez que intentábamos debug algo con console.log. Eran como dos advertencias. Estaba realmente molesto. Es como si vinieran de los paquetes. No puedo hacer nada al respecto. Aquí es donde comienza. Oh Dios, sí.
16. Patching Console.log and React Reduce Stress
Short description:
Descubrí una forma de parchear console.log y creé un script para sobrescribirlo y borrar el registro después de un tiempo específico. Es una broma divertida para molestar a tu equipo. También hice que el script no fuera buscable por console, log o clear. Siéntete libre de usarlo y compartir mejoras. Luego decidí hablar con mi equipo y parchear console.log, console.warn y console.error. Además, creé React Reduce Stress, que se lanzó hoy en la versión 2.0.
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.
17. React Advertencias de la Consola y Doble Renderizado
Short description:
Y lo que te permite hacer es que hay una API. Puedes obtener advertencias de consola suprimidas. Para los hooks, ordena una clave única en una lista, usa el controlador nativo. Tranquilidad en tu consola. El problema es que la gente no lo entiende. React y React 18 ahora se renderizan dos veces. ¿No podríamos haber hecho su experiencia más fácil? ¿Qué? Console lock habría resuelto esto. Tenemos console locks para todo, pero no para esto.
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.
18. React-reduced Stress and Conclusion
Short description:
Creé un problema en el repositorio de React sobre una advertencia, pero no recibí ninguna reacción. Sin embargo, tengo React-reduced stress, que puede ayudar a los principiantes a evitar perder tiempo. Cuenta con SMDS, un sistema de detección de modo estricto y soporte para modo oscuro. Te animo a leer la nueva documentación, unirte al grupo de trabajo, gastarle una broma a tu equipo con una actualización de console log e instalar React-reduced stress. React ha sido un viaje de aprendizaje para mí y seguiré contribuyendo.
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.
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
This Talk is about interactive data visualization in React using the Plot library. Plot is a high-level library that simplifies the process of visualizing data by providing key concepts and defaults for layout decisions. It can be integrated with React using hooks like useRef and useEffect. Plot allows for customization and supports features like sorting and adding additional marks. The Talk also discusses accessibility concerns, SSR support, and compares Plot to other libraries like D3 and Vega-Lite.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?
¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.
Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.
¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.
¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
En esta masterclass, aprenderás cómo construir tu primer dapp de pila completa en la blockchain de Ethereum, leyendo y escribiendo datos en la red, y conectando una aplicación de front end al contrato que has desplegado. Al final de la masterclass, entenderás cómo configurar un entorno de desarrollo de pila completa, ejecutar un nodo local e interactuar con cualquier contrato inteligente usando React, HardHat y Ethers.js.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Comments