Partager l’état et le routage entre applications distantes

Chaque application distante de Module Federation est compilée et déployée indépendamment. Son état (useState de React, contexte et gestionnaires d’état Zustand) vit dans sa propre portée de module JavaScript. L’hôte et les applications distantes ne partagent pas automatiquement leur état : vous devez concevoir explicitement ce partage.

Le mécanisme de partage d’état le plus simple est l’URL : toute application distante peut lire les paramètres d’URL, les chaînes de requête et les valeurs de fragment sans aucune communication entre applications distantes. Cette méthode convient bien à l’état principal de la navigation, aux valeurs des filtres et à tout état qui doit pouvoir être ajouté aux favoris et partagé par lien.

CustomEvents, via EventTarget du navigateur, permettent aux applications distantes de communiquer sans importations directes. Une application distante exécute window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), et tout autre module (l’hôte ou une autre application distante) écoute avec window.addEventListener('cart:updated', handler). Aucun module partagé n’est nécessaire.

Créez une application distante dédiée à l’état qui expose un gestionnaire d’état Zustand ou Jotai. L’hôte et les autres applications distantes l’importent depuis cette application distante et obtiennent la même instance du gestionnaire, puisqu’il s’agit d’un singleton partagé. Cette solution est puissante pour les états complexes partagés (authentification, panier, préférences utilisateur), mais elle ajoute une dépendance de déploiement.

Le conteneur (hôte) possède tout l’état partagé et le transmet aux applications distantes sous forme de propriétés ou via le contexte. Les applications distantes reçoivent des fonctions de rappel comme onCartUpdate et la navigation sous forme de propriétés. Cela centralise l’état dans l’hôte, mais oblige celui-ci à connaître les interfaces des applications distantes, ce qui crée un couplage fort.

L’historique et l’état de l’emplacement de React Router sont fournis par un composant de routeur (BrowserRouter ou createBrowserRouter). Une architecture Module Federation doit contenir exactement un routeur : en placer un dans chaque application distante créerait plusieurs contextes de routage concurrents et provoquerait des conflits de navigation.

La règle architecturale est la suivante : l’hôte (le conteneur) fournit le routeur. Les applications distantes reçoivent les propriétés de routage de l’hôte ou lisent directement l’URL. Une application distante ne doit jamais créer son propre BrowserRouter : cela entrerait en conflit avec le routeur de l’hôte et interromprait la navigation de toute l’application.

Les valeurs du contexte React sont liées à une instance React et à un objet de contexte spécifiques. Pour qu’un contexte fonctionne entre l’hôte et une application distante, les deux doivent importer le même objet de contexte depuis la même source, généralement l’application distante d’état partagé ou un paquet d’utilitaires partagé. L’instance unique de React garantit que le même contexte fonctionne dans toutes les applications distantes.

Dans une architecture Module Federation claire, le conteneur (hôte) possède : la structure HTML, le fournisseur du routeur, le contexte d’authentification, le fournisseur du thème et des jetons de conception, ainsi que la navigation globale. Les applications distantes possèdent le contenu de leur domaine fonctionnel. Le conteneur compose les applications distantes dans la mise en page sans connaître les détails de leur implémentation.

Le principal anti-modèle de Module Federation est le couplage fort entre l’hôte et les applications distantes : l’hôte importe des types depuis une application distante, l’application distante importe des composants depuis l’hôte ou les deux partagent un paquet npm commun qu’ils doivent mettre à jour simultanément. Ces couplages vont à l’encontre de l’objectif du déploiement indépendant.

Définissez des contrats explicites entre l’hôte et les applications distantes : les propriétés qu’un composant distant accepte, les CustomEvents qu’il distribue et les paramètres d’URL qu’il lit. Documentez ces contrats sous forme d’interfaces TypeScript dans un paquet de types partagé. Les équipes peuvent ainsi évoluer indépendamment dans le cadre du contrat convenu.

Où faut-il placer le fournisseur de React Router (BrowserRouter) dans une architecture Module Federation ?

Le partage d’état entre les applications distantes de Module Federation peut utiliser l’état de l’URL (solution la plus simple), les CustomEvents (couplage faible), une application distante d’état partagé (gestionnaire centralisé) ou un état géré par l’hôte et transmis sous forme de propriétés. L’hôte doit posséder l’unique fournisseur du routeur : les applications distantes ne doivent jamais créer le leur. Des contrats de communication clairs, définis par des interfaces TypeScript, maintiennent l’indépendance des équipes et permettent un véritable déploiement indépendant.