Skip to content

الأسئلة الشائعة حول الواجهة التركيبية

ملاحظة

نفترض في هذا الدليل أن يكون لديك خبرة سابقة مع Vue - وبالتحديد، خبرة مع Vue 2 أثناء استخدام واجهة الخيارات بشكل أساسي.

ماهي الواجهة التركيبية؟

الواجهة التركيبية هي مجموعة من الواجهات البرمجية التي تسمح لنا بكتابة مكونات Vue باستخدام دوال مستوردة بدلاً من التصريح بالخيارات. وهي مصطلح يغطي الواجهات البرمجية التالية:

  • الواجهة البرمجية التفاعلية، على سبيل المثال ()ref و ()reactive، والتي تسمح لنا مباشرة بإنشاء حالة تفاعلية، حالة محسوبة، ودوال مراقبة.

  • خطافات دورة الحياة، على سبيل المثال ()onMounted و ()onUnmounted، والتي تسمح لنا بربط الدوال بشكل برمجي مع دورة حياة المكون.

  • حقن الاعتمادية، أي ()provide و ()inject، والتي تسمح لنا بالاستفادة من نظام حقن الاعتمادية في Vue أثناء استخدام الواجهات البرمجية التفاعلية.

لواجهة التركيبية هي ميزة مدمجة في Vue 3 و Vue 2.7. لإصدارات Vue 2 الأقدم، استخدم الملحق vue/composition-api@. في Vue 3، يستخدم أيضًا بشكل أساسي مع صيغة <script setup> في المكونات أحادية الملف. هنا مثال أساسي لمكون يستخدم الواجهة التركيبية:

vue
<script setup>
import { ref, onMounted } from 'vue'

// حالة تفاعلية
const count = ref(0)

// دوال تغيير الحالة وتحفيز التحديثات
function increment() {
  count.value++
}

// خطافات دورة الحياة
onMounted(() => {
  console.log(`العداد الأولي هو ${count.value}.`)
})
</script>

<template>
  <button @click="increment">قيمة العداد: {{ count }}</button>
</template>

على الرغم من أن الواجهة التركيبية تعتمد على أسلوب وظيفي يعتمد على تركيب الدوال، إلا أن الواجهة التركيبية ليست برمجة وظيفية. تعتمد الواجهة التركيبية على نموذج التفاعلية الدقيقة والقابلة للتغيير في Vue، بينما ترتكز البرمجة الوظيفية على عدم التغيير.

إذا كنت مهتمًا بتعلم كيفية استخدام Vue مع الواجهة التركيبية، يمكنك تعيين تفضيل الواجهة التركيبية في كامل الموقع باستخدام مفتاح التبديل في أعلى الشريط الجانبي الأيسر، ثم الانتقال إلى الدليل من البداية.

لماذا الواجهة التركيبية

إعادة استخدام الشيفرة البرمجية بشكل أفضل

الميزة الأساسية للواجهة التركيبية هي أنها تمكن إعادة استخدام الشيفرة البرمجية النظيفة والفعالة في شكل دوال تركيبية. وهي تحل جميع عيوب المخلوطات، والتي تعتبر آلية إعادة استخدام الشيفرة البرمجية الأساسية في واجهة الخيارات.

قدرة إعادة استخدام الشيفرة البرمجية في الواجهة التركيبية أدت إلى ظهور مشاريع مجتمعية مثيرة مثل VueUse، وهي مجموعة من الأدوات التركيبية المتنامية باستمرار. كما أنها تعمل كآلية نظيفة لدمج الخدمات أو المكتبات الخارجية ذات الحالة في نظام التفاعلية في Vue بسهولة، على سبيل المثال البيانات غير القابلة للتغيير، الآلات الحالية، و RxJS.

تنظيم أكثر مرونة للشيفرات

يحب العديد من المستخدمين أن نكتب شيفرة منظمة بشكل افتراضي مع واجهة الخيارات: كل شيء له مكانه بناءً على الخيار الذي ينبني عليه. ومع ذلك، تفرض واجهة الخيارات قيودًا جديو عندما تتجاوز الشيفرة البرمجية لمكون واحد حدًا معينًا من التعقيد. وهذا القيد بارز بشكل خاص في المكونات التي تحتاج إلى التعامل مع العديد من الوظائف المنطقية، والتي شهدناها بشكل مباشر في العديد من تطبيقات Vue 2 التي تشتغل في طور الإنتاج.

