Apprivoiser la bête : comment j'ai refactorisé un composant Messy React

Nous sommes tous passés par là. Vous ouvrez un composant React que vous avez écrit il y a quelques mois, et vous avez l'impression de regarder du code écrit par quelqu'un qui était pressé – parce que vous l'étiez probablement. Les délais approchaient et les fonctionnalités devaient être expédiées. Avance rapide jusqu’à aujourd’hui, et il est temps de refactoriser ce composant désordonné.

Alors, voici comment je l’ai abordé.

L'horreur initiale

La première chose que j'ai remarquée, c'est que le composant était devenu beaucoup trop gros. Il essayait de tout faire, comme gérer l'état, effectuer des appels d'API, gérer une logique d'interface utilisateur complexe et même appliquer des styles directement. Il s'agissait d'un seul fichier de plus de 540 lignes, et le lire donnait l'impression de se promener dans une jungle sans carte.

La première étape a été d'accepter la réalité : ce code n'était plus maintenable. Si moi, la personne qui l’ai écrit, pouvais à peine suivre ce qui se passait, quelqu’un d’autre n’aurait aucune chance. Alors, j'ai décidé de le décomposer.

Le décomposer

J'ai commencé par identifier les différentes responsabilités du composant. Il y avait trois domaines clairs :

1. Gestion de l'état : la gestion de l'état du composant était étroitement liée à la logique de l'interface utilisateur.

2. Appels API : récupération des données et gestion des états de chargement.

3. Rendu de l'interface utilisateur : affichage des données dans une structure d'interface utilisateur quelque peu complexe.
   Chacune de ces responsabilités devait être séparée.

Extraction de hooks pour l'état et la logique API

La première chose que j'ai faite a été d'extraire la gestion de l'état et la logique de l'API dans des hooks personnalisés. Cela a non seulement nettoyé le composant, mais a également facilité le test et la réutilisation de la logique ailleurs.

Mentionner un code ici (pas celui d'origine) :

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 };
}

Avec useDataFetching, j'ai extrait la logique d'appel de l'API et géré les états de chargement et d'erreur. Désormais, le composant n'a plus qu'à appeler ce hook et obtenir les données nécessaires, propres et simples.

Simplification de la logique de l'interface utilisateur
Ensuite, j'ai regardé la logique de rendu. Auparavant, je vérifiais le chargement, les erreurs et les données dans la fonction de rendu, ce qui rendait le suivi assez difficile. J'ai séparé cette logique en petites fonctions autonomes, quelque chose comme ça (bien sûr pas celle d'origine ;)

function renderLoading() {
  return <p>Loading...</p>;
}

function renderError(error) {
  return <p>Error: {error.message}</p>;
}

function renderData(data) {
  return <div>{/* Complex UI logic here */}</div>;
}
//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;
}

Discours final

Après avoir décomposé le composant, le fichier est passé de plus de 540 lignes à environ 124, avec une logique beaucoup plus facile à suivre. Le composant fait désormais une chose : restituer l'interface utilisateur. Tout le reste a été déchargé vers des hooks personnalisés et des fonctions utilitaires.

Cette expérience a renforcé quelques leçons clés pour moi :

• Ne craignez pas la refactorisation : il est facile de laisser du code désordonné tel quel, surtout lorsqu'il fonctionne. Mais prendre le temps de tout nettoyer rend votre vie – et celle de votre futur – tellement plus facile.

• Séparation des préoccupations : le fait de conserver différentes préoccupations à différents endroits (état, API, interface utilisateur) a rendu le code plus modulaire, réutilisable et testable.

• Gardez les choses simples : simplifier la fonction de rendu en déchargeant la logique vers des fonctions plus petites a rendu le composant beaucoup plus lisible.

Donc, si vous avez un composant en désordre comme vous, n'hésitez pas à le refactoriser. Il ne s’agit pas seulement d’un code propre, il s’agit également de vous faciliter la vie en tant que développeur. Et qui ne voudrait pas de ça ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!