Gestion de l’état partagé
Découvrez des stratégies de gestion de l’état partagé entre des applications fédérées, telles que Redux ou l’API Context.
Gestion de l’état partagé est une leçon Micro Frontends Architecture with Module Federation gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Micro Frontends Architecture with Module Federation, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Micro Frontends Architecture with Module Federation comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
What is Shared State?
In Micro Frontends, shared state refers to data that needs to be accessible and consistent across different, independently developed and deployed applications.
- Think of user authentication status, global theme settings, or shopping cart contents.
- This state isn't owned by a single micro frontend but is crucial for a cohesive user experience.
Managing this state effectively is key to building complex federated applications.
Why Shared State in MFEs?
When you have multiple micro frontends making up a single user interface, they often need to react to the same global information.
- User Experience: A user logs in on one MFE, and others need to know they're authenticated.
- Consistency: Applying a global theme preference across all parts of the application.
- Data Flow: Passing data from one MFE (e.g., product selection) to another (e.g., checkout).
Without shared state, each MFE would manage its own isolated data, leading to inconsistencies and a disjointed user journey.
Challenges of Shared State
While essential, sharing state in a Micro Frontend architecture comes with unique challenges:
- Isolation: MFEs are designed to be independent. Breaking this isolation needs careful planning.
- Framework Agnosticism: Different MFEs might use different JavaScript frameworks (React, Angular, Vue).
- Performance: Inefficient sharing can lead to redundant data fetching or slow updates.
- Complexity: Deciding ownership, update mechanisms, and preventing conflicts can be complex.
We need strategies that balance independence with the necessity of shared information.
Simple Shared State: Local Storage
For very basic, non-sensitive, and persistent state, browser's Local Storage can be a quick solution. Each MFE can read from and write to it.
However, it's not reactive, meaning MFEs don't automatically update when Local Storage changes. It's also not suitable for complex or real-time state.
Try setting and getting an item:
localStorage.setItem('appTheme', 'dark');
console.log('Theme set to dark.');
const currentTheme = localStorage.getItem('appTheme');
console.log('Current theme:', currentTheme);
// To remove:
// localStorage.removeItem('appTheme');
// console.log('Theme removed.');Centralized State Stores
For more complex and reactive shared state, a centralized state store is a common pattern. Libraries like Redux are popular examples.
- A single source of truth for your application's state.
- Predictable state changes through actions and reducers.
- Easier debugging and traceability of state modifications.
In a federated setup, a host or a dedicated remote MFE can expose such a store for others to consume.
Building a Simple Global Store
Let's create a basic, framework-agnostic global store. This store will hold our shared state and allow components to subscribe to changes. This mimics how a Redux store would function at a high level.
Run this code to see a simple store in action:
let sharedState = { userStatus: 'loggedOut', notifications: [] };
const subscribers = [];
function getSharedState() {
return sharedState;
}
function dispatchAction(action) {
switch (action.type) {
case 'LOGIN':
sharedState = { ...sharedState, userStatus: 'loggedIn' };
break;
case 'ADD_NOTIFICATION':
sharedState = { ...sharedState, notifications: [...sharedState.notifications, action.payload] };
break;
default:
return;
}
subscribers.forEach(cb => cb(sharedState));
}
function subscribe(callback) {
subscribers.push(callback);
return () => {
const index = subscribers.indexOf(callback);
if (index > -1) subscribers.splice(index, 1);
};
}
// --- Example Usage ---
console.log('Initial state:', getSharedState());
const unsubscribe = subscribe(newState => {
console.log('State updated:', newState);
});
dispatchAction({ type: 'LOGIN' });
dispatchAction({ type: 'ADD_NOTIFICATION', payload: 'Welcome!' });
unsubscribe();
console.log('Unsubscribed from updates.');Consuming the Global Store
Now, imagine different Micro Frontends needing to react to changes in this global store. They would use the getSharedState and subscribe functions.
This example demonstrates how two 'virtual' MFEs could interact with the shared store, reacting to updates.
let sharedState = { userStatus: 'loggedOut', notifications: [] };
const subscribers = [];
function getSharedState() { return sharedState; }
function dispatchAction(action) {
switch (action.type) {
case 'LOGIN': sharedState = { ...sharedState, userStatus: 'loggedIn' }; break;
case 'ADD_NOTIFICATION': sharedState = { ...sharedState, notifications: [...sharedState.notifications, action.payload] }; break;
case 'LOGOUT': sharedState = { ...sharedState, userStatus: 'loggedOut' }; break;
default: return;
}
subscribers.forEach(cb => cb(sharedState));
}
function subscribe(callback) {
subscribers.push(callback);
return () => { const index = subscribers.indexOf(callback); if (index > -1) subscribers.splice(index, 1); };
}
// --- MFE A (e.g., Header Component) ---
function handleUserStatusChange(state) {
console.log('MFE A: User status is now', state.userStatus);
}
const unsubscribeMFEA = subscribe(handleUserStatusChange);
// --- MFE B (e.g., Notification Bell) ---
function handleNotificationsChange(state) {
console.log('MFE B: Notifications:', state.notifications.length);
}
const unsubscribeMFEB = subscribe(handleNotificationsChange);
// Simulate actions from other MFEs or host
dispatchAction({ type: 'LOGIN' });
dispatchAction({ type: 'ADD_NOTIFICATION', payload: 'New message!' });
dispatchAction({ type: 'LOGOUT' });
unsubscribeMFEA();
unsubscribeMFEB();React Context API for MFEs
If your Micro Frontends are all built with React, the Context API can be a powerful way to share state. A Context provides a way to pass data through the component tree without having to pass props down manually at every level.
- Create a Context in a shared library or a host MFE.
- Expose this Context via Module Federation.
- Remote MFEs can then consume this Context directly.
This approach works well when all federated applications are within the same React ecosystem.
Sharing React Context (Concept)
To share React Context, you'd typically:
- Define Context: Create
MyContext.jsin a shared utility MFE. - Expose Context: Use Module Federation to expose
MyContext.ProvideranduseContext(MyContext). - Provide Context: The host MFE (or a parent MFE) wraps its children (including remote MFEs) with the
<MyContext.Provider value={...}>. - Consume Context: Any remote MFE can then import and use
useContext(MyContext)to access the shared state.
This allows a deeply nested component in a remote MFE to access state provided by a parent MFE.
Question: Shared State Benefits
You've learned about various approaches to managing shared state in Micro Frontends.
Which of the following is a primary benefit of implementing robust shared state management in a Micro Frontend architecture?
Recap: Shared State Management
We've explored key strategies for managing shared state in Micro Frontends:
- Need: Essential for consistent user experience and data flow across independent MFEs.
- Challenges: Maintaining isolation, framework compatibility, and managing complexity.
- Simple Methods: Local Storage for basic, non-reactive data.
- Centralized Stores: Using patterns like Redux to create a single source of truth, accessible by all MFEs.
- React Context: An effective solution for sharing state when all MFEs are within the React ecosystem.
Choosing the right strategy depends on your team's needs, framework choices, and the complexity of the shared data.
Questions Fréquemment Posées
La leçon « Gestion de l’état partagé » est-elle gratuite ?
Oui — le texte complet de « Gestion de l’état partagé » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Micro Frontends Architecture with Module Federation, passe à CoddyKit PRO. Le cours Micro Frontends Architecture with Module Federation comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Gestion de l’état partagé » ?
Découvrez des stratégies de gestion de l’état partagé entre des applications fédérées, telles que Redux ou l’API Context. Tu pratiques Micro Frontends Architecture with Module Federation avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Micro Frontends Architecture with Module Federation ?
Aucune expérience préalable n'est requise. Micro Frontends Architecture with Module Federation sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « Gestion de l’état partagé » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Micro Frontends Architecture with Module Federation ?
Oui. Chaque leçon Micro Frontends Architecture with Module Federation inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Bus d’événements pour la communication entre applications
- Gestion de l’état partagé
- Solutions de communication personnalisées
- Communiquer avec les événements DOM personnalisés