0Pricing
Micro Frontends Architecture with Module Federation · บทเรียน

การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน

เรียนรู้วิธีแชร์ไลบรารีและสิ่งที่ต้องพึ่งพาร่วมกันระหว่างแอปพลิเคชันแบบสหพันธ์อย่างมีประสิทธิภาพ

การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน เป็นบทเรียน Micro Frontends Architecture with Module Federation ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Micro Frontends Architecture with Module Federation และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Micro Frontends Architecture with Module Federation มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Why Share Dependencies?

In Micro Frontends, different parts of your application might use the same libraries, like React, Vue, or Lodash. Without careful management, each Micro Frontend could bundle its own copy of these libraries.

This means users would download the same code multiple times, increasing load times and wasting bandwidth. Sharing dependencies solves this problem!

The Problem: Duplicate Bundles

Imagine your main 'Host' application uses React, and a 'Remote' Micro Frontend also uses React. If both bundle React independently, your user's browser ends up downloading React twice.

  • Host Bundle: Includes React
  • Remote Bundle: Includes React (again!)

This leads to larger overall application sizes and slower performance.

Module Federation's Solution

Webpack's Module Federation offers a powerful solution: the shared configuration. It allows you to declare common libraries that should be shared across your federated applications.

Module Federation then ensures these libraries are loaded only once, even if multiple Micro Frontends depend on them.

Configuring `shared`

You define shared dependencies within the ModuleFederationPlugin in your webpack.config.js file. The shared property is an object where each key is the name of a module you want to share.

Here's a basic look at how it's structured:

new ModuleFederationPlugin({
  // ... other configs
  shared: {
    // 'module-name': { options }
    'react': { /* ... */ },
    'react-dom': { /* ... */ }
  }
})

Sharing with `requiredVersion`

The requiredVersion option is crucial for compatibility. It specifies the acceptable version range for a shared dependency using semantic versioning (e.g., ^18.0.0).

Module Federation will try to use a compatible version already loaded; if none exists or it's incompatible, it will load a new one.

shared: {
  react: {
    requiredVersion: '^18.0.0',
    // other options like singleton: true
  },
  'react-dom': {
    requiredVersion: '^18.0.0'
  }
}

The `eager` Property Explained

Normally, shared modules are loaded asynchronously, on demand. However, sometimes a shared module is needed immediately at startup, before any remote modules are even requested.

For such cases, you can use the eager: true option. Be cautious, as this can impact initial load performance by forcing the module to load upfront.

shared: {
  'my-critical-lib': {
    requiredVersion: '^1.0.0',
    eager: true // Load this module immediately
  }
}

Host & Remote `shared` Configs

Both your host and remote applications should typically define the same common libraries as shared. This tells Module Federation that these dependencies are part of the shared pool.

Module Federation then orchestrates which application actually loads the dependency and makes it available to others, ensuring only one copy exists in the browser.

Practical Use of Shared Deps

When react and react-dom are configured as shared, your application code can simply import them as usual. Module Federation handles the underlying logic to ensure they are loaded efficiently and only once.

This minimal React entry point demonstrates how standard imports leverage shared dependencies:

import React from 'react';
import ReactDOM from 'react-dom/client';

// This is a minimal React app entry point.
// If 'react' and 'react-dom' are shared in Module Federation,
// these imports will efficiently use a single instance.
function App() {
  return (
    <div>
      <h1>Shared Dependencies Demo</h1>
      <p>This app uses React, which can be shared!</p>
    </div>
  );
}

const rootElement = document.getElementById('root');
if (rootElement) {
  const root = ReactDOM.createRoot(rootElement);
  root.render(
    <React.StrictMode>
      <App />
    </React.StrictMode>
  );
} else {
  console.error("Root element not found!");
}

Benefits of Sharing Libraries

  • Smaller Bundle Sizes: Prevents common libraries from being duplicated across different Micro Frontends, directly reducing the total amount of code users download.
  • Improved Performance: Less code to download, parse, and execute means faster initial page load times and a more responsive user experience.
  • Consistent Versions: Helps ensure all parts of your federated application use the same version of a library, reducing potential conflicts and unexpected behavior.

Shared Dependencies Check

Module Federation's shared configuration is crucial for efficient Micro Frontends. Which option correctly describes a key benefit of using shared dependencies?

Recap & Next Steps

We've learned how Module Federation's shared configuration is vital for optimizing Micro Frontends. By defining common libraries as shared, you prevent them from being bundled multiple times.

This leads to smaller initial load times, better performance, and more consistent dependency versions across your federated applications.

Next, we'll dive deeper into managing Singleton Modules & Versioning to ensure robust shared dependency handling.

คำถามที่พบบ่อย

บทเรียน “การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Micro Frontends Architecture with Module Federation ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Micro Frontends Architecture with Module Federation มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน”

เรียนรู้วิธีแชร์ไลบรารีและสิ่งที่ต้องพึ่งพาร่วมกันระหว่างแอปพลิเคชันแบบสหพันธ์อย่างมีประสิทธิภาพ คุณปฏิบัติ Micro Frontends Architecture with Module Federation ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Micro Frontends Architecture with Module Federation หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Micro Frontends Architecture with Module Federation บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Micro Frontends Architecture with Module Federation นี้ได้ไหม

ได้ บทเรียน Micro Frontends Architecture with Module Federation ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การเรียกใช้สิ่งที่ต้องพึ่งพาร่วมกัน
  2. โมดูลซิงเกิลตันและการจัดการเวอร์ชัน
  3. การโหลดโมดูลแบบไดนามิก
  4. การแชร์สถานะและยูทิลิตีระหว่างแอประยะไกล
← กลับไปที่ Micro Frontends Architecture with Module Federation