El Medio Desordenado — Navegando la Complejidad en Aplicaciones React Grandes

Hola React Summit, mi nombre es Maxi Ferreira y hoy quiero compartir con ustedes algunas de mis reflexiones sobre uno de mis temas favoritos, que es la gestión de la complejidad en grandes aplicaciones React. Pero antes de empezar, imaginemos el viaje de cualquier gran proyecto. Podríamos imaginar que va a ser algo así, vamos a hacer progresos constantes con el tiempo hasta que finalmente llegamos a la meta, lanzamos a producción y salimos a celebrar con nuestro equipo. En realidad, sin embargo, es mucho más probable que sea algo así. Las cosas se complican en el medio. Las características ahora tardan una eternidad en lanzarse, el dev técnico se acumula muy rápidamente y la meta parece alejarse cada día más. La razón de que esto suceda es que a menudo imaginamos que la complejidad crece linealmente con el tiempo. Cuanto más progreso hacemos, más crece la complejidad del código, y eso es algo que esperamos. Pero más a menudo que no, la complejidad tiende a crecer exponencialmente. Así que cuando estamos a mitad de camino en el proyecto, podemos ver que la complejidad no está disminuyendo. Puede resultar bastante abrumador.

Para el propósito de esta charla, vamos a definir la complejidad como cualquier cosa que haga que el sistema sea más difícil de cambiar o más difícil de entender. Lo que me gusta de esta definición es que podemos invertirla y obtenemos exactamente lo que necesitamos hacer para lograr la simplicidad, que es hacer que las cosas sean fáciles de cambiar y más fáciles de entender. Así que hoy quiero compartir con ustedes mis tres estrategias y técnicas favoritas para ayudarles a manejar esta creciente complejidad en grandes proyectos React, que espero que sean útiles, especialmente si están en medio del caos de su proyecto en este momento

Entonces, veamos cómo podemos mejorar este design con la composición de componentes. Todavía tenemos un componente de tarjeta de ubicación aquí que maneja quizás el diseño del componente. Pero ahora no toma ninguna prop. En cambio, estamos definiendo el contenido de la tarjeta a través de componentes hijos. Así que ahora es mucho más flexible. Si quieres ocultar el botón de favorito como lo hicimos antes, puedes simplemente apuntar a ese elemento en el JSX y eliminarlo. Y ahí lo tenemos. Queremos cambiar la etiqueta y el color del botón. Bueno, el botón está justo ahí. Así que podemos hacer el cambio en el botón directamente sin tener que cambiar ninguna otra parte del componente. Lo importante a tener en cuenta aquí es que con la composición, generalmente hay un equilibrio entre la flexibilidad y la facilidad de uso. Podemos descomponer un componente grande en muchos más pequeños, y esto hará las cosas súper flexibles. Pero con muchas piezas pequeñas, el componente se vuelve más difícil de usar. En el otro extremo del espectro, tenemos un componente muy simple que no es muy flexible en absoluto, como nuestro ejemplo inicial del componente de tarjeta de ubicación. Por lo general, quieres estar en algún lugar en el medio cuando se trata de composición. Y esto te dará el nivel correcto de composición para el problema que estás tratando de resolver. Ahora, ¿cómo encontramos este punto dulce? Esto me lleva a mi segundo punto, que es usar los modules. Este es un concepto que proviene del libro una filosofía de diseño de software design, que es uno de mis libros favoritos, y habla sobre la profundidad del módulo como un equilibrio entre coste y beneficio. Cualquier módulo, podría ser una función, una clase, o un componente de React tiene esencialmente dos partes. Tiene una interfaz, que en el caso de un componente de React, son las props del componente. Y tiene una pieza de funcionalidad, que es lo que hace el módulo. Un módulo profundo es aquel que proporciona una funcionalidad poderosa a través de una interfaz simple. Un módulo superficial por otro lado, es aquel que proporciona muy poca funcionalidad en comparación con la complejidad de su interfaz. Entonces, veamos un ejemplo de un componente profundo de React. Este componente FileAbloader, sabes, tiene mucha funcionalidad. Se encarga de la validation, arrastrar y soltar, la subida real del archivo, incluyendo el manejo de errores. Y al mismo tiempo, la interfaz es muy simple. Solo tiene dos props. La implementación de este componente es probablemente muy compleja. Pero debido a la simplicidad de la interfaz, esa complejidad

