Creando React Impecable: Mejores Prácticas para un Código Mantenible

Rate this content
Bookmark
Slides

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.

29 min
08 Dec, 2023

AI Generated Video Summary

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.

1. Introducción a las Mejores Prácticas de React

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2022React Summit 2022
160 min
React at Scale with Nx
WorkshopFree
The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.
We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries.