Migration jQuery vers React avec mesure des performances avant/après

Contexte

Projet réalisé en formation (parcours Développeur JavaScript React, OpenClassrooms). Mission fictive pour « WealthHealth » : migrer HRnet, une application RH interne vieillissante en jQuery, vers React. Consigne stricte du brief : 100% React, 0% jQuery — pas de mélange des deux approches. Parmi les quatre plugins jQuery de l'application (sélecteur de date, fenêtre modale, menu déroulant, tableau de données), un seul devait être converti en composant React et publié comme package npm indépendant ; les trois autres pouvaient être recodés à la main ou remplacés par une bibliothèque existante.

Architecture générale

Application React 18 avec Create React App, routage via react-router-dom (trois routes : création d'employé sur /, liste des employés sur /employees-list, page d'erreur générique en fallback). Exclusivement des composants fonctionnels avec Hooks, conformément à la contrainte du brief d'éviter les classes.

Gestion d'état avec Redux

Store Redux unique (pas de combineReducers, un seul reducer suffisant vu le périmètre) avec redux-thunk pour gérer les actions asynchrones. Trois types d'action (IS_LOADING, LOADING_ERROR, DISPLAY_EMPLOYEES, ADD_EMPLOYEE) couvrant le cycle de chargement et d'ajout des employés. La persistance des données continue de reposer sur le localStorage du navigateur (l'application n'a pas de backend, comme dans la version jQuery d'origine), mais transite désormais systématiquement par le store Redux plutôt que d'être lue/écrite directement dans les composants — le brief demandait explicitement l'ajout d'un système de gestion d'état, sans exiger de vrai backend.

Le plugin converti et publié sur npm

Le menu déroulant est le plugin choisi pour la conversion complète exigée par le brief. Publié comme package npm indépendant sous le nom doubeck-react-select (version 1.1.0, dépôt GitHub séparé), avec sa propre documentation d'installation et d'usage. Le composant attend un tableau d'objets possédant une clé name, ignore les clés superflues, et notifie le parent via un callback updateSelect(valeur, nom_du_champ) — une API volontairement minimale pour rester réutilisable en dehors de ce projet précis.

Les trois autres composants

Sélecteur de date : composant très léger, un simple wrapper contrôlé autour de l'<input type="date"> natif HTML5 plutôt qu'une réimplémentation calendrier complète — choix pragmatique, le natif couvrant déjà le besoin. Fenêtre modale (PopIn) : composant piloté par une prop mode (show/hide) et un callback de fermeture, sans dépendance externe. Tableau de données : react-bootstrap-table-next associé à ses modules de pagination et de recherche (barre de recherche + bouton d'effacement) — bibliothèque existante plutôt que composant maison, conformément à l'option du brief d'importer une lib en cas de contrainte de temps.

Navigation contextuelle

Le header adapte son lien de navigation selon l'URL courante (window.location.href) : propose « Current employees » depuis la page de création, et inversement « Create employee » depuis la liste — une seule paire de pages, navigation la plus simple possible entre elles.

Tests de performance

Audit Lighthouse comparatif avant/après conversion, réalisé sur build de production. Résultats : Performance passée de 91 à 98, Accessibilité passée de 87 à 100 — la conversion en React a mesurablement amélioré les deux scores, confirmant l'hypothèse de départ du brief sur le coût de performance des plugins jQuery tiers.

Note

Le fichier App.test.js est resté celui généré par défaut par Create React App (recherche du texte « learn react », absent de l'application réelle) — il aurait échoué s'il avait été exécuté. Le brief autorisait explicitement à se limiter à des tests manuels faute de temps, ce n'est donc pas un écart au cahier des charges, seulement un fichier resté non nettoyé.