Mess to Modern: Refactoring a React Nightmare

¿Alguna vez has abierto una base de código de React y te has asustado de lo que viste al otro lado? Podría haber sido 900 líneas de un completo lío de código espagueti, múltiples diferentes use effects, múltiples diferentes use states, todas estas cosas diferentes a las que hemos abierto bases de código y nos hemos preocupado por lo que vimos. Mi nombre es Caleb Garner. Soy un desarrollador full stack y he abierto muchas de estas pesadillas de React. He tenido mucha experiencia teniendo que refactorizarlas y hacer que se vean mucho más bonitas al otro lado.

Así que lo que quiero hacer en esta charla hoy es darte un plan de cinco pasos sobre cómo convertir este componente de React de 900 líneas heredado o creado y convertirlo en algo con lo que realmente disfrutarás trabajando. Así que este es nuestro punto de partida, y verás que esto es muy desordenado y está haciendo muchas cosas aquí. Son más de 900 líneas de React, cinco llamadas de usuario, 16 nuevas llamadas de estado. Hay obtención, transformación, validación, renderizado, todo sucediendo en el mismo lugar. Y es una completa pesadilla trabajar en ello desde el punto de vista de un desarrollador.

Ahora, he abierto muchas bases de código y me he encontrado con algo muy similar a esto. Pero, ¿a dónde vamos desde aquí? ¿Qué hacemos para condensar esto y llegar a un lugar en el que realmente sea agradable trabajar? Y no solo eso, es mucho más eficiente, y está mucho mejor estructurado para que el resto del equipo lo gestione también desde este punto. Ahora, vamos a repasar cinco puntos separados para abordar bases de código como esta. Así que el primero es la modularidad del sistema. No estamos comenzando realmente dentro del componente. Estamos comenzando desde afuera y cómo organizamos toda la estructura del proyecto en conjunto.

Verás, ¿cuál es el patrón que vemos mucho en estas bases de código? Y cómo va a funcionar esto es que vamos a repasar cómo se ve el patrón, cómo lo arreglamos y por qué lo arreglamos al final. Verás, primero está la modularidad sistemática. Sabes, la mayoría de los proyectos que vas a abrir se abrirán a una carpeta de componentes plana, más de 40 carpetas que te dicen qué son los componentes e incluso qué es el framework, pero no te dicen qué es el proyecto. Y ese es el primer paso para que esta base de código se convierta en algo moderno y modular, es que nuestra estructura de componentes debe modelar lo que nuestra aplicación está haciendo y no los componentes o el framework en el que está. Antes de mover una sola línea de código, necesitas un mapa de cómo se verán los componentes en la aplicación. Ahí es donde entras en componentes dirigidos por características. Componentes, hooks y tipos están todos co-ubicados basados en las características, no basados en el framework. Y entramos en esta estructura donde si necesitas un elemento específico para una característica específica, se encuentra dentro de la carpeta de características. Esto hace que las cosas sean mucho más manejables cuando entregas este proyecto a alguien que nunca lo ha visto antes o simplemente para el mantenimiento diario de este proyecto. Esto va a ser mucho más fácil y mucho más estructurado para poder trabajar como desarrollador también. Y obviamente, cualquier componente compartido en la utilización de primitivas, que es algo de lo que hablaremos un poco más adelante en la presentación, también es importante. Pero todas estas estructuras y componentes están co-ubicados en los lugares donde necesitan estar, no basados solo en una biblioteca de componentes plana singular.

