En el mundo dinámico de React, asegurarse de que su código permanezca limpio y mantenible es primordial. Sumérgete en una sesión que desmitifica las complejidades de estructurar tus proyectos de React, separando claramente las preocupaciones y adhiriéndose a las mejores prácticas que resisten el paso del tiempo. A partir de experiencias del mundo real y consejos prácticos, esta charla promete equiparte con el conocimiento para elevar tu base de código de React a la cima de la claridad y la eficiencia.
This talk has been presented at React Day Berlin 2023, check out the latest edition of this React Conference.
FAQ
Miguel Ángel Duran sugiere encapsular la biblioteca de estado con tus propios hooks para una integración más fluida, evitar el uso excesivo de useMemo y useCallback a menos que sea necesario, y mantener la gestión del estado y la lógica de negocio lo más agnósticas al framework posible.
La estructura de carpetas de la arquitectura scrimming organiza los componentes y hooks basados en características o lógica de negocio, facilitando la gestión y el mantenimiento de los hooks en proyectos grandes.
Miguel Ángel Duran compara trabajar con React con hacer una pizza, donde ambos procesos comienzan con restricciones básicas y a través de la incorporación de componentes y funcionalidades se termina con un producto finalizado, que en el caso de React sería una aplicación.
Miguel Ángel Duran opina que useMemo y useCallback solo deben utilizarse cuando sea realmente necesario, ya que su uso excesivo puede complicar la legibilidad y añadir una complejidad innecesaria sin una mejora tangible de rendimiento.
Miguel Ángel Duran sugiere considerar el uso de Million, un reemplazo del DOM virtual para React, que mejora automáticamente el rendimiento sin necesidad de cambiar o añadir código adicional.
Miguel Ángel recomienda crear hooks personalizados para encapsular la gestión del estado, lo que permite una integración más adaptable y menos intrusiva con la biblioteca de estado utilizada.
Se discuten las mejores prácticas de React, incluyendo la gestión del estado, el rendimiento de los componentes, las pruebas, la accesibilidad y la arquitectura limpia. El uso de useMemo y useCallback debe limitarse a cuando sea necesario, y herramientas como el nuevo compilador de React y Million.js pueden ayudar en la optimización del rendimiento. Las pruebas de extremo a extremo y la Biblioteca de Pruebas de React son importantes para las funcionalidades críticas. Se enfatiza la accesibilidad, y se recomienda el uso del paquete xCore/React. La lógica de negocio puede extraerse de los componentes, y se debe considerar cuidadosamente el nombre de los archivos y la estructura de las carpetas. Los alias de importación y las diferentes estructuras de carpetas pueden mejorar la mantenibilidad del código. La charla también toca la gestión de los hooks y las pruebas, y termina con una discusión sobre la pizza favorita y la presencia en línea.
React proporciona los bloques de construcción fundamentales para crear una espléndida aplicación desde cero. Trabajar con React es como hacer una pizza, incorporando todas las funcionalidades, componentes, dependencias, bibliotecas y lógica. Sin embargo, el software tiende a degradarse con el tiempo. En esta charla, compartiré las mejores prácticas, ideas y trampas comunes relacionadas con el rendimiento de los componentes, la gestión del estado, las pruebas y la accesibilidad, la lógica empresarial y la estructura del código.
Bueno, gracias. Estoy súper emocionado de estar aquí hoy. Me encanta el Día de React en Berlín. Amo Berlín. Me encanta React. Y React es increíble. Quiero decir, proporciona los bloques de construcción fundamentales para crear una espléndida aplicación desde cero, permitiéndote elegir cada ingrediente paso a paso. A veces trabajar con React, se siente como hacer una pizza. Tienes algunas restricciones básicas como sus formas y el método tradicional de construirla. Y al incorporar todas tus funcionalidades, componentes, dependencias, bibliotecas y lógica, terminas con tu pizza perfecta. Pero unos meses después, esa pizza una vez gloriosa y hermosa se transforma en esto. Sí. Pero con React, ¿quién ha experimentado esto? Levanta la mano. Casi todos. Sí. Eso es típico. Y David Lortz una vez dijo que los programas, como las personas, envejecen. No podemos prevenir el envejecimiento. Pero podríamos intentar limitar sus efectos. Así que, demasiado largo para leer la cita del blog. El software tiende a degradarse con el tiempo. En 20 minutos, estaré compartiendo las mejores prácticas, ideas y trampas comunes relacionadas con cinco temas distintos de React. Primero, hablaremos sobre el rendimiento de los componentes, la gestión del estado, las pruebas y la accesibilidad, la lógica empresarial, y finalmente, archivos, carpetas y estructura de código. Así que, en resumen, algunas mejores prácticas de React. Guten morgen. Mein name is Miguel Ángel Duran. Y esto es todo el alemán que sé. Lo siento
2. Introducción y Gestión del Estado
Short description:
Creo contenido sobre desarrollo web en YouTube y Twitch. Tengo más de 15 años de experiencia en desarrollo de software. He estado trabajando con React durante siete años. Mi último puesto fue como líder de frontend donde pasé cinco años. Di el salto de mi trabajo diario para centrarme en crear contenido en Twitch y desarrollar mis propios productos. Las mejores prácticas de hace cinco años o de hoy no son las mismas. El contexto importa. Factores como la experiencia del equipo, la estructura organizativa, las bibliotecas en uso y la necesidad de una iteración rápida juegan un papel. Pasaré por alto algunas de las mejores prácticas más comunes para las aplicaciones de React. Comencemos con la gestión del estado. Y el uso más simple del selector para extraer un estado de la tienda sería este. Nuestro componente se entrelaza con el paquete React Redux.
por los errores. Lo intenté mucho. Bitte. Creo contenido sobre web development en YouTube y Twitch. En caso de que quieras empezar a aprender español, ¿quién sabe? Puedes encontrarme en YouTube con midu.live. Un poco sobre mí. Tengo más de 15 años de experiencia en desarrollo de software. Puedo parecer joven, pero me acerco a los 40. He estado trabajando con React durante siete años. Empezando con el infame Create Class. ¿Alguien ha probado Create Class por aquí? Sí. Algunos de vosotros. Sí. Os daré un abrazo después de la charla. Afortunadamente, pasamos esa era. Mi último puesto fue como líder de frontend donde pasé cinco años. Nosotros emprendimos la importante tarea de migrar una aplicación monolítica a una nueva aplicación React. Hace un año, di el salto de mi trabajo diario para centrarme en crear contenido en Twitch y desarrollar mis propios productos. Así que, antes de empezar, porque quiero reconocer que las discusiones sobre best practices a menudo pueden encender la pasión. Quiero decir, eso es un poco genial, pero a veces incluso un poco de fanatismo. Así que, best practices de hace cinco años o de hoy no son las mismas que quizás serían en dos semanas, un mes, o un año después. Estas prácticas pueden evolucionar con el tiempo, o puede que no sean aplicables a tu caso de uso específico. Porque el contexto importa. Factores como la experiencia del equipo, la estructura organizativa, las bibliotecas en uso, la necesidad de una iteración rápida, incluso a costa de la profundidad técnica, todos juegan un papel. Así que, incluso si no estás de acuerdo con algunas de estas prácticas, lo cual está completamente bien, te animo a que mantengas la mente abierta y hagas las tuyas. Pasaré por alto algunas de las mejores prácticas más comunes para las aplicaciones de React. ¿De acuerdo? Y comencemos con la gestión del estado. Estoy bastante seguro de que conoces este logo de la biblioteca, Redux. Está en todas partes. Y en cada base de código. Y el uso más simple del selector para extraer un estado de la tienda sería este. E importamos el hook de Redux y lo usamos para acceder a una porción específica de un estado que nos interesa. Y como podríamos observar, incluso con el componente más simple,
3. Gestión del Estado y Rendimiento del Componente
Short description:
Este enfoque es manejable para proyectos pequeños o quizás proyectos de tamaño medio. Pero podría plantear desafíos a medida que el proyecto se amplía. Un consejo para las mejores prácticas en React sería tomar tu biblioteca de estado con tus propios hooks. Es mejor encapsular tu biblioteca de estado. Crea un hook personalizado que se centre en los datos en sí. No dejes que tu biblioteca se filtre en todos tus componentos. Evita este tipo de hooks personalizados de user store, use local storage, use Fetch, y en su lugar, céntrate en tus datos. Y nombra tus hooks personalizados para cambiar la implementación. Ahora hablando sobre el rendimiento del componente, useMemo y useCallback están diseñados como herramientas de optimización de rendimiento para las aplicaciones de React. Pero diría que sólo deben ser utilizados cuando sea realmente necesario.
componente más simple, nuestro componente se entrelaza con el paquete React Redux. Este enfoque es manejable para proyectos pequeños o quizás proyectos de tamaño medio. Pero podría plantear desafíos a medida que el proyecto se amplía. Si quieres cambiar a Sustan, alguien podría pensar en usar reemplazo final, pero no es tan fácil. Porque tienes un montón de resultados. Y tiene algunas desventajas. Porque podrías pasar por alto algunos archivos. Es un proceso manual. Un montón de cambios de archivos. E incluso quizás es demasiado complejo. Porque algunos componentes como este, es incluso para un componente pequeño, está abarrotado con numerosas referencias a Redux. Así que, un consejo para las mejores prácticas en React sería tomar tu biblioteca de estado con tus propios hooks. Es mejor encapsular tu biblioteca de estado. Porque entonces y esto es aplicable a cualquier biblioteca. Porque asegura una integración más fluida y adaptable de la gestión del estado dentro de tu aplicación. Así que, obviamente, podrías crear un hook personalizado, y eso sería algo así. Y lo más importante no es incluso el hook personalizado, sino el nombre de este. Porque si te fijas en el nombre del hook, no especifica cómo o de dónde estamos extrayendo los datos. Sino que se centra en los datos en sí. Y cuando lo estamos utilizando, estamos eliminando cualquier especificación de Redux. E incluso si revisamos el ejemplo más complejo en esta instancia, la mejora va a ser significativa. Pasamos de esto, que está super abarrotado con código de Redux, a algo como esto. Ahora es comprensible. No le importa de dónde estoy obteniendo los datos. Y se está centrando en unas pocas líneas de código. Así que, no dejes que tu biblioteca se filtre en todos tus componentes. Evita este tipo de hooks personalizados de user store, use local storage, use Fetch, y en su lugar, céntrate en tus datos. Y nombra tus hooks personalizados para cambiar la implementación. Y ni siquiera tienes que ir a cada uno de tus componentes para pasar de una biblioteca a otra. Ahora hablando sobre el rendimiento del componente, useMemo y useCallback están diseñados como herramientas de rendimiento optimización para las aplicaciones de React. Pero diría que sólo deben ser utilizados cuando sea realmente necesario.
4. Optimizando el Rendimiento y las Pruebas
Short description:
El uso excesivo de useMemo y useCallback puede complicar la legibilidad y añadir una complejidad innecesaria sin mejoras significativas de rendimiento. El nuevo compilador de React, en desarrollo, tiene como objetivo memorizar automáticamente los componentes y funciones. Otra opción es Million, un reemplazo del DOM virtual para React que ofrece mejoras automáticas de rendimiento sin cambios de código. El perfilado de las herramientas de desarrollo es crucial para identificar los componentos re-renderizados y evaluar su coste. En cuanto a las pruebas y la accesibilidad, las pruebas de integración son esenciales.
cuando sea realmente necesario. Y quiero decir, muchas veces en mi última empresa, teníamos mucho código como este. Están utilizando el hook useMemo para evitar recrear publicaciones en cada renderizado si la publicación permanece sin cambios. Y este enfoque podría tener sentido a veces para algunos casos específicos. Pero el problema es que a veces encontrarás algo como esto dentro de un componente. El problema surge porque el mismo componente está utilizando un useCallback y useMemo cuatro veces. Y este uso excesivo complica la legibilidad, añade una complejidad innecesaria, y en algunos casos no resulta en una mejora tangible de performance. Entonces, ¿qué podemos hacer? Podríamos esperar a React olvidar el nuevo compilador en el que el equipo de React está trabajando. Todavía está en desarrollo. Fue anunciado en 2021. Y está diseñado para memorizar automáticamente nuestros componentes y funciones. Hace tres meses, compartieron una pequeña actualización de que todavía están trabajando en ello. No sé si va a ser lanzado algún día. Pero otra posible solución podría ser considerar el uso de Million. Million es un reemplazo del DOM virtual para React. Y no necesitas cambiar o añadir complejidad y luces de código en tu base de código. Pero en cambio, ofrece una mejora significativa de performance automáticamente. Entonces, compila. Actúa como un envoltorio en algunos componentos. Y mejora su performance. Y no tienes que cambiar nada. No tienes que añadir useMemo o useCallback. No hace lo mismo. Pero la mejora de performance es considerable. Lo que quiero compartir es este tipo de frase que es súper importante. La optimization primitiva es la raíz de todo mal. El consejo aquí es que tienes que perfilar desde las herramientas de desarrollo para identificar qué componentes están siendo re-renderizados. Pero no sólo eso, sino también comprobar el coste de ello. Porque a veces, incluso si tarda un milisegundo o incluso menos, no tiene sentido poner más código para intentar solucionar algo que no es un problema. Hablando de testing y accessibility, considera una aplicación utilizando Amazon como ejemplo. Si estuvieras limitado a realizar sólo un tipo de testing, ¿cuál sería? Necesitas
5. Pruebas de extremo a extremo y React Testing Library
Short description:
La implementación de pruebas de extremo a extremo en su aplicación es crucial para las funcionalidades críticas. Herramientas como Playwright ofrecen características impresionantes, como una extensión de Visual Studio Code que genera código mientras navegas por tu sitio web. La API es similar a React Testing Library, que se considera la mejor API para probar aplicaciones de React.
pruebas de integración. La elección obvia sería una prueba de extremo a extremo. Si solo tienes una prueba en tu aplicación, debería ser una prueba de extremo a extremo. Y actualmente, no hay excusa para no implementar alguna prueba de extremo a extremo en tu aplicación para funcionalidades críticas. Hoy en día, estas pruebas son más rápidas que hace algunos años y son más asequibles. Y tenemos algunas herramientas como Playwright que son impresionantes. Por ejemplo, tienen esta extensión de Visual Studio Code, donde abres tu sitio web y mientras estás navegando por tu sitio web y estás probando tu aplicación, entonces está escribiendo todo el código para ti. Y incluso la API es súper impresionante porque es muy similar a React Testing Library que creo y encuentro que esta es la mejor API para testing para aplicaciones de React.
6. Accesibilidad e Informes
Short description:
Muchas veces la gente no se preocupa por la accesibilidad. Mi recomendación sería instalar el paquete xCore/React. Es muy fácil de entender y configurar. Puedes crear un método para informar sobre problemas de accesibilidad y obtener información detallada sobre los problemas en el registro de la consola.
Y también sobre la accessibility, muchas veces la gente no se preocupa por la accessibility. A veces es porque somos, no sé, ignorantes, tal vez nos falta información sobre cómo solucionar esas cosas. Mi recomendación sería instalar este paquete, xCore slash React. Es muy fácil de entender. Va directo al grano. Y te mostraré cómo configurar y la información que vas a obtener. Podrías crear un método para informar problemas de accessibility como este. Lo único es que se va a ejecutar en el cliente y en modo de desarrollo. Y estamos usando una importación dinámica para importar solo esas dependencias para el desarrollo. Así evitamos agregar el paquete al paquete de producción, estos paquetes. Luego, en tu punto de entrada, deberías usar este nuevo método, dos líneas de código, informar sobre accessibility, y luego pasar la instancia de React realmente al método. Y esa es la información que vas a obtener. Vas a obtener en la consola log, vas a obtener algunos problemas, problemas serios, problemas moderados, y no solo los problemas típicos que podrías encontrar en el Lighthouse, que son geniales, pero algunos más interesantes incluso para la semántica del HTML, los roles de área que faltan, y mucho más.
7. Lógica de Negocio y Arquitectura Limpia
Short description:
Normalmente, si vemos un use effect en un componente, podría ser una señal de algo. No siempre, no es una bala de plata, pero podría ser un indicador de que podría ser una refactorización en un hook personalizado. A veces los hooks personalizados no son suficientes, al menos para aplicaciones más grandes, para aplicaciones empresariales. Entonces, la idea sería extraer tu lógica de los componentes. La arquitectura limpia podría tener sentido si estás trabajando en una empresa muy grande. Podría ayudar a probar nuestra lógica de negocio sin la necesidad de pensar en React. La lógica de negocio es lo que te está generando dinero. Podrías mover tu lógica de negocio a una biblioteca diferente, incluso para diferentes dispositivos, aplicaciones, etc.
Hablando de lógica de negocio, normalmente, si vemos un use effect en un componente, podría ser una señal de algo. No siempre, no es una bala de plata, pero podría ser un indicador de que podría ser una refactorización en un hook personalizado. Este es un ejemplo típico de uso de use effect, y podríamos extraerlo a un hook personalizado. E incluso podríamos ir más allá usando use query de React query para evitar la necesidad de manejar manualmente los estados para loading error y data. Pero a veces los hooks personalizados no son suficientes, al menos para aplicaciones más grandes, para aplicaciones enterprise. Entonces, la idea sería extraer tu lógica de los componentes. Entonces, una idea sería que tenemos este hook personalizado, use real states, estamos obteniendo estados reales, pero considera este escenario, un hook personalizado que está cargado con numerosas responsabilidades, como la validation de los data, de la entrada, la obtención de data, y el mapeo. Y lo que es aún peor es cuando intentamos extraer la lógica de nuestros componentes de React, y terminamos haciendo algo como esto. Parece que es mejor, pero el problema es que estamos pasando como parámetros una forma de actualizar nuestro estado local. Entonces, nuestra lógica debería ser agnóstica al framework, y esto no lo es. Esto sería un poco mejor. Tenemos algo que es completamente agnóstico a React. Entonces, podríamos usar esto para React Native, Vue, Angular. Bueno, tal vez no para Angular, porque no usamos Angular. Pero para cualquier framework, incluso para vanilla JavaScript. Pero podrías dar un paso más usando la arquitectura limpia.
A veces la arquitectura limpia podría tener sentido si estás trabajando en una empresa muy grande. Si solo sois un equipo de tres, tal vez no. Podría ser nuestro ingeniero. Pero en una empresa con cientos de desarrolladores, podría tener sentido crear objetos de valor y entidades basadas en el diseño específico del dominio. Interfaces de repositorio para poder cambiar de tu repositorio de Apple, o tal vez repositorio de almacenamiento local, o directamente a repositorio de database. Podrías crear tu propio repositorio de API. E incluso crear un servicio que podrías inyectar si estás usando el repositorio de API o un repositorio de mock. Esto es genial. Esto está ayudando a probar nuestra lógica de negocio sin la necesidad de pensar en React. La lógica de negocio es lo más importante que vas a tener. Porque React, espero que vaya a estar vivo durante unos años más. Pero la lógica de negocio es lo que te está generando dinero. Y podrías mover tu lógica de negocio a una biblioteca diferente, incluso para diferentes dispositivos, aplicaciones, etc. ¿Y has visto esta imagen en Twitter, verdad?
8. Acciones del Servidor y Nomenclatura de Archivos
Short description:
La cadena mágica useServer te permite extraer acciones del servidor a un archivo diferente, haciéndolas invisibles para el paquete del cliente. Es crucial tener en cuenta la nomenclatura de archivos y la estructura de carpetas para evitar errores sutiles, especialmente en sistemas basados en Linux. Los sistemas Unix distinguen entre mayúsculas y minúsculas, mientras que los sistemas Mac no, por lo que es mejor usar camelCase para nombres de archivos y carpetas, incluso para componentes de React.
fue el meme. Y el problema con este tipo de imagen es que carece de contexto. Esta es la posibilidad que podrías hacer con Next.js ahora, con React, con las acciones del formulario. Pero lo cierto es que puedes extraer esto a un archivo diferente. No estás obligado a hacer esto en línea dentro del botón. En este caso, puedes extraer toda la lógica de las acciones del servidor. Y podrías hacer algunas validaciones. Podrías hacer de todo. Y lo único importante es que uses la cadena mágica useServer en el archivo. Y entonces se vuelve invisible para el paquete del cliente. Lo último son los archivos, carpetas y la estructura del código. Es súper interesante porque hay toneladas y toneladas de artículos en el internet hablando de esto. Y es normal porque es un desafío. Es súper importante sobre el contexto de cada aplicación. Y porque cada uno tiene una opinión diferente de ello. Pero una cosa que es, para mí, súper, súper importante. Si revisas este código, parece estar bien. Pero hay un error sutil que podría hacer que tu sistema de integración continua falle, particularmente si está basado en Linux. Y es súper difícil de ver. Y yo sé, por experiencia, que podría llevar horas obtener el error. El problema con este código es este. Lo que pasa es que los sistemas Unix distinguen entre mayúsculas y minúsculas, mientras que los sistemas Mac, que es el que estamos usando, excepto este que está usando Adele, no distinguen entre mayúsculas y minúsculas. Así que mi consejo sobre esto es evitar camelCase para nombres de archivos y carpetas. Prefiere camelCase incluso para los componentes de React. Y sé que esto no es popular. Lo sé. Mucha gente ahora está tomando fotos. Lo sé. Pero pensé, hace algunos años, que el caso perfecto para los componentes de React era Pascal case. Y después de eso, estuve revisando muchos repositorios en GitHub sobre proyectos populares como Next.js. Y están usando camelCase
9. Alias de Importación y Estructura de Carpetas
Short description:
Si no te gusta Next.js, para mí no es negociable. Siempre utiliza alias de importación para mejorar la mantenibilidad del código. Utiliza una estructura de carpetas diferente para proyectos grandes y enormes. Tu arquitectura debe informar a los lectores sobre el sistema en sí. No tengas miedo de cambiar de opinión. Echa un vistazo a Advent.js, un calendario de Adviento con desafíos para JavaScript y TypeScript.
para todos sus archivos, incluso los componentes de React. Y si no te gusta Next.js a ti mismo, porque no sé, Peanuts, incluso remix en el repositorio de componentes, están usando camelCase. Y no es por eso que lo inventaron. Quiero decir, hay una razón detrás de esto. Así que, sé que podría ser difícil. Pero para mí, no es negociable. Otra cosa es siempre usar alias de importación para mejorar la mantenibilidad del código. Los alias de importación te permiten evitar el uso de rutas relativas en tus importaciones. Así que este tipo de código que es súper difícil de leer y entender de dónde vienen, vienen de esto a esto. Es mucho más claro utilizando alias de importación. Y finalmente, hablando de la estructura. Esta es la estructura clásica de carpetas. Quiero decir, está bien. Es bueno para muchas cosas. Es perfecto para proyectos pequeños y medianos. Pero cuando las cosas se hacen más grandes, es difícil de escalar. Esta es una estructura de carpetas diferente que es súper interesante para proyectos grandes y enormes. Y es que tu arquitectura debería informar a los lectores sobre el sistema en sí, en lugar de los frameworks y dependencias que estás utilizando. En la clásica, incluso tienes una carpeta que se llama Redux. Así que, en este caso, si estás, no sé, construyendo un sistema de salud, entonces los nuevos programadores ven el repositorio de código fuente, y su impresión inicial debería ser, oh, este es un sistema de salud. Algunas desventajas, por supuesto. La curva de aprendizaje es complicada. La sobrecarga inicial, el riesgo de duplicación, porque tal vez duplicas algunos componentes. Pero al final, para proyectos enormes es imprescindible. En 20 minutos, es complicado hablar de todas las mejores prácticas en React. Intenté compartir algunas, basándome en mis conocimientos y mi experiencia. Pero lo más importante es que no tienes que tener miedo de cambiar de opinión. Para mí, por ejemplo, fue como el caso de los sistemas de archivos o componentes en las aplicaciones de React. Y a veces sólo se trata de comprobar, intentar e intentar de nuevo. Antes de irnos, una cosa más. Me gustaría invitarte a que eches un vistazo a Advent.js, un calendario de Adviento con desafíos para JavaScript
QnA
Arquitectura y Gestión de Hooks
Short description:
Disponible en inglés, portugués y español. Pero si me pides que lo traduzca al alemán, lo haré. Una cosa que encuentro interesante de tu charla es que te sumergiste en algunas cosas reales que la gente puede simplemente cambiar en sus archivos, en su código directamente. Especialmente cuando hablas de arquitectura, pienso en algunas personas que trabajan en pequeñas y medianas empresas, algunas personas trabajan en grandes empresas con cientos de desarrolladores, y tienen diferentes necesidades. Y especialmente para el tipo de pequeñas y medianas empresas, ¿es esta a veces arquitectura? ¿Es una sobreingeniería? ¿Estamos poniendo más esfuerzo en construir cosas que son más grandes que los requisitos que tenemos? Tenemos otra pregunta. La pregunta más votada con mucha gente preguntando es, ¿cómo gestionas tus hooks? Es muy fácil crear cientos de hooks personalizados siguiendo algunos de estos consejos.
y TypeScript, desarrollado con React, por supuesto. Disponible en inglés, portugués y español. Pero si me pides que lo traduzca al alemán, lo haré. Bueno, no lo estoy haciendo. Es un poco difícil. Pero gracias.
Lo que voy a hacer, por cierto, es que voy a guardar las preguntas divertidas para el final, ¿de acuerdo? Y empezaremos con las preguntas técnicas primero. Pero una cosa que encuentro interesante de tu charla es que te sumergiste en algunas cosas reales que la gente puede simplemente cambiar en sus archivos, en su código directamente. Y luego hablaste de algunas ideas y temas arquitectónicos más amplios. Y especialmente cuando hablas de arquitectura, pienso en algunas personas que trabajan en pequeñas y medianas empresas, algunas personas trabajan en grandes empresas con cientos de desarrolladores, y tienen diferentes necesidades. Y especialmente para el tipo de pequeñas y medianas empresas, ¿es esta a veces arquitectura? ¿Es una sobreingeniería? ¿Estamos poniendo más esfuerzo en construir cosas que son más grandes que los requisitos que tenemos? Absolutamente. Quiero decir, quería compartir mi experiencia trabajando en un proyecto enorme, porque creo que es importante. Y normalmente no hablamos de ello. Y usamos una arquitectura limpia en el lado del front-end, lo cual no es común. Pero obviamente, no recomiendo a las personas de una pequeña empresa, tres personas en el equipo, 15 personas. Tal vez no valga la pena. Pero incluso así, podrían intentar separar la lógica en un archivo, agnóstico del framework. Y eso, seguro, va a ayudar. Es súper fácil, barato. Es menos de un minuto. Y podría ayudarte a intentar probar mejor, compartir esta lógica con otros componentes, o tal vez incluso moverte a una aplicación React nativa y usar esa lógica. Y es como un minuto de eso. Y creo que eso es lo bueno de la arquitectura limpia, es que se derrama en todos los demás aspectos. Como tus pruebas te lo agradecerán. Si necesitas ir cross-platform, te lo agradecerán y todas esas cosas. Así que gran respuesta. Gran respuesta. Tenemos otra pregunta. La pregunta más votada con mucha gente preguntando es, ¿cómo gestionas tus hooks? Es muy fácil crear cientos de hooks personalizados siguiendo algunos de estos consejos. Así que vamos a tener muchas diferentes charlas. Muchas personas diferentes van a presentar diferentes hooks que la gente
Gestión de Hooks y Million.js
Short description:
La idea de la estructura de carpetas de la arquitectura scrimming facilita la creación y gestión de hooks. Million.js tiene algunos problemas de compatibilidad y requiere añadir un array de componentes a excluir. Ofrece un reemplazo directo para los internos de React. El desarrollo guiado por pruebas es útil en algunos casos, pero no es necesario todo el tiempo.
debería usar. ¿Cómo gestionas todos ellos? Sí. Gran pregunta. Por eso quería introducir la idea de la estructura de carpetas de la arquitectura scrimming. Porque si no, tienes una carpeta llamada hooks. Y tienes como 100 hooks dentro. Entonces tienes que comprobar como, OK, ¿dónde está el que necesito? O voy a duplicar algunos. Así que la idea con la estructura de carpetas de la arquitectura scrimming es que, a medida que gestionas los componentes de hooks o algo más, basado en tus características o tu lógica de negocio, va a ser más fácil crear y gestionar esos hooks. Lo entiendo totalmente. Y la siguiente es, creo que me perdí esto en tu código, pero ¿cuál es el problema con Million.js? ¿Puedes reemplazarlo sin ningún error? Entonces, sí, por supuesto, hay un problema. Un problema es que no es 100% compatible. Hay algunos casos especiales. Por ejemplo, tienes que añadir un array de componentes a excluir para evitar usarlo en todas partes, porque podría ser problemático. Y el otro problema es que estás añadiendo una nueva dependencia. Quizás hay algún coste en el tiempo de compilación, tiempo de construcción. Pero aparte de eso, el problema es que me encanta React. Pero el DOM virtual e incluso algunos internos de React, son un poco antiguos. Y es muy fácil crear un reemplazo directo mejor que algunos internos que tenemos de React. Me encanta React, pero ya tiene algún tiempo.
Absolutamente. Definitivamente hay algunas cosas que sólo tienen sentido en el ecosistema de React, y que no tienen sentido en ningún otro lugar. Tenemos otra pregunta, y esta es sobre el desarrollo guiado por pruebas. ¿Qué opinas sobre ello? Me encanta el TDD. Pero para mí, no hay una bala de plata. Sé que hay personas que sólo desarrollo usando el desarrollo guiado por pruebas. A veces lo uso, especialmente para la lógica, porque podría crear la lógica, devolver el JSON directamente, y luego ir hacia atrás tratando de hacer pasar la prueba y así sucesivamente. Pero no sé. Depende. Algunos días quiero probar el TDD y usarlo. Y a veces soy más creativo, y trato de crear el componente. Así que creo que podría ayudar en algunos casos, pero me gustaría usarlo sólo cuando tenga sentido, no el 100% del tiempo.
Pruebas, Herramientas y Pizza
Short description:
Escribir pruebas tiene su propio ecosistema de errores y fallos que no son de tu código. Zustand es genial para proyectos pequeños, mientras que Redux Toolkit es mejor para los más grandes. La API de Contexto puede ser utilizada para estados estáticos. Cada solución tiene sus desventajas y ventajas. Pasemos a algunas preguntas divertidas. ¿Por qué no paella? La pizza es más universalmente entendida. ¿Cuál es tu pizza favorita? Mientras no tenga piña, cualquier pizza es aceptable. Mi favorita es la de pollo con chocolate.
Sí, totalmente. Estuvimos en el TestJS Summit ayer, y es realmente interesante cómo escribir pruebas tiene su propio ecosystem de errores y fallos que no son de tu código. Tu código podría estar bien, y luego las pruebas tienen un problema, lo cual es realmente interesante. Y no hay una solución mágica. Es la clásica respuesta de que depende. Depende, sí.
Por supuesto, por supuesto. Tenemos otra. Esta es más sobre herramientas y kits de herramientas. ¿Por qué Zustand en lugar de Redux Toolkit? Entonces es lo mismo. Depende. Quiero decir, incluso ¿por qué no la API de Contexto? La API de Contexto podría tener sentido para un estado que no va a cambiar a menudo para algo que es estático. Zustand es genial, por ejemplo, para tiendas pequeñas, proyectos pequeños. Si se hace más grande, Redux Toolkit, lo bueno que tienes, es una gran documentation, una gran community. Ahora tienes inmutabilidad que también es genial. El problema es que es más grande, pero quiero decir, hay desventajas y cosas buenas de cada solución.
No, totalmente. Bueno, nos queda menos de un minuto para terminar. No podré pasar por más de las preguntas técnicas, pero vamos a pasar por algunas de las divertidas. Elegiste pizza. ¿Por qué no paella? Es más complicado compartir un chiste sobre la paella aquí porque tal vez la gente va a pensar que la paella es genial en cada foto. No importa. Pero en la pizza, no es normal tener pollo. Tal vez consigues un pollo y tal vez la gente piensa que eso es normal. Estoy bastante seguro de que hay algunos italianos que estaban gritando internamente en la pantalla cuando vieron esa foto. Hablando de eso, ¿cuál es tu pizza favorita? Vaya, eso es complicado. Por favor, siempre y cuando no tenga piña. Si hay alguna respuesta correcta, acepta esa.
Pizza Favorita y Presencia en Línea
Short description:
Mi pizza favorita es la sobrassada, que es como mantequilla con miel y queso. Para más información, consulta la sección de preguntas y respuestas del orador y la sala de discusión. Puedes encontrarme en línea en Middle-def en todas partes.
No, no. Mi pizza es de pollo con chocolate. No, no, no. Mi pizza favorita es una especial porque es sobrassada. No sé la palabra en inglés, pero es como una especie de pepperoni, pero es como mantequilla con miel y queso. Genial. Nos hemos quedado sin tiempo, pero la gente quiere saber más. Alguien estaba preguntando sobre el GitHub. Pueden encontrarte en la sección de preguntas y respuestas del orador y la sala de discusión. Genial. ¿Y dónde pueden encontrarte las personas en línea? Middle-def en todas partes. Muy bien, búscalo. Dale un aplauso. Gracias.
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
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.
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
This Talk focuses on effective React state management and lessons learned over the past 10 years. Key points include separating related state, utilizing UseReducer for protecting state and updating multiple pieces of state simultaneously, avoiding unnecessary state syncing with useEffect, using abstractions like React Query or SWR for fetching data, simplifying state management with custom hooks, and leveraging refs and third-party libraries for managing state. Additional resources and services are also provided for further learning and support.
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
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 🤐)
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.
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
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo. Puntos Cubiertos: 1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso Cómo Ayudará a los Desarrolladores: - Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Comments