خذ مكون مستكشف المجلدات من الواجهة الرسومية الخاصة بـ Vue CLI كمثال: هذا المكون مسؤول عن الوظائف المنطقية التالية:

  • تتبع حالة المجلد الحالي وعرض محتوياته
  • التعامل مع تصفح المجلدات (فتح، إغلاق، تحديث...)
  • التعامل مع إنشاء مجلد جديد
  • التبديل إلى عرض المجلدات المفضلة فقط
  • التبديل إلى عرض المجلدات المخفية
  • التعامل مع تغييرات مجلد العمل الحالي

النسخة الأصلية من المكون كتبت بواجهة الخيارات. إذا أعطينا كل سطر من الشيفرة لونًا بناءً على الوظيفة المنطقية التي يتعامل معها، هذا هو شكله:

folder component before

لاحظ كيف تُجبر الشيفرة التي تتعامل مع نفس الوظيفة المنطقية على الانقسام تحت خيارات مختلفة، وتقع في أجزاء مختلفة من الملف. في مكون يتكون من عدة مئات من الأسطر، يتطلب فهم وتصفح وظيفة منطقية واحدة التمرير بين الأعلى والأسفل باستمرار، مما يجعل المهمة أكثر صعوبة مما ينبغي. بالإضافة إلى ذلك، إذا كنا ننوي استخراج وظيفة منطقية إلى أداة قابلة لإعادة الاستخدام، فإنها تتطلب الكثير من العمل لإيجاد واستخراج الأجزاء المناسبة من الشيفرة من أجزاء مختلفة من الملف.

هنا نفس المكون قبل وبعد إعادة هيكلته يالواجهة التركيبية:

شكل مكون المتصفح بعد الهيكلة

لاحظ كيف يمكن تجميع الشيفرة المتعلقة بنفس الوظيفة المنطقية معًا الآن: لم نعد بحاجة إلى القفز بين كتل الخيارات المختلفة أثناء العمل على وظيفة منطقية محددة. علاوة على ذلك، يمكننا الآن نقل مجموعة من الشيفرة إلى ملف خارجي بجهد أدنى، لأننا لم نعد بحاجة إلى ترتيب الشيفرة من أجل استخراجها. هذا الاحتكاك المنخفض لإعادة الترتيب أمر أساسي لقابلية الصيانة على المدى الطويل في مجموعات الشيفرة الكبيرة.

استنباط أفضل للأنواع

في السنوات الأخيرة، تبنى الكثير من مطوري الواجهة الأمامية TypeScript لأنه يساعدنا على كتابة شيفرة أكثر صلابة، وإجراء التغييرات بثقة أكبر، ويوفر تجربة تطوير رائعة مع دعم المحررات. ومع ذلك، واجهة الخيارات التي صممت في الأصل عام 2013، دون الأخذ في الاعتبار استنباط الأنواع. كان علينا تنفيذ بعض التمارين المعقدة بشكل سخيف لجعل استنباط الأنواع يعمل مع واجهة الخيارات. حتى مع كل هذا الجهد، يمكن أن يتعطل استنباط الأنواع لواجهة الخيارات في المخاليط وحقن الإعتمادية.

هذا ما أدى بالعديد من المطورين الذين يريدون استخدام Vue مع TS يميلون نحو واجهة البرمجة الكائنية التي تعمل بواسطة vue-class-component. ومع ذلك، تعتمد واجهة البرمجة الكائنية بشكل كبير على مزيد من ES decorators، وهي ميزة لغة كانت مقترحة مرحلة 2 فقط عندما كان تم البدء في تطوير Vue 3 في عام 2019. شعرنا أنه من المخاطرة جدًا أن نقوم بتأسيس واجهة برمجة رسمية على مقترح غير مستقر. منذ ذلك الحين، مر مقترح decorators بتغييرات كاملة أخرى، ووصل أخيرًا إلى المرحلة 3 في عام 2022. بالإضافة إلى ذلك، تعاني واجهة البرمجة الكائنية من قيود إعادة استخدام الشيفرة وتنظيمها مماثلة لواجهة الخيارات.

بالمقارنة، تستخدم واجهة البرمجة التركيبية متغيرات ودوال عادية بشكل أساسي، والتي تكون ودية للأنواع بشكل طبيعي. يمكن للشيفرة المكتوبة في واجهة البرمجة التركيبية الاستمتاع بالاستنباط الكامل للأنواع مع القليل من الحاجة إلى تلميحات الأنواع اليدوية. في معظم الأوقات، ستبدو الشيفرة المكتوبة في واجهة البرمجة التركيبية متطابقة تمامًا في TypeScript و JavaScript العادي. وهذا أيضًا يجعل من الممكن على مستخدمي JavaScript العادي الاستفادة من استنباط الأنواع الجزئي.

