El Arte de las 'Vistas Humildes': Probando Aplicaciones React Native de Manera Inteligente

♪♪♪ Hola a todos. Muchas gracias, Nathaniel. Esa fue sinceramente una introducción muy, muy amable. Me siento humilde. Vamos. Bueno, los chistes de papá no caen muy bien aquí. Bueno saberlo. Bien, de acuerdo. Así que hoy estoy muy emocionado de estar en Berlín con todos ustedes. Es mi primera vez en la ciudad, y es tan estéticamente agradable. Las vibraciones son sinceramente impecables, especialmente con la nieve. Estoy muy emocionado de hablar sobre este concepto de vistas humildes. Vamos a ver cómo puedes arquitecturar tus aplicaciones de React y React Native para, con suerte, facilitar un poco las pruebas y también hacer que tus aplicaciones sean más escalables.

Un poco sobre mí. Como mencionó Nathaniel, mi nombre es Mo. Dirijo el equipo móvil en el Reino Unido para Theodo. Así que Theodo es una consultoría global con más de 700 expertos digitales, 150 de los cuales hacen React Native y React. Así que hemos estado haciendo React y React Native desde los primeros días de su aparición. Y como resultado, hemos pasado por fases de evolución y hemos visto diferentes bases de código y hemos visto diferentes patrones e intentado encontrar los que duran mucho tiempo y son escalables y esperamos poder compartir algo de eso con ustedes hoy.

Así que las pruebas son un tema polémico. La gente suele caer en dos campos. Si sigues la ruta del artesano del software, te encuentras con gente como Bob Martin, que cree firmemente que debes apuntar a un 100% de cobertura de pruebas, que una alta cobertura de pruebas es la piedra angular de una buena base de código. Así que esta es la visión tradicional, y esta es la visión que te dirá el artesano del software. Más recientemente, por otro lado, tienes a los influencers de YouTube en el espacio de la codificación que te dirán, ¿sabes qué? No he estado probando durante años y he sido muy rápido, nunca podrás alcanzarme. Trabajé en Twitch, confía en mí, hermano. Y entonces obtienes estos diferentes puntos de vista y tienes gente que está vehementemente en contra de las pruebas y tienes gente que está muy, muy a favor de las pruebas. Y así, como con muchas cosas en la vida estos días, las cosas se polarizan al extremo. A la izquierda, tienes a la gente que dice, no pruebes. Y si pruebas, nunca más me hables. Y luego a la derecha, tienes gente que dice, tu código es malo, deberías estar probando cada parte de él.

Y realmente, lo que sucede es que tienes esta tierra de nadie de testing en el medio donde se pierde toda la sutileza. Y a veces se lanzan tomates desde ambos lados. Pero realmente, no se tienen muchas conversaciones matizadas en torno a un enfoque pragmático de testing. Y me considero un poco centrista. No defiendo nada. Así que mi objetivo es molestar a ambas partes con una charla. Veremos cómo va esto.

Permíteme establecer un poco el escenario. Así que hace un par de años, estaba trabajando en un proyecto de React Native en la industria de la moda. La aplicación iba a ser utilizada en almacenes donde iban a escanear artículos de ropa con un escáner de códigos de barras dentro de la aplicación. Y almacenaría alguna información. Podrían introducir información sobre el artículo de ropa. Y estaba siendo utilizado por la oficina de atrás, efectivamente. Había una desarrolladora en mi equipo que estaba trabajando mucho en las cosas de front end. Y en un momento me dijo, estoy intentando escribir una prueba para el escáner de códigos de barras. Básicamente, lo que quiero probar es que cada código de barras tiene un checksum. Los últimos dígitos serán una suma de algunos de los valores en el medio en alguna fórmula matemática. Así que quiero probar eso. Pero el desafío que encontró fue que necesitaba hacer mucha configuración antes de que pudiera realmente probar eso al renderizar la pantalla. ¿Y a qué me refiero con eso? De hecho, extraje el código y verás lo horroroso que es en solo un segundo. Pero esta pantalla inicialmente tenía un montón de contextos diferentes. Y realmente no los necesitábamos para la pantalla en sí. Pero necesitaba ser simulado para que pudieran seguir adelante y probarlo. Genial. Así que eso es un montón de simulacros. Luego, algunos de los clientes necesitaban ser simulados para las solicitudes de fetch. El escáner de códigos de barras de Expo, que era una biblioteca externa que utiliza el dispositivo nativo, también necesitaba ser simulado porque no tienes acceso a eso en las pruebas unitarias. Tu marco de navegación en la capa nativa necesitaba ser simulado. Bien. Eso es más simulacros.

