Todos hemos pasado por eso. Abres un componente de React que escribiste hace unos meses y te sientes como si estuvieras viendo un código escrito por alguien que tenía prisa, porque probablemente tú lo tenías. Se avecinaban fechas límite y era necesario enviar funciones. Avancemos hasta el día de hoy y es hora de refactorizar ese componente desordenado.

Así que así es como lo abordé.

El horror inicial

Lo primero que noté fue que el componente había crecido demasiado. Intentaba hacer de todo, como manejar el estado, realizar llamadas a la API, administrar una lógica de interfaz de usuario compleja e incluso aplicar estilos directamente. Era un único archivo de más de 540 líneas y leerlo era como estar en una jungla sin mapa.

El primer paso fue aceptar la realidad: este código ya no se podía mantener. Si yo, la persona que lo escribió, apenas pudiera seguir lo que estaba sucediendo, alguien más no tendría ninguna posibilidad. Así que decidí desglosarlo.

Rompiéndolo

Comencé identificando las diferentes responsabilidades del componente. Había tres áreas claras:

1. Gestión de estado: el manejo del estado del componente estaba entrelazado con la lógica de la interfaz de usuario.

2. Llamadas API: obtención de datos y manejo de estados de carga.

3. Representación de UI: visualización de los datos en una estructura de UI algo compleja.
   Era necesario separar cada una de estas responsabilidades.

Extracción de ganchos para lógica de estado y API

Lo primero que hice fue extraer la administración del estado y la lógica API en ganchos personalizados. Esto no solo limpió el componente sino que también facilitó probar y reutilizar la lógica en otros lugares.

Mencionando algún código aquí (no el original):

function useDataFetching(apiEndpoint) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchData() {
      try {
        let response = await fetch(apiEndpoint);
        let result = await response.json();
        setData(result);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    }

    fetchData();
  }, [apiEndpoint]);

  return { data, loading, error };
}

Con useDataFetching, saqué la lógica de llamada de la API y manejé los estados de carga y error. Ahora, el componente sólo necesita llamar a este enlace y obtener los datos necesarios, de forma limpia y sencilla.

Simplificando la lógica de la interfaz de usuario
A continuación, miré la lógica de renderizado. Anteriormente, estaba verificando la carga, los errores y los datos dentro de la función de renderizado, lo que hacía que fuera bastante difícil de seguir. Separé esta lógica en funciones pequeñas e independientes, algo como esto (por supuesto, no la original;)

function renderLoading() {
  return 
Loading...
;
}

function renderError(error) {
  return 
Error: {error.message}
;
}

function renderData(data) {
  return 
{/* Complex UI logic here */}
;
}
//After that, component is ni much pretty shape

function MyComponent() {
  const { data, loading, error } = useDataFetching('/api/data-endpoint');

  if (loading) return renderLoading();
  if (error) return renderError(error);
  if (data) return renderData(data);

  return null;
}

Charla final

Después de desglosar el componente, el archivo pasó de más de 540 líneas a aproximadamente 124, con una lógica que es mucho más fácil de seguir. El componente ahora hace una cosa: renderizar la interfaz de usuario. Todo lo demás se ha descargado en ganchos personalizados y funciones de utilidad.

Esta experiencia reforzó algunas lecciones clave para mí:

• No temas refactorizar: es fácil dejar el código desordenado como está, especialmente cuando funciona. Pero tomarse el tiempo para limpiarlo hace que su vida (y la de su yo futuro) sea mucho más fácil.

• Separación de inquietudes: mantener diferentes inquietudes en diferentes lugares (estado, API, UI) hizo que el código fuera más modular, reutilizable y comprobable.

• Mantenlo simple: simplificar la función de renderizado al descargar la lógica a funciones más pequeñas hizo que el componente fuera mucho más legible.

Entonces, si tienes un componente desordenado como el tuyo, no dudes en refactorizarlo. No se trata sólo de código limpio, sino de hacerle la vida más fácil como desarrollador. ¿Y quién no querría eso?