الهدف الرئيسي

تحقيق عزلة قوية لكل micro-frontend (حماية الـ CSS، DOM، وتبعيات كل تطبيق فرعي).

مشاركة أجزاء محددة من الحالة (state) بين التطبيقات الفرعية كـ single source of truth (مثلاً: جلسة المستخدم، سلة المشتريات، إعدادات عامة).

الحفاظ على أداء عالٍ وتقليل إعادة الرندر وتكرار تحميل المكتبات.


ثلاثة أنماط عملية لمشاركة الحالة

1. مشاركة عبر حزمة مشتركة/مونو-ريبو (Module Federation أو ما يُكافئها)

الفكرة: وجود مصدر واحد للحالة يُعرَض لكل التطبيقات الفرعية في وقت التشغيل بحيث يحصل كل تطبيق على نفس نسخة الـ store (singleton).

المزايا: مشاركة حقيقة وحيدة للحالة، تكامل سلس مع آليات الـ Provider والـ hooks، تقليل تعارض النسخ.

العيوب: يتطلب تنسيق في عملية البناء/النشر، وإدارة توافق الإصدارات بين الحزم.



2. الـ Host يوفّر Provider مركزي

الفكرة: الـ Shell أو المضيف ينشئ الـ store ويزوّد التطبيقات الفرعية بواجهة أو مزود (Provider) لاستعماله داخل شجرة React أو إطار العمل المستخدم.

المزايا: تحكم مركزي، سهولة مراقبة الحالة وأدوات المطور (DevTools)، وضوح مصدر الحقيقة.

العيوب: يحتاج اتفاقية تكامل بين الـ shell والـ remotes وقد يتطلب نسخ React متوافقة أو حلول للنسخ المتعددة.



3. فصل كامل مع تزامن عبر قنوات رسائل (Event Bus / BroadcastChannel / postMessage)

الفكرة: كل تطبيق يحتفظ بنسخته المحلية من الـ state، والتزامن يتم عبر إرسال واستقبال رسائل تبادل حالة بين التطبيقات.

المزايا: عزلة قوية جداً، مناسب للتطبيقات المنشورة بشكل مستقل تمامًا أو عند استخدام iframes أو عبر أصول مختلفة.

العيوب: توافق eventual consistency (لا يكون التزامن فورياً دائماً)، تعقيد في حل التعارضات، ومزيد من الجهد لضمان سلامة الحالة.




متى تختار أي نمط؟

اختر نمط الـ Module Federation / حزمة مشتركة إذا كان بإمكانك التحكم في عملية البناء والنشر وترغب في instance واقعي وحيد للحالة.

اختر Provider مركزي إذا أردت إدارة مركزية مع أدوات تتبع وتطوير قوية، وكنت تعمل ضمن بيئة يمكنها استيراد مزود واحد من المضيف.

اختر Event Bus إذا كانت التطبيقات تُنشر بشكل مستقل تمامًا أو تعمل عبر أصول/نطاقات مختلفة، أو إذا أردت أقصى درجات العزل.


كيف تحافظ على العزل والأداء — قواعد عملية

1. قسم الـ state إلى محلي ومشترك: اجعل الـ global يحتفظ فقط بما يجب أن يُشارك فعلاً (مثل جلسة المستخدم، سلة عامة، تفضيلات). كل شيء آخر يبقى محلياً داخل التطبيق الفرعي.


2. اشتراك انتقائي: اختر أجزاء الحالة بدقة عند الاشتراك بها لتقليل إعادة الرندر في الواجهات. لا تجلب الـ state بالكامل بلا حاجة.


3. Memoization ومقارنات سطحية: استخدم آليات تقلّل من إعادة الحساب وإعادة العرض غير الضرورية.


4. تخفيض حجم الحزم المشتركة: شارك المكتبات المشتركة كاعتماد مشترك لتجنّب تحميلها عدة مرات، وقلل من الاعتماديات غير اللازمة داخل كل remote.


5. التحميل الكسول (lazy loading): لا تَحمِل كل التطبيقات أو الحالة المشتركة دفعة واحدة — حمّل ما تحتاجه عند الطلب.


6. منع حلقات التحديث: عند استخدام قنوات رسائل أو تزامن ثنائي الاتجاه، ضَع آليات لمنع تحديثات تخلق حلقات لا نهائية (مثلاً: تضمين معرف المصدر، أو وضع قواعد تحديث).


7. التحكم في التحديثات السريعة: إذا كانت التغييرات سريعة جداً، دلّج أو جمّع التحديثات قبل إرسالها عبر الباص/القناة لتقليل الرسائل.


8. استخدام Web Worker للعمليات الثقيلة: إذا كان هناك معالجة بيانات مكثفة، نفّذها في خيط منفصل وأرسل النتائج للـ store، لتجنب حظر واجهة المستخدم.


9. مراقبة وقياس الأداء: سجّل زمن الاستجابة، حجم الرسائل، ومعدلات إعادة العرض في بيئة تحاكي الإنتاج لتحديد الاختناقات.


10. عقود واجهة واضحة وأنواع ثابتة: صمّم واجهات تواصل صغيرة ومحددة بين المكونات والـ store (مثل واجهات استدعاء/اشتراك بسيطة) واستخدم مواصفات/قصص تغيّر واضحة لتجنّب كسر التوافق.



إدارة الإصدارات والتوافق الخلفي

اجعل واجهة المشاركة (API) صغيرة ومحددة وواضحة؛ تجنّب تعريض كل تفاصيل الحالة الداخلية.

اتبع سياسة ترقيم إصدارات صريحة (Semantic Versioning) وتخطيط لمرحلة انتقالية عند تغيير عقود الواجهة (مثل دعم وجود واجهتين مؤقتاً).

وفّر طبقات تحويل (adapters) عند الحاجة لتقليل أثر التغييرات على التطبيقات الفرعية القديمة.


نصائح عملية إضافية

لا تشارك كل شيء "لأنّه سهل" — مشاركة أقل تعني تعقيد أقل ومخاطر أقل.

صمم تطبيقات قابلة للعمل في وضع degraded mode — أي أن كل remote يجب أن يعمل بشكل محدود إذا فقد الاتصال بالمصدر المركزي للحالة.

ضع قواعد أمنية لرسائل القنوات (التحقق من الأصل، توقيع الرسائل في حالات cross-origin).

استخدم اختبارات متكاملة (integration tests) لمحاكاة سيناريوهات تزامن الحالة ومتاعب التعارض.


خلاصة سريعة (ملخّص القرار)

إذا تريد نسخة وحيدة وحقيقية من الـ state وتملك سيطرة على البنية: اختر مشاركة مركزية عبر حزمة مشتركة أو Provider من المضيف.

إذا تحتاج عزلة انتقائية ونشر مستقل تمامًا: استخدم Event Bus مع آليات حل تعارض قوية.

واعمل دائماً على تقسيم الـ state، اشتراكات انتقائية، lazy loading، ومراقبة الأداء. عرض المزيد

محمد علي

مبرمج ويب منذ شهر

بلاغ

رد ممتاز ومتكامل، يعطيك العافية على الشرح الوافي والمفيد جدًا 🌹

1 0