Después, queríamos espiar alert, que es la funcionalidad de alerta nativa dentro de React Native. Otra funcionalidad. Y luego simplemente continuó una y otra vez. Es como tantos simulacros antes de que realmente pruebes lo que fundamentalmente querías probar, que es la lógica de negocio central, ¿verdad? Realmente no es un buen estado del arte cuando estás testing de esta manera.

Y entonces ella me hizo una muy buena pregunta, que fue, ¿siempre tiene que ser tan difícil? Y me hizo pensar en la arquitectura general de nuestro código, ¿verdad? Y conduce a una muy buena pregunta, que es, ¿qué es la arquitectura de código? Y realmente me gusta esta definición. Así que la arquitectura son las decisiones que desearías poder acertar al principio de un proyecto. Es una cita de Ralph Johnson, que es profesor de ciencias de la computación en los Estados Unidos. Ha escrito varios libros sobre buena arquitectura de software.

Y uno de los conceptos fundamentales que aprenderás dentro de la arquitectura de software es esta idea de separación de preocupaciones, ¿verdad? Así que esta idea con la separación de preocupaciones es que puedes tomar diferentes componentes dentro de tu aplicación y tratas de dividirlos en modules o trozos individuales que son cada uno individualmente responsable de un solo trabajo distinto. Y pueden hacer eso independientemente de todas las demás partes. Esa es la teoría. Así que los ejemplos que obtienes es como la división de HTML, CSS, JavaScript en la web tradicional o la pila IP, que está en casi todos los libros de texto de ciencias de la computación, que es como, tienes todas estas capas en la pila de red, y luego puedes sacar una y reemplazar con algo más. Y en teoría, el resto del sistema debería funcionar bien.

Ahora estamos en el mundo de React, y React está un poco en desacuerdo con la separación de preocupaciones. ¿Qué quiero decir con eso? Así que el punto de venta fundamental de React y la premisa de JSX se basan realmente en violar la separación de preocupaciones. Es esta idea de que puedes traer tu marcado a tu capa de interactividad, empezar a escribir sintaxis similar a HTML para representar tu interfaz de usuario dentro de JavaScript. Así que viola esa antigua mentalidad tradicional de separación de preocupaciones, que tu HTML hace tu marcado, tu JavaScript hace tu interactividad, y tu CSS hace tu estilo. Y el resto del ecosystem sigue el ejemplo. Tienes bibliotecas como componentes de estilo, que te permiten hacer tu estilo dentro de tu JavaScript también, este concepto completo de CSS y JS. Así que estamos juntando todas estas cosas. Y esto es genial, por cierto. No estoy negando el hecho de que esto es en realidad una gran adición para tener como marco, porque hace las cosas mucho más rápidas y mucho más fáciles de entender con esta mentalidad basada en componentes. Lo que significa es que puedes poner todo en un solo lugar y todo simplemente funciona. Así que tengo el ejemplo de contador más básico que puedes pensar. Está en React Native, pero es lo mismo con React. Tienes en la parte superior tu interactividad. Así que son los estados usados que tienes, las devoluciones de llamada que tienes para incrementar el contador. Pero en la parte inferior tienes tu capa de presentación, así que tienes tu marcado y tu estilo. Y si añades un marco de estilo como Tailwind a ello, básicamente tienes tu estilo, tu marcado, así que tu estructura de interfaz de usuario así como tu interactividad todo en un solo archivo. Así que la separación de preocupaciones se vuelve un poco más confusa allí.

Tómalo... No se supone que debas leer este código, por cierto. No lo intentes. No tiene sentido. Pero la idea aquí es que si añades un poco más de funcionalidad y la mantienes dentro del mismo componente, solo con buscar el nombre de un artículo y tener el botón para volver a buscar, estos archivos se vuelven cada vez más y más grandes. A medida que empiezas a hacer estos componentes más y más complejos, las testing también se vuelven más difíciles porque estás añadiendo todas estas diferentes dependencias en un solo componente o una sola pantalla. Y este es, con mucho, el mayor desafío que la gente enfrenta, creo, cuando están diseñando su architecture. Y es que React en realidad no te impide crear estos grandes componentes que no están correctamente modularizados. Terminas, de alguna manera, pintándote a ti mismo en un rincón si no estás pensando conscientemente en cómo divides tus límites de componentes dentro de React.

