ModuleRef والتحميل الكسول والحل الديناميكي
ModuleRef والتحميل الكسول والحل الديناميكي
ينبغي حقن معظم الاعتماديات عبر الباني، لكن التطبيقات المتقدمة تحتاج أحياناً إلى بحث ديناميكي عن المزوّدات: إضافات، تكاملات اختيارية، خدمات خاصة بالمستأجر، أو وحدة لا تُحمّل إلا عند طلب ميزة. تغطي ModuleRef و LazyModuleLoader هذه الحالات.
الفكرة الأساسية
تدور هذه الميزة حول التحكم في كيفية تنظيم التطبيق وسلوكه وقت التشغيل. النقاط التالية هي ما يجب أن يعرفه المطور قبل استخدامها في مشروع حقيقي:
- تجلب ModuleRef.get() مزوداً موجوداً مسبقاً بالرمز داخل سياق الوحدة الحالية.
- يسمح تمرير { strict: false } بحل مزود من السياق العام للتطبيق، لكن الإفراط فيه يخفي مشاكل حدود الوحدات.
- تنشئ moduleRef.resolve() أو تجلب مزودات ذات نطاق باستخدام ContextId، وهذا مهم للاعتماديات بنطاق الطلب.
- يحمّل LazyModuleLoader وحدة كاملة عند الحاجة بدلاً من تحميلها وقت إقلاع التطبيق.
- الحل الديناميكي قوي لكنه مخصص غالباً لكود الإطار والإضافات والتكاملات لا لخدمات العمل العادية.
مثال عملي
يوضح المثال التالي الشكل العملي للفكرة داخل مشروع NestJS. ليست الغاية حفظ الكود، بل فهم مكانه في المعمارية:
قائمة تطبيق إنتاجية
- فضّل حقن الباني للخدمات العادية.
- استخدم LazyModuleLoader للوحدات الثقيلة قليلة الاستخدام.
- تجنب { strict: false } إلا عند الحاجة المقصودة للبحث عبر الوحدات.
- استخدم ContextIdFactory عند حل مزودات بنطاق الطلب يدوياً.
الخلاصة
يغطي هذا الدرس جزءاً متقدماً من NestJS يجب فهمه عند بناء تطبيقات مؤسسية. ركّز على الحدود الواضحة، والسلوك القابل للاختبار، واختيار الأداة المناسبة للسياق بدلاً من استخدام كل ميزة في كل مكان.