Micro Frontends Architecture with Module Federation · 강의

공유 상태 관리

Redux나 Context API처럼 모듈 연합 애플리케이션 전반에서 공유 상태를 관리하는 전략을 살펴봅니다.

공유 상태 관리은(는) CoddyKit의 무료 Micro Frontends Architecture with Module Federation 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Micro Frontends Architecture with Module Federation 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Micro Frontends Architecture with Module Federation 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

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.js in a shared utility MFE.
Expose Context: Use Module Federation to expose MyContext.Provider and useContext(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.

자주 묻는 질문

“공유 상태 관리” 강의는 무료인가요?

네 — “공유 상태 관리” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Micro Frontends Architecture with Module Federation 강의 전체를 잠금 해제할 수 있습니다. Micro Frontends Architecture with Module Federation 강의에는 총 4개의 강의가 포함되어 있습니다.

“공유 상태 관리”에서 뭘 배우나요?

Redux나 Context API처럼 모듈 연합 애플리케이션 전반에서 공유 상태를 관리하는 전략을 살펴봅니다. 브라우저에서 직접 실행하는 실습 코드로 Micro Frontends Architecture with Module Federation을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Micro Frontends Architecture with Module Federation을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Micro Frontends Architecture with Module Federation은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“공유 상태 관리” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Micro Frontends Architecture with Module Federation 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Micro Frontends Architecture with Module Federation 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Micro Frontends Architecture with Module Federation(으)로 돌아가기