حزمة إنتاج أصغر وتكاليف أقل

الشيفرة المكتوبة بواجهة البرمجة التركيبية و صسغى <script setup> أكثر كفاءة ودية للتقليل من حجمها مقارنة بما يعادلها في واجهة الخيارات. هذا لأن القالب في عنصر <script setup> يترجم كدالة مضمنة في نفس نطاق شيفرة <script setup>. على عكس الوصول إلى الخاصية من this، يمكن لشيفرة القالب المترجمة الوصول مباشرة إلى المتغيرات المعلنة داخل <script setup>، دون وجود نسخة وسيط بينهما. وهذا أيضًا يؤدي إلى تقليل حجم الشيفرة بشكل أفضل لأن جميع أسماء المتغيرات يمكن تقليلها بأمان.

العلاقة مع واجهة الخيارات

التجاذبات

بعض المستخدمين الذين ينتقلون من واجهة الخيارات وجدوا أن شيفرة الواجهة التركيبية أقل تنظيمًا، واستنتجوا أن الواجهة التركيبية "أسوأ" من حيث تنظيم الشيفرة. نوصي المستخدمين الذين لديهم مثل هذه الآراء بالنظر إلى هذه المشكلة من منظور مختلف.

صحيح أن الواجهة التركيبية لم تعد توفر "حواجز الحماية" التي توجهك لوضع شيفرتك في الحاويات المناسبة. وبالمقابل، يمكنك كتابة شيفرة المكون كما لو كنت تكتب JavaScript عادي. وهذا يعني يمكنك ويجب عليك تطبيق أي ممارسات أفضل لتنظيم الشيفرة على شيفرة الواجهة التركيبية كما تفعل عند كتابة JavaScript عادي. إذا كنت تستطيع كتابة JavaScript منظم، يجب أن تكون قادرًا أيضًا على كتابة شيفرة منظمة بالواجهة التركيبية .

واجهة الخيارات تسمح لك بـ "التفكير أقل" عند كتابة شيفرة المكون، وهذا هو السبب في أن العديد من المستخدمين يحبونها. ومع ذلك، في تقليل العبء الذهني، فإنه يقفلك في نمط تنظيم الشيفرة المحدد دون وجود مخرج، مما يجعل من الصعب إعادة ترتيب الشيفرة أو تحسين جودة الشيفرة في مشاريع أكبر حجمًا. من هذا المنطلق، توفر الواجهة التركيبية قابلية توسع أفضل على المدى الطويل.

هل تغطي الواجهة التركيبية جميع حالات الاستخدام؟

هناك خيارات قليلة فقط قد تكون ما زالت مطلوبة: props، emits، name، و inheritAttrs. إذا كنت تستخدم <script setup>، فإن inheritAttrs هو الخيار الوحيد الذي قد يتطلب كتلة <script> عادية منفصلة.

TIP

منذ 3.3 يمكنك استخدام defineOptions مباشرة في <script setup> لتعيين اسم المكون أو خاصية inheritAttrs

إذا كنت تنوي استخدام الواجهة التركيبية حصريًا (جنبًا إلى جنب مع الخيارات المذكورة أعلاه)، يمكنك تقليص بضعة كيلوبايتات من حزمة الإنتاج الخاصة بك عن طريق علامة تصريف في وقت التشغيل التي تحذف الشيفرة المتعلقة بواجهة الخيارات من Vue. لاحظ أن هذا يؤثر أيضًا على مكونات Vue في الاعتماديات الخاصة بك.

هل يمكنني استخدام الواجهتين مع بعض؟

نعم. يمكنك استخدام واجهة التركيبية عبر الخيار setup() في مكون واجهة الخيارات.

ومع ذلك، نوصي فقط بالقيام بذلك إذا كان لديك قاعدة شيفرات موجودة بالفعل تحتاج إلى التكامل مع ميزات / مكتبات خارجية جديدة مكتوبة بالواجهة التركيبية.

هل ستُلغى واجهة الخيارات؟

