لقد كان Vue 3 خطأً لا يجب أن نكرره

لقد مرت أكثر من 4 سنوات منذ التقديم الأولي لـ Vue 3. أدت العديد من المناقشات حول العديد من طلبات RFC والكثير من التأثير من أطر العمل الحديثة الأخرى بما في ذلك React وSvelte إلى تشكيل Vue ليصبح على الأرجح أقوى إطار عمل وأكثره شمولاً على الإطلاق، قادر عل

لقد مرت أكثر من 4 سنوات منذ التقديم الأولي لـ Vue 3. أدت العديد من المناقشات حول العديد من طلبات RFC والكثير من التأثير من أطر العمل الحديثة الأخرى بما في ذلك React وSvelte إلى تشكيل Vue ليصبح على الأرجح أقوى إطار عمل وأكثره شمولاً على الإطلاق، قادر على من دعم التطبيقات تدريجيا من أي نطاق والهندسة المعمارية.

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

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

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

من ناحية أخرى، أدى الخلل المعماري المتمثل في استخدام الميراث على التركيب عند تجريد المنطق المشترك إلى مزيج إلى خلق الكثير من مشكلات قابلية التوسع وكان يخالف الكثير من مبادئ إعلان المكونات النظيفة. تم تقديم Composition API كحل.

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

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

بالإضافة إلى ذلك، تم إضافة الكثير من الميزات الجديدة:

واجهة برمجة التطبيقات للتكوين
تركيب SFC لتركيب واجهة برمجة التطبيقات (SFC) (<إعداد البرنامج النصي>)
النقل الفوري
فتات
تنبعث خيار المكون
createRenderer API من @vue/runtime-core لإنشاء عارضين مخصصين
متغيرات CSS التي تعتمد على حالة SFC (v-bind في <style>)
يمكن الآن لـ SFC <stylescoped> أن يتضمن قواعد عامة أو قواعد تستهدف المحتوى المحدد فقط
تشويق
تعمل الميزات الجديدة على تحسين تجربة المطور بشكل عام ويتم الترحيب بها دائمًا. الحجة هي أن معظمها بما في ذلك واجهة برمجة تطبيقات التركيب والنقل الآني والتشويق وما إلى ذلك تعمل بالفعل مع Vue 2 لذا لا يمكن اعتبارها تحسينات لإطار العمل.

المشكلة الحقيقية
كسر التغييرات. وهنالك الكثير منهم. بعضها واضح ومباشر مثل انخفاض قيمة Events API. هذا يعني أنه لم يعد من الممكن استخدام مثيل Vue كناقل أحداث، ولكن هناك حلول التوصيل والتشغيل مثل القفاز أو الباعث الصغير الذي يمكن استخدامه كبدائل مباشرة. لا يزال هذا يتطلب العمل ولكن يمكن القيام به في الوقت المناسب دون الكثير من المخاطر.

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

تعقيد ترحيل Vue
يرتبط كل إدخال بوثائق الهجرة
miro.com

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

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

النظام البيئي
الإطار قوي مثل نظامه البيئي. أدت القرارات المثيرة للجدل وانعدام المساءلة أثناء إيقاف الميزات إلى رحيل العديد من المساهمين وأدى إلى التخلي عن العديد من المكتبات. لكن إلقاء اللوم على المصادر المفتوحة lإن مكتبة التأخير عندما لا تمنحهم طريقة مجدية لدعم كلا الإصدارين تظهر نقصًا في التعاطف وعدم فهم الصورة الأكبر.

القوة الحقيقية لإطار العمل تأتي من المجتمع والنظام البيئي المحيط به.

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

يشبه الانتقال إلى Vue 3 إلى حد كبير الانتقال من AngularJS إلى Angular (الإصدار 1⇒ 2)*. أدى الكثير من التأخير والتغييرات الطارئة إلى الإحباط وفي النهاية فقدت Angular جاذبيتها تجاه React وVue.

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

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

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