Es importante saber que nadie se propone construir algo muy complejo desde el principio. Las cosas suelen empezar de manera simple, como nuestra implementación inicial de la tarjeta de ubicación. Este era un componente potente con una interfaz simple. Era un módulo profundo, hasta que dejó de serlo. Así que es importante que controlemos esta evolución para asegurarnos de que las abstracciones que implementamos al principio siguen siendo las soluciones correctas a los problemas que tenemos hoy.

Y esto me lleva a mi técnica final para gestionar la complejidad, que es enfocar tus esfuerzos en reducir la carga cognitiva. Con esto, me refiero a minimizar la cantidad de información que necesitas mantener en tu cabeza para hacer un cambio simple. Toma este componente, por ejemplo. Es una cuadrícula de enlaces a diferentes partes de la aplicación que los usuarios verán en sus paneles de control, pero diferentes usuarios verán diferentes enlaces dependiendo de qué tipo de usuario sean y también de qué plan tengan. Por ejemplo, un usuario regular en el plan básico solo verá estos cuatro enlaces. Ahora imagina que queremos hacer un cambio, como añadir un nuevo enlace a este grupo particular de usuarios. Así es como se ve la implementación. Es bastante limpia, y veo que tengo una lista de enlaces allí, así que sé que ahí es donde necesito ir y añadir mi nuevo enlace. Veo que estamos filtrando los enlaces en función del usuario y del plan, lo cual es genial porque eso es exactamente lo que necesito hacer, y luego simplemente estamos renderizando los enlaces.

Ahora esta función de filtrar enlaces parece importante. Sé que necesito entrar allí y cambiar la lógica de alguna manera para que muestre mi nuevo enlace a los conjuntos correctos de usuarios, y cuando abro esta función podríamos encontrar algo que se vea así. Ahora esta es una implementación particularmente desordenada, así que no te fijes demasiado en ella. El punto importante aquí es que ahora necesito entender completamente esta lógica de filtrado para hacer mi pequeño cambio simple. Así que necesito cargar toda esta información en mi cabeza para hacer el cambio. Ahora imagina si el componente de cuadrícula se ve algo así en su lugar. Es muy similar y todavía tengo una lista de enlaces, pero ahora ves que puedo declarar qué usuarios y plantas tienen acceso al enlace directamente en la lista. Así que todo lo que necesito hacer es añadir un nuevo elemento aquí y puedo seguir con mi día. Observa que todavía estamos llamando a la función de filtrar enlaces y por todo lo que me importa esa función puede ser muy muy compleja, pero ahora yo ni siquiera necesito abrir esta función para hacer ese cambio. Me ahorro tener que cargar toda esa lógica en mi cabeza. Este es solo un ejemplo de cómo podemos reducir la carga cognitiva en nuestra aplicación. Otras cosas que podemos hacer incluyen el uso de nombres de variables claros para que no tengamos que adivinar qué hace un componente o una variable, escribir buenos comentarios que no repitan el código sino que expliquen el por qué y el cómo, usar patrones de diseño predefinidos design patterns porque ya tenemos un entendimiento compartido de cómo funcionan, y documentar decisiones importantes en algún lugar, particularmente esas decisiones de alto nivel que simplemente no pertenecen a un comentario de código. El mensaje central de esta charla es que la simplicidad es muy difícil. Hacer las cosas fáciles de cambiar y fáciles de entender es definitivamente posible pero no es fácil en absoluto. La complejidad es un enemigo imposible. Nunca podemos eliminarla completamente pero sí tenemos cierto nivel de control sobre su crecimiento y espero que puedas usar algunas de las estrategias que cubrimos hoy para ralentizarla antes de que se apodere de tu base de código. Si disfrutas hablando sobre la complejidad, el diseño de software y la arquitectura puedes encontrarme en línea como charca en todas las redes sociales y también en mi sitio web frontend.skl donde escribo sobre diseño de software y arquitectura para desarrolladores de frontend. Muchas gracias por tenerme y espero que disfrutes el resto de la masterclass.