Así que vamos a quemar esto y ver a dónde va realmente. Un síntoma habitual que he visto en los códigos, y hemos estado yendo a muchos diferentes códigos brownfield que ves en la naturaleza, es que tienes estos archivos masivos de React con cientos o en algunos casos extremos incluso miles de líneas. Y en la mayoría de los casos, estos componentes también resultan infernales para probar. Así que esto no es un problema nuevo. La gente ha estado construyendo GUIs desde la década de 1980, ¿verdad? ¿Cómo lidiaron con esto cuando las testing eran un desafío? Si volvemos al tablero de dibujo y damos un paso fuera del mundo de JavaScript, ha habido mucho trabajo realizado por personas en otros lenguajes y otros frameworks para mirar el espacio arquitectónico y abordar algunos de estos problemas. Así que podrías haber oído términos como Modelo-Vista-Controlador, podrías haber oído el término llamado HumbleObject, en el que vamos a profundizar un poco más hoy. El Modelo-Vista-Presentador, su primo muy cercano, el Modelo-Vista-ViewModel, todos estos grandes nombres, ¿verdad? Te encantará este. ¡Mira eso! El View-Interactor-Presenter-Entity, es muy pegadizo. Viper, para abreviar. Ahora no vamos a entrar en todos estos, vamos a profundizar en dos patrones arquitectónicos patterns que creo que son realmente útiles en el espacio de React. Comencemos con el modelo HumbleObject.

Así que digamos que tenemos un componente y quieres probar realmente este componente. Un componente típico de React puede tener muchas cosas dentro de él. En un nivel, puedes tener código de infraestructura. ¿Qué queremos decir con eso? Está buscando cosas. Son servicios externos. Quizás estás llamando a Sentry, quizás estás llamando a Google Analytics, todos pueden vivir dentro de un componente y a veces encontrarás que lo hacen en la naturaleza. Puedes tener lógica de negocio, cosas como Transformadores, reglas que puedes tener en tu código, diferentes flujos de lógica. Puedes tener estado de la interfaz de usuario y lógica que está inherentemente relacionada con la renderización. Así que esos son tus campos de formulario, tus reglas de validation, y así sucesivamente, quizás alguna interactividad que entra en juego. Y por último, tienes el JSX real y el estilo.

El modelo HumbleObject intenta ayudar con este problema que puedes tener, que es cuando intentas probar este componente en su totalidad, es realmente bastante complejo. Porque necesitas simular un montón de cosas, simular tus dependencias externas, y tal vez no quieras probar todo esto. Si pensamos en lo que realmente nos importa testing a nivel básico y fundamental, realmente queremos probar la lógica de negocio más que cualquier otra cosa. En el caso de nuestro escáner de códigos de barras, lo que nos importa testing es asegurarnos de que la función de suma de comprobación funciona bien. Que si hay un duplicado, y dos códigos de barras coinciden entre sí, lanzamos una excepción y lanzamos una regla de validation.

Entonces, lo que dice el modelo HumbleObject es, saca eso del componente y sepáralo en su propio módulo o archivo o lo que sea. Y coloca tu lógica de negocio, coloca las partes importantes de tu lógica dentro de eso. Y en lugar de testing el componente real directamente, puedes probar el HumbleObject. Y cuando lo pruebas, es mucho más simple y hay mucho menos dolor asociado a ello. Así que vamos a ver un ejemplo de codificación para esto. Y ver un antes y un después.

Genial. Muy bien. Así que tenemos una configuración de aplicación muy básica aquí. Es una página de pago de preparación de comidas. No está muy bien diseñada, pero básicamente tienes una página de pago y tiene alguna lógica añadida. Así que tienes algún nivel de descuentos. Si tu total acaba siendo más de $50, obtienes un descuento. Así que puedes ver que una vez que caigo por debajo de $50 y estoy en $37, los descuentos desaparecen. Y puedes buscar y añadir más artículos si todavía tienes hambre y quieres añadir más artículos. Otras partes de la lógica que son interesantes aquí es que tus costos de envío subirán y bajarán dependiendo de tu total. Así que si estás obteniendo menos de $20, creo que terminas incurriendo en un costo de envío de $5. Y también verás que la fecha de entrega estimada cambia dependiendo de cuán grande es tu cesta. Así que tenemos un poco de lógica de front-end que vive aquí. Vamos a echar un vistazo al código. Así que si empezamos aquí, es una configuración muy básica. Dentro de app.jsx, puedes ver un componente que ni siquiera es tan largo comparado con lo que podrías ver en un rato. Son unas 110 líneas. Se suma si te enfrentas regularmente a componentes que rondan las 100 líneas en React. 200 líneas.