Ahora, ¿por qué hacemos esto? Compartimos un fragmento aquí de cómo se verían las exportaciones en nuestra página de dashboard si cumpliéramos con este patrón. ¿Y por qué? La Ley de Conway dice que tu sistema reflejará la estructura de tu organización, usualmente por accidente. La arquitectura y lo que este principio que estamos implementando aquí nos dice que deberíamos hacerlo a propósito. Nuestra característica debería decirnos exactamente qué hace ese código, y no deberíamos tener que adivinar qué está haciendo ese componente o dónde está ese componente basado en nuestra estructura de carpetas. Esto nos da una buena base y buena estructura para no solo modularizar y mejorar nuestros componentes y páginas individuales y nuestras características, sino algo que escala a toda la base de código también. Ahora, lo siguiente en lo que vamos a entrar es la extracción de lógica. Hablamos de la organización de las carpetas, y ahora vamos a entrar en el código real, lo que deberíamos estar haciendo dentro de estos componentes también. Entonces, dentro de nuestra página de dashboard, teníamos lógica de negocio integrada en el componente real también. Estos cálculos de ingresos, lógica de obtención, validación estaban todos viviendo dentro del componente. Eso puede ser problemático de un par de maneras diferentes. Uno, tenemos estos componentes que están haciendo demasiado en el front end, pero también – no es comprobable. No podemos hacer pruebas unitarias a estos componentes individuales, y también están atrapados dentro de nuestro componente. No puedes reutilizar ninguno de estos componentes si otras características necesitan hacer exactamente lo mismo. Y si un componente falla, todo en esta carpeta o en este archivo va a fallar, especialmente toda esta lógica y las piezas reutilizables también. Entonces, este es el patrón del que estamos tratando de alejarnos. Ahora, ¿cómo hacemos eso? Tenemos estos hooks específicos y separamos esta lógica de negocio en su propio sistema, sus propias piezas modulares de código que importamos en nuestro dashboard principal. Use order filters posee un filtro y lógica de origen. Use orders posee una obtención. Cada hook es comprobable de forma independiente con render hook.

El componente llama a un hook y obtiene todo lo que necesita. {{^}}El componente no está describiendo lo que necesita ni creando lo que necesita por sí mismo. Está utilizando estas piezas reutilizables y piezas de código comprobables individualmente que podemos usar dentro de la base de código también.

Ahora, ¿por qué coincidimos esto con el patrón? ¿Por qué separamos esta lógica de negocio del dashboard en estos hooks individuales? Entonces, responsabilidad única. Aplícalo a cada uno: cada hook tiene un trabajo. Y cuando falla, sabes exactamente dónde buscar. O si necesitas avanzarlo o mejorarlo, sabes exactamente dónde buscar ese hook también. La comprobabilidad es posible en este modelo. Para probar estos elementos, puedes probar en hooks individuales. No tienes que organizar eso en un componente singular completo por sí mismo.

Ahora, hay un cambio mental cuando se trata de la extracción de lógica. Cuando estamos sacando esta lógica de negocio fuera del componente, un componente que obtiene, transforma, valida y representa son cuatro cosas que pretenden ser una sola. Está pretendiendo encajar todo bajo el único paraguas de este componente. Cuando lo extraes en hooks, el componente se convierte en una cáscara delgada responsable de la representación pura. No es responsable de estas cosas exteriores que deberían ser lógica reutilizable en toda la base de código. Entonces, hablamos sobre – hemos hablado sobre la extracción de lógica. Hemos hablado sobre la organización de los componentes. Ahora, quiero hablar sobre la gestión del estado.

Este es uno de los patrones que veo con bastante frecuencia al trabajar con bases de código heredadas. Verás, filtered orders no es un estado. Es un cálculo, pero se está almacenando, sincronizando y manteniendo como si fuera datos reales. Este patrón es algo que veo mucho donde la separación entre estado y datos no se está manteniendo en estas bases de código, en estos proyectos, donde necesitamos separar. Nuevamente, el estado necesita ser gestionado como estado, y los datos deben ser manejados como datos también.

De esta manera, manteniendo una forma más madura y una forma más predecible de mantener nuestra gestión del estado. Entonces, aquí hay un patrón que vemos a menudo, pero ¿cómo lo solucionamos en su lugar? Si el valor puede ser calculado a partir de un estado existente, cálculalo con algo como useMemo. Úsalo como una pieza de estado también. Pero cuando el estado tiene múltiples piezas relacionadas, usa una unidad discriminante para que los estados imposibles se vuelvan imposibles de representar, y el sistema de tipos lo impone aquí.

Pero la idea principal y el cambio en torno a la gestión del estado dentro de nuestros componentes que hace esto más modular y más moderno es que nos convertimos en una gestión del estado predecible. No estamos usando estos use states de una manera muy abierta, y no estamos creando mucho caos con nuestros componentes y dentro de nuestra gestión del estado, sino que realmente estamos convirtiendo eso en un flujo predecible que se puede ver a lo largo de nuestro código en algo que es modular y algo que está completamente configurado dentro de nuestros componentes también.

