12. Conclusion

Nous avons écrit le client [React] de l'application [RdvMedecins]. Pour l'utilisateur, il offre les mêmes pages que l'application HTML du cours [NestJS], et que les clients [Vue.js] et [Angular] des cours précédents ; pour le développeur, tout a changé de place :

le serveur ne fabrique plus de pages. Il expose une API JSON, dont le contrat (routes, corps, codes et clés d'erreur) a suffi pour écrire le client, sans jamais lire son code. Le serveur est d'ailleurs exactement celui des clients [Vue.js] et [Angular] : seuls ses commentaires ont changé ;
les pages, la langue, la mise en forme, les messages, la navigation se sont déplacés dans le navigateur ;
la sécurité, elle, n'a pas bougé : c'est toujours le serveur qui authentifie (cookie [HttpOnly]), qui vérifie les rôles et les règles de gestion, et qui décide de ce qu'un patient a le droit de voir. Le client ne fait qu'afficher ce que le serveur lui envoie.

Le lecteur qui a suivi les trois cours peut comparer les trois frameworks sur la même application :

[React] est une bibliothèque d'affichage plus qu'un framework complet : des composants, qui sont des fonctions, du JSX, et des hooks. Pour le reste, il a fallu choisir : [React Router] pour les pages, [TanStack Query] pour les données du serveur, [Zustand] pour l'état partagé, [i18next] pour les langues, [Vite] pour construire. Cette liberté a un prix : deux applications [React] peuvent ne pas se ressembler du tout ;
[Angular], à l'inverse, fournit tout (routeur, formulaires, client HTTP, intercepteurs, outils de construction), avec une manière recommandée de les utiliser : davantage de code et de notions (classes, décorateurs, injection de dépendances, observables), mais des applications qui se ressemblent toutes ;
[Vue.js] se tient entre les deux : un routeur et un magasin officiels, des templates proches du HTML ;
la réactivité, enfin, n'est pas la même. [Vue.js] et [Angular] suivent des signaux : quand une valeur change, seul ce qui en dépend est mis à jour. [React] ré-exécute le composant dont l'état a changé, puis compare le résultat au précédent : c'est plus simple à comprendre (un composant est une fonction de ses props et de son état), mais c'est au développeur de déclarer les dépendances des effets, et de stabiliser certaines valeurs ([useCallback], les clés [key]). Le compilateur de [React] ([React Compiler]), qu'on peut ajouter au projet, fait ce travail de stabilisation automatiquement.

Les notions de [React] rencontrées dans ce cours (composants, props, état, effets, hooks personnalisés, contextes, actions de formulaire, [Suspense]) sont celles de toute application [React] récente. Pour aller plus loin :

la documentation officielle, https://react.dev, et ses tutoriels ;
les tests : [Vitest] et [Testing Library] pour les tests unitaires des composants et des hooks, [Playwright] pour les tests de bout en bout (c'est avec lui qu'ont été faites les copies d'écran de ce document) ;
le rendu côté serveur : le mode « framework » de [React Router], ou [Next.js], fabriquent la première page sur le serveur, et les composants serveur de [React] y lisent directement les données : on retrouverait alors, en partie, l'architecture du cours [NestJS] ;
le cours Un exemple de client / serveur React / NestJS (2026), qui étudie à la fois un client [React] et son serveur.