تصديرات ESM: مسماة أم افتراضية؟

أن تسمي أم لا تسمي؟

هل يجب استخدام التصدير المُسمى (`named`) أم التصدير الافتراضي (`default`) في JavaScript؟

لا يوجد نقص في المقالات ذات الآراء القوية حول هذا الموضوع.

الأغلبية تحكم على export default بأنه “سيء”. بينما يرى آخرون أن default يجب أن يفوز (مثل دليل أسلوب AirBnb).

غالبًا ما يلومون أشياء مؤقتة تمامًا: أخطاء الاستيراد التلقائي في بيئة التطوير، قدرات التجميع (tree-shaking) لأداة حزم معينة، أو مجرد احتمالية الأخطاء المطبعية عند تسمية الاستيراد.

هل فاتنا الهدف الأساسي من export في المقام الأول؟

الكود هو تواصل. ✨

نحن نرسل إشارة إلى المستوردين كيفية استخدام الشيء.

إذن، ماذا نقول؟

بشكل عام، هناك طريقتان لتصدير الأشياء في JavaScript الحديثة:

export default يعلن بجرأة “هذا هو الشيء الأكثر أهمية.” وأيضًا، “أي تصديرات مُسماة تلعب دورًا داعمًا فقط.”
named export يقول إنه “بالتأكيد شيء ما!” كما يثير بعض الأسئلة: “هل لديك أي رفاق آخرين هناك؟” ويتبعه: “هل هم مدعوون أم مطلوبون؟”

بالتأكيد يمكنك الجمع بينهما، أو استخدام أساليب مختلفة لأجزاء مختلفة من قاعدة الكود الخاصة بك. شاهد المزيد من الأمثلة في نهاية المقال.

حجج ضعيفة، يا رجل

دعنا نعالج بعض “المشكلات المؤقتة” الشائعة التي يواجهها الناس.

الحجة رقم 1: التصديرات المُسماة تضمن اتساق الاسم. المصدر
- لا، لا تفعل. ربما تبحث عن قاعدة lint؟
- (أكره أن أفسد عليك الأمر، لكن انتظر حتى تتعلم ما يمكن للمتغيرات فعله!)

// يمكنك استخدام اسم مستعار مع كليهما!
import { Knife as Handle } from "./knife.js"; // 🔪
import { default as Handle } from "./knife.js"; // 🔪
import Handle from "./knife.js"; // 🔪

الحجة رقم 2: استخدم import * as soManyKnives from './kinves.js' لدمج التصديرات المُسماة. (لم يتم الربط، المؤلف تراجع.)
- ميزة لطيفة. ليست النقطة.
- الآن أخبرني، كيف أمسك بجهازك مرة أخرى؟ لا نية للمؤلف.
الحجة رقم 3: التصديرات المُسماة لها دعم أفضل لاستيراد IDE أو إعادة التسمية. المصدر
غير صحيح (بعد الآن). قم بتكوين/تحديث أدواتك.
- الدعم موجود منذ أكثر من 3 سنوات في VS Code و IntelliJ، إلخ.
- ومع ذلك، هناك بعض “أفضل الممارسات” لاستخدامها مع default exports للحصول على أفضل تجربة IDE وإعادة هيكلة.
- ✅ export default function UserService() {} - دائماً فضّل الدوال المُسماة.
- ❌ export default function() { } - الدوال المجهولة ليست مرتبطة ضمنياً باسم ملفها. إذا لم تسمِّ الشيء، فمن الصعب أن تطلب من الكمبيوتر تغييره.
- ملاحظة: لأسباب تاريخية، لا يمكنك الجمع بين export default وتعبير const.
```
export default const Knife = () => {...blade, ...handle}
// ^ ❌ غير مدعوم ❌ ^
// لا يمكن تصدير const كافتراضي ....
// ==========================

// ومع ذلك، بمجرد التصريح، يمكنك تصدير متغير const كافتراضي.
const Knife = () => {...blade, ...handle}
export default Knife;
// ^ ✅ صالح

// للاكتمال:
export default class anyoneStillUseThese {}
// ^ ✅ صالح أيضاً لتصدير كلاس كافتراضي
```

ملخص

في الواقع هناك العديد من التركيبات لطرق تصدير الأشياء، كل منها يروي قصة مختلفة:

افتراضي (تصديرات)	مُسمى (تصديرات)	دوال خاصة	النمط	المعنى
✅	❌	❌	تصدير افتراضي واحد.	”تقديم دالة واحدة ذات غرض واحد!”
❌	✅	❌	تصدير مُسمى واحد.	”من فضلك لا تعيد تسميتي.”
✅	✅	✅	تصدير افتراضي + دوال ‘خاصة’ متعددة غير مُصدرة	”إليك بعض المنطق المرتبط. أيضاً، توقع سلوكاً شبيهًا بالكلاس.”
❌	❌	✅	تصديرات مُسماة متعددة، اسم ملف عام.	”حقيبة مختلطة من أشياء مرتبطة بشكل فضفاض، بدون تسلسل هرمي.”
✅	✅	❌	تصدير مُسمى واحد يُصدر أيضاً كافتراضي.	”لا يمكنك أن تخطئ في استيرادي.”

شيء للتفكير فيه: ماذا نقول عندما يتطابق اسم الملف أو لا يتطابق مع أحد تصديراته؟ (على سبيل المثال، ملف utils.js به دوال كثيرة.)

الخاتمة

إذا كان الكود هو تواصل، فمن فضلك export وكأنك تعني ذلك بكل جدية. 💞