Ahora, mucho de esto es realmente la lógica central del negocio. Entonces, si quieres probar esto, y vamos a entrar en nuestro app.test.jsx, que es solo una prueba VTest aquí. Permíteme acercar un poco. Olvidé preguntar, ¿todos pueden ver y leer claramente el código? ¿Verdad? Genial, gracias. Entonces, lo que hemos tenido que hacer en el nivel más alto aquí es que hemos tenido que simular el fetch. Y luego, la forma en que, digamos que queríamos probar si se aplica o no un descuento por más de $50 de cesta, porque esa es la lógica central que estamos testing aquí. Lo que hemos hecho es renderizar el carrito de compras. Y luego, estamos haciendo un query selector para verificar, ¿hay texto que tiene un tachado aplicado a él que dice $10, que es el primer elemento en nuestro precio simulado, y luego lo estamos testing. Entonces, de una manera extraña, lo que realmente nos importaba testing es muy diferente a lo que realmente hemos probado, que es que hemos probado la UI con el objetivo de validar que nuestra lógica de negocio funciona, ¿verdad? Es un poco contraintuitivo. Pero lo que realmente podemos hacer bastante fácilmente es que podemos tomar mucho de eso y convertirlo en un objeto humilde.

Y verás que las pruebas son mucho más fáciles, pero también el código se ve mucho más limpio. Así que vamos aquí y veremos el carrito de compras ahora. Así que no tenemos ninguna de esas funciones de ayuda arriba, pero tenemos un módulo de pagos que seguimos llamando para hacer la transformación de la lógica del negocio. Así que echemos un vistazo a payments.js y veamos qué hay allí. Puedes ver que son solo un montón de simples funciones de JavaScript. Tenemos un apply discount que toma los artículos. Tienes un calculate total que toma los artículos y ejecuta un reductor en ellos. Tienes un calculate shipping cost, que es solo un ternario muy simple dentro de él. Todo se ha vuelto muy funcional, pequeños bits de lógica de negocio que hemos incluido aquí. Y luego al final, simplemente devolvemos eso como un módulo en sí. Y si volvemos a app.jsx, lo que podemos ver es que todo lo que hacemos en nuestro componente de React es simplemente empezar a llamar a estas funciones que viven en nuestro servicio de pagos. Y eso es prácticamente todo. Y luego en la parte inferior, tenemos nuestro JSX real que se está renderizando. Y cuando entras en el archivo de pruebas, verás que es muy básico el testing ahora. Estás testing JavaScript. No tienes que preocuparte por los comportamientos asíncronos, o no tienes que preocuparte por los ciclos de vida del componente. No necesitas usar la biblioteca de testing para probar la lógica central del negocio que tienes. Es muy simple. Así que lo que eso significa finalmente es que pasas menos tiempo escribiendo las pruebas, y puedes escribir pruebas más efectivas porque estás comprobando directamente la lógica del negocio. Así que tenemos apply a discount for more than $50. Es muy simple. Le pasas un array de artículos, y te devuelve los artículos con un atributo añadido para el precio con descuento. Y luego algunas cosas más sobre no hay descuento por menos de $50. Y la prueba de la etiqueta de entrega, realmente solo estamos comprobando la función que toma los artículos y devuelve la cadena de lo que va a ser la etiqueta. Así que estamos testing lo que realmente es fundamentalmente importante para nosotros. Genial. Necesito dejar de reflejar. Genial. Así que eso es el modelo de objeto humilde. Veamos el modelo vista presentador.

Esta es una arquitectura tipo MVC que utilizan las bibliotecas de interfaz gráfica de usuario. Y básicamente está separando partes de tu interfaz gráfica de usuario. Tienes el modelo, que contiene la lógica de negocio, contiene la obtención de data, y luego tienes la vista. Ahora, lo que hacemos aquí es hacer de la vista una vista pasiva. Lo que significa es que la vista en sí no tiene ninguno de su estado o lógica de interfaz de usuario. Todo lo que hace es que es como una función. Toma una entrada con ciertos valores, y se renderiza en consecuencia. Es muy funcional en el enfoque que hace.