Ahora, siguiente diapositiva aquí. Entonces, ¿por qué necesitamos este patrón? No queremos adivinar el flujo de nuestros datos y el flujo de esta aplicación. Necesitamos definir un patrón predecible, especialmente usando algo como userReducer, algo que he usado mucho dentro de mi código, porque hace que cada posible transición de estado sea visible dentro del código y lo que tu aplicación va a hacer y lo que la gestión del estado va a hacer a medida que avanzas a través de tu aplicación. Ya no estás jugando un juego de adivinanzas sobre cuál es tu estado. Estás definiendo claramente cuál va a ser el estado de tu aplicación y gestionándolo de una manera mucho más estructurada. Y userReducer te da un único lugar donde los estados en la transición están definidos y son legibles, pero userReducer para estado local complejo, lo otro que veo muchas veces, es recurrir a una biblioteca como Zestand para el estado.

Y no necesitamos recurrir a eso como primer instinto, porque la gestión del estado que vive fuera del árbol de componentes, este estado es necesario para múltiples componentes diferentes. Ahí es donde usarías un gestor de estado como Zestand. Así que no recurras a una tienda por defecto si el estado no sale del árbol. Realmente no lo necesita en ese caso. Pero hay otros métodos y otras formas en que podemos obtener esta gestión de estado predecible en todo nuestro proyecto y dentro de estos componentes específicos y dentro de estos procesos específicos. Ahora, mencioné procesos específicos. El cuarto o cuarto paso del que quiero hablar es el manejo de datos. Este patrón que estamos notando en este fragmento, user effect gestiona su propio estado de carga, su propio estado de error y su propia caché. Y es muy fácil que estos se desvíen. Una vez que uno se actualiza, los otros no.

Y este es el estado del servicio siendo gestionado en el lado del cliente. Luego, la versión más peligrosa de esto es que dos páginas diferentes de la aplicación necesitan estos datos, ambas necesitan esta estructura, ambas necesitan órdenes de API o clientes de API. Esta lógica necesita ser compartida entre múltiples componentes. Y este patrón, si lo estamos haciendo de esta manera, ambas aplicaciones necesitarían definir este user effect inmediatamente. Y ese no es el caso que queremos establecer para nuestro código. Queremos poder tener algo reutilizable. Queremos tener algo que no esté haciendo este estado de servicio siendo gestionado en el lado del cliente. Entonces, ¿qué necesitamos hacer? Bueno, extraer estas consultas en componentes reutilizables y hooks reutilizables. La clave de consulta es todo el sistema de caché en un concepto usando la estructura de React query.

Y realmente la mentalidad aquí es desglosar estos bloques de datos y componentes de manejo de datos basados en su dominio. ¿Qué datos están obteniendo para que puedan ser reutilizados en múltiples aplicaciones? El componente individual no debería describir qué necesitan obtener, especialmente cuando se reutiliza en múltiples aplicaciones diferentes. Pero tener esta estructura en una consulta individual que pueda ser reutilizada es un superpoder que puede ser usado en múltiples componentes diferentes para obtener datos similares y tener el mismo manejo de estos datos, como almacenamiento en caché y validación, y tener la misma estructura en un único punto de entrada para estos datos en lugar de que cada componente maneje estos datos por su cuenta.

El estado del servicio y el estado del cliente son cosas diferentes que necesitan herramientas diferentes. El estado del servidor del que hablamos en una sección anterior, pero no necesita ser gestionado como un estado del cliente. Los datos que necesitamos dentro de nuestra aplicación, la lógica de negocio necesita ser manejada de una manera muy diferente. Y esto no es solo para limpiar nuestro código o hacerlo mucho más bonito cuando miramos los componentes individuales. Cambia el modelo mental de obtener y almacenar a almacenar en caché y sincronizar. Cuando la API cambia, cambias un archivo. No necesitas ir y buscar en componentes individuales para encontrar, oh, este componente usa esta consulta, y este componente usa esta consulta. Consultas estructuradas en un archivo reutilizable único para que puedan ser usadas en múltiples componentes diferentes, y puedan ser fácilmente probadas y fácilmente reutilizadas y fácilmente mantenidas en todo el código porque los componentes no deberían estar diciendo qué datos de negocio necesitan. Nuestras consultas deberían estar manteniendo qué datos de negocio se necesitan en toda la aplicación.