لا، ليس لدينا أي خطة للقيام بذلك. واجهة الخيارات هي جزء لا يتجزأ من Vue والسبب في ذلك أن العديد من المطورين يحبونها. ندرك أيضًا أن العديد من فوائد الواجهة التركيبية تظهر فقط في المشاريع ذات المستوى الأكبر، وواجهة الخيارات لا تزال خيارًا متينًا للعديد من السيناريوهات ذات المستوى المنخفض إلى المتوسط.

العلاقة مع واجهة الكائنية

نحن لم نعد نوصي باستخدام الواجهة الكائنية مع Vue 3، نظرًا لأن الواجهة التركيبية توفر تكاملًا رائعًا مع TypeScript مع فوائد إعادة الاستخدام الإضافية للشيفرة وتنظيمها.

المقارنة مع خطافات React

الواجهة التركيبية توفر نفس مستوى قدرات تركيب الشيفرة مثل خطافات React، ولكن مع بعض الاختلافات المهمة.

خطافات React تستدعى مرارًا وتكرارًا في كل مرة يُحدث فيها المكون. هذا يخلق عددًا من الحالات التي يمكن أن تربك حتى المطورين المتمرسين في React. كما أنه يؤدي إلى مشاكل تحسين الأداء التي يمكن أن تؤثر بشكل كبير على تجربة التطوير. وإليك بعض الأمثلة:

  • الخطافات حساسة لترتيب الاستدعاء ولا يمكن أن تكون شرطية.

  • يمكن أن تُلتقط المتغيرات المعلنة في مكون React بواسطة مغلف الخطاف وتصبح "غير صالحة" إذا فشل المطور في تمرير مصفوفة الاعتماديات الصحيحة. وهذا يؤدي إلى أن يعتمد مطورو React على قواعد ESLint لضمان تمرير الاعتماديات الصحيحة. ومع ذلك، فإن القاعدة غالبًا ليست ذكية بما فيه الكفاية وتعوض عن الصحة، مما يؤدي إلى إلغاء غير ضروري وصداع عند مواجهة حالات قصوى.

  • تتطلب العمليات الحسابية المكلفة استخدام useMemo، والذي يتطلب مرة أخرى تمرير مصفوفة الاعتماديات الصحيحة يدويًا.

  • يتسبب معالجو الأحداث الممررة إلى المكونات الأبناء في تحديثات غير ضرورية للأبناء افتراضيًا، ويتطلب استخدام useCallback بشكل صريح كتحسين. وهذا مطلوب تقريبًا دائمًا، ويتطلب مرة أخرى مصفوفة الاعتماديات الصحيحة. وإهمال هذا يؤدي إلى إعادة تصيير التطبيقات افتراضيًا ويمكن أن يتسبب في مشاكل في الأداء دون أن ندرك ذلك.

  • مشكلة المغلف الغير صالح، مجتمعة مع الميزات المتزامنة، تجعل من الصعب التفكير في متى تشغل قطعة من شيفرة الخطافات، وتجعل العمل مع الحالة القابلة للتغيير التي يجب أن تستمر عبر التصييرات (عبر useRef) مرهقة.

بالمقارنة، الواجهة التركيبية في Vue:

  • تستدعي شيفرة ()setup أو <script setup> مرة واحدة فقط. وهذا يجعل الشيفرة تتوافق بشكل أفضل مع الحدس المتعلق باستخدام JavaScript النمطي لأنه لا توجد مغلفات غير صالحة للقلق بشأنها. كما أن استدعاء الواجهة التركيبية ليس حساسًا لترتيب الاستدعاء ويمكن أن يكون شرطيًا.

  • يجمع نظام التفاعلية في وقت التشغيل في Vue تلقائيًا الاعتماديات التفاعلية المستخدمة في الخاصيات المحسوبة والمراقبة، لذا لا حاجة لإعلان الاعتماديات يدويًا.

  • لا حاجة لتخزين مؤقت لدوال رد النداء يدويًا لتجنب تحديثات الأبناء غير الضرورية. بشكل عام، يضمن نظام التفاعلية الدقيق في Vue أن تُحدث المكونات الأبناء فقط عندما يكون ذلك ضروريًا. وتحسينات تحديث الأبناء يدويًا نادرًا ما تكون مصدر قلق لمطوري Vue.

نقرّ بالاعتراف بالإبداع في خطافات React، وهي مصدر إلهام رئيسي للواجهة التركيبية. ومع ذلك، فإن المشاكل المذكورة أعلاه موجودة في تصميمها ولوحظ أن نموذج التفاعلية في Vue يوفر طريقة للتغلب عليها.

الأسئلة الشائعة حول الواجهة التركيبية has loaded