Y en el medio, entre el modelo y la vista, lo que insertas es un presentador. La idea con este presentador es que este presentador contendrá todo tu estado de interfaz de usuario. Manejará la conversión del estado de la interfaz de usuario. Manejará la conversión de los datos del modelo a un formato y una forma que coincida con lo que quieres renderizar en la vista. Entonces, ¿qué significa eso en la práctica? Si miramos nuestro ejemplo aquí de nuevo, hemos tomado todo y lo hemos puesto en un objeto humilde. Lo que esto también significa es que vamos a tomar el infracódigo, y también el estado y la lógica de la interfaz de usuario, y también sacar eso del componente. Y lo que vamos a hacer es que vamos a ponerlo dentro de un hook que vive fuera del componente en sí. Y esto va a ser useComponent, como se llame tu componente. Y contendrá el infracódigo, pero también tu estado de interfaz de usuario y tu lógica. Y también hará las referencias a tu objeto humilde también. Y ahora en este punto, realmente queda a tu discreción lo que quieras probar. Podrías probar el hook. O podrías probar el componente de interfaz de usuario real si realmente quisieras asegurarte de que la interfaz de usuario se comporta de cierta manera. Una forma sencilla de hablar de esto, especialmente con el resto del equipo, es una simplificación para decir que tienes una regla de un hook por pantalla. Lo que eso significa es que cada componente de pantalla solo debería estar llamando a un solo hook en cualquier momento. Y abstraes todo tu estado y lógica de interfaz de usuario en ese hook. Y realmente lo hace funcional. Y veremos cómo evoluciona nuestro ejemplo de codificación para manejar esto.

Genial. Misma aplicación exacta. Pero vamos a ver realmente el modelo MVP. Así que hemos abstraído nuestro objeto humilde en payment.

Volvamos a la app ahora y veamos cómo se ve. Lo que hemos hecho es que hemos creado un hook llamado shoppingCart.hook.js. Se llama useShoppingCart. Esa es la página que tenemos. Y toda la parte difícil del componente realmente ha sido trasladada aquí. Así que tenemos nuestro use state aquí, el useEffect para poblar los valores. Las llamadas al servicio de pago se han movido aquí también, así que al objeto humilde. Y luego nuestras callbacks para eliminar y añadir items. Y luego hemos calculado el costo de envío. Y lo que hacemos es que devolvemos un objeto en este hook, en este hook personalizado, que tiene los items transformados. Tiene el total y todo lo demás que necesitamos en la UI para renderizar correctamente.

Y volveremos a nuestro app.jsx. Y en realidad ha bajado a unas 38 líneas. Y todo lo que hace es que llama a este hook y obtiene los data que se requieren para renderizar desde el hook. Y luego simplemente lo renderiza de manera muy sencilla. Es muy funcional. Está saliendo. Y eso es todo lo que hace. Y lo que eso significa fundamentalmente es que todavía tenemos nuestras pruebas de pago. Hemos probado toda la lógica de negocio. Pero aparte de eso, si queríamos probar cómo se ve la UI, tal vez realmente queríamos asegurarnos de que el tachado se renderizaba cuando los precios originales ya no son aplicables y tienes un descuento. Lo que podemos hacer es que solo necesitamos un mock aquí. Y esto es realmente fundamentalmente importante cuando empiezas a tener estos componentes complejos que necesitan analíticas y sentry y así sucesivamente añadidos. Tienes muchas cosas para simular. Y al abstraer todo en un hook, siempre tienes como máximo un mock, que es el hook real que estás pasando a ese componente específico. Y lo que le decimos es, en este caso, simplemente devuelve esto como la salida del hook. Estos son los data que quiero que mi pantalla obtenga. Y luego todo lo que estoy haciendo es que estoy renderizando la app y luego comprobando muy rápidamente para ver si este elemento existe dentro del DOM. ¿Correcto? Así que es mucho más sencillo probarlo porque no tienes que preocuparte por simular todas las dependencias. Es solo aquí está el hook y aquí está el valor que el hook va a devolver.

Genial. ¿Por qué es esto importante? La idea con esto es que quieres alentar a tu equipo y a tus desarrolladores a caer en el pozo del éxito. Así que hay este gran artículo que recomendaría mucho leer que se llama Cae En el Pozo del Éxito. Es del cofundador de Strack Overflow. Y habla de cómo C++ es básicamente un pozo de fracaso o un pozo de perdición. Si cometes un error en una aplicación C++, las consecuencias son enormemente graves y no hace nada para salvaguardarte o protegerte de caer en el pozo de la perdición. Mientras que un buen lenguaje de programación o un buen marco de trabajo o una buena architecture, una buena base de código te preparará para el pozo del éxito. La idea es que creas estos sistemas bien diseñados que hacen que sea realmente fácil caer en buenos patterns. Todavía puedes permitir que las personas escapen de esos buenos patterns, pero lo haces bastante difícil para hacerlo. Así que animas a las personas a caer en el pozo del éxito. Se vuelve muy fácil para ellos tener éxito.

