Micro Frontends Architecture with Module Federation · درس

الوحدات Singleton وإدارة الإصدارات

افهم كيفية ضمان تحميل نسخة واحدة فقط من الوحدة وإدارة تعارضات الإصدارات

الوحدات Singleton وإدارة الإصدارات درس مجاني في Micro Frontends Architecture with Module Federation على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Micro Frontends Architecture with Module Federation، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Micro Frontends Architecture with Module Federation 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

What are Singleton Modules?

In Micro Frontend architectures, a singleton module is a piece of code or a library that should only ever exist as a single instance across your entire application, even if multiple Micro Frontends try to load it.

Think of it as a unique resource that all parts of your system need to share consistently.

Ensures a single source of truth.
Prevents conflicting states or behaviors.

Why Singletons Matter for MFEs

Imagine multiple Micro Frontends (MFEs) all loading their own copy of a UI library like React, or a state management library like Redux.

Without singletons, you could end up with:

Multiple instances of React Context, breaking component communication.
Separate Redux stores, leading to inconsistent application state.
Increased bundle size due to duplicate code.

Singletons solve these issues by guaranteeing a unified dependency.

Implementing Singletons with MF

Module Federation makes it easy to declare shared modules as singletons using the singleton: true option in your Webpack configuration.

When this is set, Webpack ensures that only one version of the specified module is loaded and used by all federated applications (hosts and remotes) at runtime.

Code: Configuring a Singleton

Here's how you'd configure a shared module, like react, to be a singleton in your webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  // ... other Webpack config
  plugins: [
    new ModuleFederationPlugin({
      name: 'host_app',
      remotes: {},
      shared: {
        react: {
          singleton: true, // Only one React instance allowed
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true, // Only one ReactDOM instance allowed
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

Understanding Shared Module Versioning

Beyond ensuring a single *instance* (singleton), you also need to manage which *version* of a shared module gets loaded.

What if one MFE needs React v17 and another needs React v18? Module Federation has mechanisms to handle these version conflicts and ensure compatibility or gracefully fail.

`requiredVersion` for Specificity

The requiredVersion option in the shared configuration allows you to specify the semantic version (semver) range that your application expects for a shared module.

Webpack will try to find a compatible version among the host and remote applications. If a compatible version is found, it's used. If not, it might load a fallback or throw an error, depending on other settings.

Code: Specifying Required Versions

Here's how you might define a requiredVersion for a shared library:

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      // ...
      shared: {
        lodash: {
          singleton: false,
          requiredVersion: '^4.17.21', // Any version compatible with 4.17.21
        },
        moment: {
          singleton: true,
          requiredVersion: '2.29.1', // Exactly version 2.29.1
        },
      },
    }),
  ],
};

`strictVersion: true` for Strictness

While requiredVersion guides version selection, strictVersion: true enforces it rigorously.

If strictVersion: true is enabled and a remote module requests a version that is incompatible with the host's requiredVersion (or the version already loaded), Module Federation will throw an error and prevent the application from loading. This prevents unexpected behavior from version mismatches.

Code: Enforcing Strict Versioning

Combining singleton, requiredVersion, and strictVersion for critical dependencies:

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      // ...
      shared: {
        react: {
          singleton: true,
          requiredVersion: '^18.0.0',
          strictVersion: true, // Fail if versions are incompatible
        },
        // ... other shared modules
      },
    }),
  ],
};

Best Practices for Shared Dependencies

To effectively manage singleton modules and versioning:

Use Semantic Versioning (SemVer): Adhere to major.minor.patch for all shared modules.
Communicate: Ensure teams are aware of shared module updates and version requirements.
Test Compatibility: Regularly test your federated applications to ensure shared modules work across all remotes and hosts.
Be Strategic: Not all shared modules need to be singletons or have strict versioning. Apply these settings thoughtfully based on the module's criticality.

Quick Check: Singleton & Versioning

When configuring shared modules in Module Federation, what are the primary benefits of using singleton: true and strictVersion: true?

Recap & Next Steps

You've now learned about singleton modules and versioning in Module Federation!

Singleton modules ensure only one instance of a shared dependency exists across your federated application, crucial for stateful libraries.
The requiredVersion and strictVersion options help manage compatibility and prevent issues arising from conflicting module versions.

These techniques are vital for building robust and predictable Micro Frontend applications.

الأسئلة الشائعة

هل درس «الوحدات Singleton وإدارة الإصدارات» مجاني؟

نعم — نص درس «الوحدات Singleton وإدارة الإصدارات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Micro Frontends Architecture with Module Federation، انتقل إلى CoddyKit PRO. تتضمن دورة Micro Frontends Architecture with Module Federation 4 دروس في المجموع.

ماذا ستتعلم في «الوحدات Singleton وإدارة الإصدارات»؟

افهم كيفية ضمان تحميل نسخة واحدة فقط من الوحدة وإدارة تعارضات الإصدارات تتمرن على Micro Frontends Architecture with Module Federation مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Micro Frontends Architecture with Module Federation؟

لا تُشترط خبرة سابقة. Micro Frontends Architecture with Module Federation على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.

كم من الوقت يستغرق درس «الوحدات Singleton وإدارة الإصدارات»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Micro Frontends Architecture with Module Federation هذا؟

نعم. كل درس في Micro Frontends Architecture with Module Federation يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

استهلاك التبعيات المشتركة
الوحدات Singleton وإدارة الإصدارات
التحميل الديناميكي للوحدات
مشاركة الحالة والأدوات عبر التطبيقات البعيدة

← العودة إلى Micro Frontends Architecture with Module Federation