1. Introducción a las Mejores Prácticas de React
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
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
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
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
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
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
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
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
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 Arquitectura y Gestión de Hooks
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
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
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
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.
React Summit 2023