Genial. Así que hagamos un resumen y mi tiempo se ha terminado. Los cuatro puntos principales son, en primer lugar, quieres fomentar el código limpio y la architecture y realmente puede ayudarte a reducir el desperdicio en tu testing junto con todos los beneficios que te brinda en términos de organización de tu base de código y scalability. Si aíslas la lógica de negocio importante en objetos humildes, puedes hacerlo muy fácil para probar los componentes críticos de tu aplicación muy rápidamente. Usar una capa de presentador puede hacer vistas pasivas fácilmente comprobables. Otro nombre para estas vistas son las vistas pasivas y puedes hacerlo realmente fácil para probarlas porque no tienen ninguna dependencia de data. Y por último, y creo que esta es la parte clave, habrá muchos desarrolladores más experimentados aquí. Todos ustedes conocen estos conceptos. Estas son cosas fundamentales que aprendes a lo largo de los años al convertirte en ingeniero de software, pero en realidad enseñar estos principios a tu equipo y hablar explícitamente sobre ellos con tu equipo te ayudará a prepararlos para el pozo del éxito y, con suerte, hacerlo menos intimidante para ellos al probar, especialmente cuando se trata de componentes complejos.

Muchas gracias a todos por escuchar. Ese es mi Twitter y LinkedIn en caso de que quieras mantenerte conectado. Y sí, agradezco todo su tiempo. Una de mis cosas favoritas de ser un MC es que siempre puedo hacer la primera pregunta. Siempre. Una de las cosas que amo es que he hecho la architecture o patrón de componente utilizado antes. Pero, ¿cómo pruebas un hook de componente utilizado? Con mucho dolor. Solo sangre, sudor y lágrimas. Sí, sí, sinceramente. No lo intentes. No. Bueno, puedes probar el hook. Obviamente, has aislado muchas de tus partes difíciles de probar dentro del hook. Hay diferentes opciones y realmente depende. Sé que esa es la respuesta evasiva. Parte de la teoría que leerás si vas al blog de Martin Fowler sobre objetos humildes es que estás testing los bits importantes de forma aislada y luego usando algún tipo de pruebas de extremo a extremo o algún tipo de prueba de humo, lo que puedes hacer es asegurarte de que todas las conexiones y el cableado debajo del capó funcionen bien. Así que combínalo con un buen marco de pruebas de extremo a extremo y puedes asegurarte de que tu código esté cubierto. Pero sí, tienes esa parte, que es mucho más difícil de probar, ¿verdad? Por supuesto. Por supuesto.

Y así tenemos un par de preguntas. Muchas de ellas son sobre la regla de un hook por componente. Así que voy a agruparlas todas si eso está bien, que es en primer lugar, ¿por qué es importante? ¿Y luego tienes algún método para crear reglas de linter para hacerla cumplir? Esa es una buena pregunta. De hecho, hemos hablado de las reglas del linter. No tenemos una regla de linting. Simplemente usamos el proceso de revisión de código para asegurarnos de que nos adherimos a ella. Pero creo que sería muy valioso tener una regla de linting para ello. Simplemente no hemos invertido el tiempo para hacerlo. ¿Por qué la regla es tan importante? Creo que no es la regla en sí. Es una regla que empieza a hacer que la gente piense en ello. Es una regla muy simple para dar a un desarrollador junior que no tiene mucha experiencia. Para decirles, no añadas más de un hook para cada pantalla o para cada componente. Es una forma muy simple de empezar a tener esta conversación. Así que creo que es más una pieza de enseñanza que cualquier otra cosa. No es una regla estricta y rápida per se, sino simplemente una pieza de enseñanza. Es una bonita forma de formular este concepto del modelo MVP. Es un pozo de éxito. Un pozo de éxito. Muchas gracias.

Vale. Y alguien preguntó, y supongo que la respuesta a esto es sí, ¿sigues estos patterns tú mismo? No, soy un hipócrita. Intentamos hacerlo, especialmente en proyectos Greenfield, definitivamente intentamos seguir estos patterns cuando estamos configurando la base de código. En proyectos que ya existen y en los que entramos, es un poco más difícil obviamente porque tienen sus propias configuraciones. Pero eventualmente lo que intentamos hacer es ir en esa dirección. Y a veces es más difícil. A veces es más fácil. Realmente depende de lo que ya existe. Pero sí, realmente intentamos hacer esto. Lo que eso también significa para nuestro caso, especialmente como consultoría, es que las personas trabajarán en, en un solo año, tal vez trabajarán en 12 proyectos diferentes, ¿verdad? A veces la rotación de proyectos es rápida. Algunos de ellos son más largos, pero muchos de ellos serán de corta duración. Y a medida que estandarizas estos patterns, las personas tendrán un tiempo mucho más fácil para entrar y salir de los proyectos. Y eso es genial para nuestros clientes también porque significa que es muy fácil capacitar a las personas porque tienes reglas y tienes marcos de pensamiento consistentes, mentalidades y todo alrededor de ello. Así que creo que definitivamente ayuda. No, tiene sentido. Tiene sentido.