Ahora, otra área que, o la quinta etapa, la última página de la que queremos hablar es tener componentes modulares. Ahora, nadie construye un componente de 12 props a propósito. Nadie llega a este punto a propósito. Lo que sucede muchas veces es que lo agregas uno a la vez. Agregas el orden una vez. Agregas el estado de actualización una vez. Agregas el estado de guardado una vez. Y luego pasas de este componente muy simplista a 12 props, todos haciendo, y realmente la mentalidad aquí es, un componente teniendo cada estado individual y sabiendo cómo hacer cada pieza de este rompecabezas, lo que este componente debería estar haciendo para que pueda ser reutilizado en diferentes componentes, en diferentes estructuras. Muchos de los patrones es que tenemos este nivel de componentes que llegan al nivel de primitivas y llegan al nivel de una biblioteca de componentes compartida. Pero esto es muy difícil de mantener desde la perspectiva de un desarrollador también, poder mantener estos diferentes props y diferentes estados dentro de este componente para reutilizarlo dentro de nuestro código. Esa interfaz crece, y el componente se vuelve intestable y realmente difícil de mantener desde ese punto. Entonces, ¿cómo abordamos esto? Bueno, son componentes compuestos. Si queremos estructurar de esta manera como algo que está desglosado y cada pieza posee su propio y realmente mirando los componentes, hay dos maneras diferentes de abordar esto. Una, podrías tener componentes individualizados y primitivas más profundas que hagan una cosa muy bien. Tienes una estructura, y este componente va a hacer una cosa muy bien. El otro lado de esto es tener mucha más flexibilidad es un patrón como componentes compuestos, donde dejas que cada pieza individual de este componente haga exactamente una cosa. Estás agregando a esta composición y agregando a este componente compuesto, pero no estás agregando props y cambiando el diseño completo y teniendo esta manera más casi brutalista de manejar el componente también. Así que detalles de la muestra en el sitio de llamada.

El llamador controla cuál es el diseño. Donde determinamos y llamamos a este componente determina qué es. Las piezas no necesitan saber unas de otras desde ese punto. ¿Y por qué hacemos un patrón como este? Para cualquier cosa que requiera accesibilidad, y usando Radix como ejemplo para esto, Radix va a manejar gran parte de tu accesibilidad y el valor de tus componentes también, donde van a resolver la navegación por teclado, van a resolver el enfoque de conducción, van a resolver ARIA, y tú vas a poseer el estilo y poseer la composición desde este punto de vista. Donde incluso mirando la estructura como un llamador de este componente, solo voy a llamar lo que absolutamente necesito y no tener que mantener estos props para llegar a ese punto que necesito también.

Así que pasamos por cada uno de estos componentes y cada una de estas cinco fases de esta biblioteca de componentes y cómo abordarlo y cómo proceder. Y si notas los fragmentos, pasamos por cada cosa individual que está mal en este componente. Así que aquí es donde comenzamos. 900 líneas de React, 5 llamadas a UseEffect, 16 llamadas a UseState, obtención, transformación, validación y renderizado, todo sucediendo dentro del mismo componente. Una completa pesadilla para trabajar. Así que si tomamos estos cinco principios en este libro de jugadas, podemos pasar de esto a esto. 35 líneas de React. Y este es el tipo de transformación que he visto en mis propias bases de código usando algunos de estos principios. Y mirando este componente, es renderizado puro.

La lógica permanece donde pertenece. Estamos importando todo lo que necesitamos y la lógica que necesitamos dentro de este componente. Pero no tengo que clasificar un montón de líneas de lógica de negocio para llegar a nuestro componente, a nuestra pieza de renderizado, que es lo que nuestros componentes realmente deberían estar poseyendo al final del día. Está organizado y estructurado, y es divertido trabajar en él de nuevo. No solo simplemente no eliminamos toda la funcionalidad de la aplicación para llegar a este punto.