Entonces, has hablado un poco sobre esto, especialmente porque no solo lo estás haciendo para ti mismo. Eres un líder técnico. Estás empoderando a otros, educando a otros para implementar estos patterns y muchas otras cosas en la escala. ¿Y cómo evitas la burocracia con esto? Como que muchas personas diferentes tienen muchas opiniones diferentes. A menudo también ves en las preguntas, ¿cómo evitas esa burocracia? Es una pregunta interesante. Porque sí, hay una línea fina entre hacer estos mandatos que son como, tener este porcentaje de cobertura de pruebas. Sabes, como un ejemplo, o estas son las reglas dentro de nuestra base de código y vamos a apegarnos a ellas sin importar qué. Y hay otra cosa, enseñar a las personas sobre buenas prácticas y luego usarlo más como una pieza educativa. Y creo que la actitud que tenemos es que es una pieza educativa. Es una pieza de formación más que reglas impuestas. Así que sabes, nadie recibe un golpe en la muñeca si no usan, si tienen dos hooks en sus componentes o cualquier cosa. Es muy orientado a la formación. Está muy orientado hacia el aprendizaje y la enseñanza. Y es más que la sabiduría colectiva nos guiará hacia ese ideal de tener una buena base de código.

Sí, eso tiene mucho sentido. Totalmente tiene sentido. Creo que especialmente como líder, esa es una buena habilidad para tener. Y la siguiente pregunta vuelve al ejemplo de un solo hook. Entonces, ¿cómo te aseguras de que solo tienes un hook? ¿Creas un hook que llama a los demás? Sí. Es un hook personalizado que llama a los demás. Definitivamente échale un vistazo si tal vez este es un patrón de React que es nuevo para ti. Es bastante genial y hace que tu código sea mucho más legible y reutilizable. Así que personalmente también lo recomendaría. Una de las cosas interesantes con esto es que si trabajas en una estructura de monorepo, digamos que tienes una aplicación de React Native y una aplicación de React que son totalmente separadas entre sí. A menudo, la lógica de negocio central va a ser la misma. Y si empiezas a tomar estos y los conviertes en hooks personalizados, lo que puedes hacer con una herramienta útil como TurboRepo o NX es en realidad usar la misma lógica de negocio exacta para tus aplicaciones web y tus mobile apps sin tener que codificarlo dos veces. Así que hay otros beneficios al abstractarlos y ponerlos en sus propios modules también, que son subproductos de tener una regla como esta.

Bien, bien. La siguiente pregunta con la gente que ama a React aquí, la gente está muy informada sobre él. Y esta es también una pregunta de React. ¿Podrías usar señales en lugar de...? No en React, no podrías porque las señales no tienen soporte oficial en React. Pero estos conceptos son como conceptos fundamentales de ingeniería de software. No creo que sean solo aplicables al código de React. Creo que son particularmente relevantes cuando hablas de React porque es este modelo basado en componentes en el que puedes meter todo en un componente. Pero otros frameworks podrían tener patrones un poco más opinados. Si te adentras en Angular, obtendrás un modelo MBC por defecto, al menos cuando usé Angular en el pasado. Y por lo tanto, es mucho más opinado y te guía en esos patterns. Estoy seguro de que puedes implementar algo como esto con Svelte o con Solid o lo que sea que tengas. Depende de la respuesta para la sesión, ¿verdad? Siempre hay una. Y creo que esto es una de las cosas interesantes cuando vienes a las charlas. Porque una persona te habla sobre una tecnología y tal vez te cuenta un caso de uso específico. Pero necesitas un poco de todo. Y hablaste de esto, como React, React Native. Y estás dando esta charla específicamente desde la perspectiva de alguien que está preparando pruebas y aplicaciones para encajar en ambos mundos. Y eso no necesariamente puede ser lo mismo para ti. Así que definitivamente conocer todas las opciones en la mesa también es bastante útil.

Pasemos al siguiente. Esto es, de nuevo, sobre un hooks. ¿Cuál es el peligro de tener más de un hook por componente? Bueno, de nuevo, estás empezando a agregar más dependencias. Puedes dividir los hooks en diferentes hooks. Digamos que tienes dos hooks personalizados que usan diferentes cosas. Pero es solo este concepto de crearlo simple para seguir un patrón dentro de la base de código. Y si tienes múltiples hooks personalizados que necesitan referirse entre sí, yo los aislaría en una sola capa. Simplemente porque lo hace mucho más fácil. Es muy claro. Hay un solo punto de entrada para todos los data en tu componente. Y luego simplemente se alimenta en el JSX, y se renderiza allí. Así que incluso si necesitas múltiples hooks, simplemente ponlos todos en una capa de un hook personalizado, diría yo.

Genial. Entonces, a partir de ahora, si quieres hacer una pregunta sobre un hook, lo que voy a hacer es decirte que consultes a Mo en el Discord en la sala de discusión de los ponentes después. Pero tenemos un montón de otras preguntas. Como una, específicamente, esto es algo sobre empoderar a tu otro equipo, y todas estas personas, tal vez personas que están al principio de su career como desarrolladores. Y entonces esta persona ha preguntado, ¿has usado Copilot o GPT para ayudar a todos a adherirse a estos patterns? ¿O para autoverificar que tienen estos patterns? ¿Y has encontrado alguna utilidad en ello? No en la etapa de revisión de código, o en mí mismo para la etapa de redacción real. Pero ha sido útil para las refactorizaciones, en realidad. Así que si entras en un código base, y tienes estos componentes, y a veces se convierte en algo mecánico refactorizarlos en estas reglas de un hook por pantalla, ChatGPT puede ser bastante bueno en tomarlo y separar la lógica de negocio del JSX para ti de una manera bastante automatizada porque es bastante simple y directo hacer eso. Es muy mecánico una vez que aprendes a hacerlo. Y esto se siente como algo muy nuevo, porque todas estas herramientas de IA son bastante nuevas. Aunque están siendo adoptadas muy, muy rápidamente, ¿ves algo cambiando en el futuro con la forma en que usamos las herramientas de IA para ayudar a refactorizar, o algo así como autoverificar estas? Creo que realmente pueden ayudar con el proceso de revisión de código. Así que tengo un colega, su nombre es Matt. Ha estado trabajando en esta biblioteca de GitHub llamada Code Review GPT. Puedes buscarla si estás interesado. Es algo así como la idea de, ¿podemos añadirla al proceso de revisión? Todavía está muy en proceso. No está perfeccionado, pero creo que va a ser realmente bueno en el aspecto de que no va a reemplazar lo que hacemos día a día, pero esperemos que pueda señalar algunas de las partes más mecánicas y metódicas de nuestro trabajo, hacer eso un poco menos intensivo en tiempo, y automatizar esa parte de él.

Genial. Muy bien. Tenemos tiempo para una pregunta más. La pregunta es, eres un especialista en React, React Native, pero aquí la gente, tal vez ellos trabajan en otros frameworks. ¿Cómo pueden tomar algunos de estos patterns y cosas de las que has hablado, y luego hablaste sobre, especialmente cuando hablamos de la pregunta de las señales, pero tal vez cuáles son algunos de los conceptos que dirías, estas son las cosas que necesitas recordar y aplicar en tu marco? Y tal vez podemos emparejarlo con la siguiente pregunta es, ¿por qué esta charla es una React Native y no solo React y Amigos? Eso se debe a mi pobre marketing y a no pensar en cómo esto puede ser aplicable a otras cosas. Pero en términos de cómo aplicas estos a otros frameworks, ¿o los aplicaría? Creo que sí. Sí. Y definitivamente tiene un gran lugar en estas bibliotecas de UI basadas en componentes, como React. Creo que puedes llevar esto fácilmente a otros frameworks que están basados en componentes. Si te metes en pilas front-end más opinadas, como si, digamos, quisieras escribir un componente dentro de, digamos, SwiftUI, creo que SwiftUI también puede tomar muchos de estos conceptos y aplicarlos a ellos, porque está muy basado en la mentalidad de React, y se inspiró en eso. Pero digamos que entraste en algo como una aplicación de UI kit en una aplicación iOS. Es un poco más difícil hacer eso, porque todo el encuadre de cómo design las UI es muy diferente. Es imperativo. No se comporta de la misma manera. Así que creo que es realmente aplicable a otros frameworks basados en componentes. Gracias. Sabes, es una gran charla cuando las preguntas se ramifican en tantas otras posibilidades. Gracias por mostrarnos todas estas posibilidades. ¡Demos un gran aplauso a Mo!