لماذا اخترنا Vue.js (وليس رد فعل)

بدأ فريق Qwintry مؤخرًا في الترحيل النشط إلى Vue.js في جميع مشروعاتنا القديمة والجديدة:

  • على النظام القديم القائم على دروبال (qwintry.com)
  • في موضوع qwintry.com الجديد الذي تمت إعادة كتابته بالكامل (الخلفية على Yii2 / Node.js)
  • في أنظمة B2B لدينا (مدعوم من Yii2) (Logistics.qwintry.com)
  • في جميع مشاريعنا الداخلية والعامة الصغيرة (باستخدام PHP و Node.js في الواجهة الخلفية بشكل أساسي)

لماذا اختار المبرمجون لدينا Vue.js ، يقول رئيس التطوير في Qwintry LLC . انطون سيداشين ➔

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


الحزمة الخاصة بنا على باب العميل - من مراجعات العملاء

يحتوي Qwintry على قاعدة رموز كبيرة نوعًا ما ، تتكون أساسًا من PHP و JS (+ Swift و Java لتطبيقات الهاتف المحمول).

قررنا استخدام Vue.js بعد أن أنشأنا تطبيق اختبار بوظائف متطابقة - الآلة الحاسبة لدينا - على React و Vue.js و Angular2.
 

رد فعل js


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

لقد شاهدنا العديد من SPA والأدوات الديناميكية على React ، واختبرنا React Native (لنظام iOS) و Redux. أعتقد أن React كانت خطوة كبيرة لعالم JS من حيث وعي الدولة ، وأظهرت للعديد من الناس ما هي البرمجة الوظيفية الحقيقية بطريقة جيدة وعملية. أعتقد أيضًا أن React Native رائع - فهو يغير حرفيا المشهد الكامل لتطوير المحمول.

رد فعل سلبي بالنسبة لي:

غالبًا ما تهيمن النظافة والحصانة والأيديولوجية على النهج البراغماتي.


لا تفهموني خطأ. أقدر نقاء وبساطة نهج تقديم () - لا شك أن هذه فكرة عظيمة تعمل في التنمية الحقيقية. أنا أتحدث عن أشياء أخرى.

أعتقد أن هذا المستوى من الدقة والنظافة يمكن أن يكون مفيدًا عندما يكون لديك 1000 مطور في شركتك - في نفس الوقت الذي تقرر فيه تطوير بناء الجملة الخاص بك لترجمة جميع تعليمات PHP البرمجية إلى أنواع ثابتة . أو عندما تكون مطورًا في Haskell قرر استيعاب JS. لكن معظم الشركات لديها عدد أقل بكثير من المطورين وميزانيات وأهداف أصغر تختلف عن أهداف Facebook. سوف أطيل في هذا بالتفصيل أكثر قليلاً.

تمتص JSX


انتظر ثانية! اعرف! هذا هو "فقط جافا سكريبت نقي مع بناء جملة خاص". رفاقنا الذين يرسمون تصميمًا في رسم وفوتوشوب ثم يحولونه إلى HTML ، الذين لديهم مواعيد نهائية صارمة والذين يشكلون هذا النموذج الآن ، يلفونه في عدد من divs - في الوقت الحالي - الطبل نظيف و "بسيط" ES6. تطبيق بعض التصميم على مكونات React ليس ينبوعًا ، لأن JSX تفتقر إلى إمكانية القراءة. إن عدم القدرة على وضع IF القديم الجيد في جزء من شفرة HTML أمر سيء ، ويرجى عدم الوثوق بمعجبين React الذين يقولون "إذا كان () هو القرن الماضي ، والآن يستخدم جميع المبرمجين العاديين عوامل تشغيل ثلاثية". دعني أؤكد لك: JSX لا يزال مزيجًا من HTML و JS في اللحظة التي تقرأها وتحررها ، حتى لو تم تجميعها لاحقًا في JS خالص.

<ul>
       {items.map(item =>
         <li key={item.id}>{item.name}</li>
       )}
</ul>

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

stackoverflow.com/a/38231866/1132016

تجبرك JSX أيضًا على تقسيم المكونات في 15 سطرًا إلى HTML إلى 3 مكونات ، 5 أسطر ، HTML في كل منها. لا تعتقد أن هذا النهج يجعلك مطورًا أفضل.

إليك الشيء:

عندما تكتب مكونًا معقدًا نسبيًا - والذي من المحتمل أنك لن تنشره على الراب العام GitHub غدًا لتوضيح ذلك على HackerNews - فإن هذا الأسلوب من كسر المكونات إلى مكونات غبية للغاية بسبب قيود JSX دائمًا ما يسحبك من الدفق ، في التي تحل مشكلة عمل حقيقية. لا ، أنا لا أقول أن فكرة المكونات الجزئية سيئة أو لا تعمل. يجب أن تدرك بوضوح أنك بحاجة إلى تقسيم الوظيفة إلى مكوناتها من أجل الحفاظ على التعليمات البرمجية الخاصة بك في حالة يمكن التحكم فيها. ولكن عليك أن تفعل ذلك إلا إذا كنت تعتقد أن هذا الكيان منطقي معين في التعليمات البرمجية من الأفضل أن يكون عنصرا منفصلا مع الدعائم الخاصة - و ليسلكل شرطين أو ثلاثة تم كتابتها باستخدام عامل التشغيل الثلاثي! في كل مرة تقوم فيها بإنشاء مكون جديد هنا وهناك ، يكلفك جهدًا محددًا للغاية ويعطل تدفقك .، لأنك تحتاج إلى التبديل من تفكير المهندس المعماري (عندما تتذكر بالفعل الحالة الحالية لنموذج المكون وتحتاج فقط إلى إضافة HTML هنا وهناك لكي تعمل الوظيفة) إلى تفكير المدير: تحتاج إلى إنشاء ملف منفصل للمكون ، فكر في الدعائم لهذا المكون الجديد كيف يتم تعيينهم على الدولة ، وكيف ستقوم بإعادة توجيه المكالمات ، وما إلى ذلك. ونتيجة لذلك ، يتم تقليل سرعة كتابة التعليمات البرمجية ، لأنه يجب عليك بذل جهود على الوحدات النمطية المبكرة للمكونات حيث ربما لن تحتاج إليها ، إذا كانت بنية JSX أكثر مرونة. في رأيي ، فإن النمذجة المبكرة سابقة لأوانها تشبه إلى حد كبير التحسين المبكر. بالنسبة لي وفريقنا ، تعد قراءة الرمز مهمة ، ولكن لا يزال من المهم جدًا الاستمتاع بكتابة التعليمات البرمجية. هذا ليس رائعًاعندما يتطلب شكل بسيط من الآلة الحاسبة إنشاء 6 مكونات ، لكل منها أدواتها الخاصة.

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

مرة أخرى ، أنا لا أقترح كتابة متجانسة. أقترح استخدام المكونات بدلاً من المكونات الدقيقة للبرمجة اليومية. حول التوازن والفطرة السليمة.

العمل مع النماذج و Redux سيجعلك تطبع طوال اليوم


رد فعل - يتعلق الأمر بالنظافة والتدفق في اتجاه واحد ، تذكر؟ هذا هو السبب في أن LinkedStateMixin أصبح شخصية غير مرغوب فيها.، والآن عليك كتابة 10 وظائف للحصول على إدخال من 10 حقول نموذج. لا ، يمكنك بالطبع كتابة وظيفة واحدة تتحقق من e.target ، ولكن في النهاية ستكون هناك شجرة من الظروف مع تطبيع البيانات الواردة من النموذج الذي تريد البكاء ؛ لذلك لا أحد يفعل ذلك. ستحتوي 80٪ من هذه الوظائف على سطر واحد مع this.setState () أو استدعاء لإجراء Redux. (عندها ربما ستضطر إلى إنشاء 10 ثوابت أخرى - واحدة لكل إجراء). أعتقد أن هذا النهج سيكون مقبولًا إذا كان بإمكانك إنشاء كل هذا الرمز فقط من خلال التفكير فيه ... ولكن لا أعرف أي محرر IDE يمكنه تبسيط كتابة مثل هذا الجزء المعياري. لماذا يجب أن تطبع كثيرا؟ لأن الأشخاص الكبار قرروا أن التجليد ثنائي الاتجاه خطير في تطبيقات المؤسسات الكبيرة.يمكنني أن أؤكد أن الربط ثنائي الاتجاه في بعض الأحيان ليس بهذه البساطة وغير قابل للقراءة ، ولكن معظم هذه المخاوف تتعلق بالمعاناة العامة للأشخاص من الإصدار الأول من Angular ، حيث قد لا يكون الربط ثنائي الاتجاه هو الأفضل. ومع ذلك ... ربما لم يكن هذا أكبر خطأ في الحسابات حتى في Angular. انظر إلى محرري السريع ، الذي سئمت مؤخرًا من Vue.js لمنصة Drupal الخاصة بنا (أعتذر مقدمًا عن التصميم ، وهذا هو الواجهة الخلفية لواجهة المستخدم لدينا ، والمصممين مشغولون في إنشاء واجهات لعملائنا ، لذلك هذه القطعة من الوظائف تنتظر ساعات لتصبح جميلة):ربما لم يكن أكبر خطأ في الحسابات حتى في Angular. انظر إلى محرري السريع ، الذي سئمت مؤخرًا من Vue.js لمنصة Drupal (أعتذر مقدمًا عن التصميم ، وهذا هو الواجهة الخلفية لواجهة المستخدم لدينا ، والمصممين مشغولون في إنشاء واجهات لعملائنا ، لذلك تنتظر هذه القطعة من الوظائف ساعات لتصبح جميلة):ربما لم يكن أكبر خطأ في الحسابات حتى في Angular. انظر إلى محرري السريع ، الذي سئمت مؤخرًا من Vue.js لمنصة Drupal (أعتذر مقدمًا عن التصميم ، وهذا هو الواجهة الخلفية لواجهة المستخدم لدينا ، والمصممين مشغولون في إنشاء واجهات لعملائنا ، لذلك تنتظر هذه القطعة من الوظائف ساعات لتصبح جميلة):



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

Redux هو أيضًا مطول ويتطلب الكثير من الكتابة . وعلى الإنترنت ، من السهل العثور على عبارات المطورين الذين يتهمون Mobx بتحويل React إلى Angular لمجرد استخدام Mobx لربط البيانات في اتجاهين (راجع البند رقم 1 حول "النظافة"). يبدو أن العديد من الأشخاص الأذكياء يقدرون "نظافة" التعليمات البرمجية الخاصة بهم أكثر من مهمة العمل السريعة والحسنة (والتي ، من حيث المبدأ ، أمر طبيعي إذا لم يكن لديك مواعيد نهائية).

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

الإفراط في الأدوات


رد فعل يعمل مع النطاق الأصلي على بابل. لن تقوم بعمل تطبيق React حقيقي بدون مجموعة لائقة من حزم npm ، بدءًا من مترجم ES5. تطبيق بسيط يعتمد على بناء البدء الرسمي في الحمل يتلقى حوالي 75 ميغابايت من كود JS في node_modules. هذا ليس شيئًا مهمًا ويتعلق أكثر بعالم JS ككل بدلاً من رد الفعل ، لكنه لا يزال يضيف الإحباط والإزعاج.

حكم رد الفعل الخاص بي - يسمح لك بكتابة كود رائع وقابل للقراءة ، لكن كتابته كثيرًا ليس ممتعًا. حسنًا ، لا تختفي مشكلات مصممي التخطيط الذين لا يمتلكون ، ولا يريدون امتلاك ES6 داخل HTML.

الزاوي 1: الحرية الزائدة سيئة أيضًا


Angular 1 هو إطار جيد لوقته ، يقع في الزاوية المقابلة (من React) لخريطة JS وهمية للنظافة وإمكانية قراءة التعليمات البرمجية. يتيح لك Angular البدء بسرعة ، ويسمح لك بالاستمتاع بكتابة أول سطر من التعليمات البرمجية ، ومن ثم يجعلك عمليًا تكتب كودًا لا يعمل بشكل جيد جدًا. من المحتمل أن تضيع في التوجيهات ، والمجالات ، وتدفقات البيانات ثنائية الاتجاه التي تخترق جميع طبقات التطبيق الخاص بك ستكون الوتر النهائي لأغنية البجعة من التعليمات البرمجية الخاصة بك ، والتي لن يرغب المطورون الجدد في لمسها ، لأن شيئًا ما سوف ينكسر. لماذا يحدث هذا؟ تم إنشاء Angular.js في عام 2009 ، عندما بدا عالم تطوير الواجهة الأمامية بسيطًا للغاية ولم يفكر أحد حتى في التحكم الجيد في حالة التطبيق. لا يجب إلقاء اللوم على المؤلفين - لقد صنعوا للتو منافسًا لـ Backbone ببعض الرقائق الجديدة وأرادوا طباعة أقل (وقد فعلوا كل شيء ، سؤال آخر بأي تكلفة).

الزاوي 2


فقط قم بإنشاء تطبيق hello-world وانظر إلى عدد الملفات التي تنتهي في اللفت. سأضطر إلى استخدام Typescript (وأنا لست متأكدًا بنسبة 100٪ مما أريد القيام به كل يوم - لا ، يا رفاق ، الكتابة الثابتة في JS ليست دواءً سحريًا ، ولكن مرة أخرى سأضطر للطباعة ، أفكار جيدة من Eric Eliott حول هذا الموضوع) والمترجمين للبدء. كان هذا كافيا بالنسبة لنا لتأجيل Angular2 حتى أوقات أفضل. أنا كسول ، وبالنسبة لي ، هناك الكثير من الصفيحة قبل أن تبدأ في كتابة رمز حقيقي. في رأيي ، يحاول مؤلفو Angular 2 بناء نظام مثالي لمؤسسة ستهزم React ، بدلاً من محاولة بناء إطار يحل مشاكل العمل للمستخدم العادي العادي. ربما أكون مخطئًا ، وقد يتغير رأيي - ليس لدي الكثير من الخبرة في Angular2 ، لقد قمنا للتو بإنشاء تطبيق حاسبة اختبار ، في النهاية. صفحة مقارنة رائعة على Vue.js تطلق على Angular2 نظامًا جيدًا ، والذي يحتوي على العديد من الأفكار المشتركة مع Vue.js.

Vue.js


Vue.js هو شيء كنت أنتظره منذ فترة طويلة (فيما يلي سأتحدث عن Vue.js 2 ، التي تلقت العديد من التحسينات مقارنة بالإصدار الأول من Vue ، وهذا هو الإصدار المستقر الحالي للنظام). بالنسبة لي ، من حيث الأناقة والإيجاز ، بالإضافة إلى التركيز على حلول لمشاكل العالم الواقعي ، تعد Vue.js أكبر اختراق في JS منذ اليوم الذي تعرضت فيه إلى Jquery في عام 2007. إذا نظرت إلى الرسوم البيانية لشعبية Vue.js ، ثم لاحظ أن هذا العام لم يسعدني فقط:



في Vue Github - مشروع JS Top 1 لعام 2016 (بين اللفت بكود المصدر).

من خلال الشعبية في Google Trends ، تفوق Vue.js في عام 2016 بشكل حاد على رد الفعل (بالطبع ، هذا هو متوسط ​​درجة الحرارة في مستشفى كبير جدًا ، ويعتمد بشكل كبير على الطلب المصاغ - علامة غير مباشرة جدًا على الشعبية).
يعتبر https://www.google.com/trends/explore؟q=vue.js،react.js،angular.js

Vue.js أحد الأسرع نموًا (من حيث المجتمع أو على الأقل عدد الإعجابات في github ، ومستخدمي Vue Dev Tools في Chrome) حلول JS في عام 2016 ، وأنا متأكد من أن هذه ليست مجرد مكتبة عصرية أخرى لمحبي موسيقى الجاز الذين يتحولون إلى إطار عمل JS جديد كل 3 أشهر ، أو أن عمل قسم العلاقات العامة كبير شركة.

أضاف Laravel Vue.js إلى النواة ، وهذا ادعاء خطير.

إيجابيات Vue.js


يحافظ Vue.js على توازن ممتاز بين سهولة القراءة ، وقابلية الحفاظ على الشفرة ومتعة ذلك ، هذا الرمز ، الكتابة. يقع هذا التوازن على مسافة متساوية تقريبًا بين React و Angular 1 ، وإذا نظرت إلى إرشادات vue.js ، فستلاحظ على الفور عدد الأفكار المفيدة التي استعارها من هذه الأنظمة.

من React Vue.js ، اتخذت نهج المكون ، والدعائم ، ودفق بيانات أحادي الاتجاه للتسلسل الهرمي للمكونات ، والأداء ، والقدرة على العرض على الواجهة الخلفية وأهمية إدارة الحالة المناسبة. Vue.js مأخوذ من قوالب Angular1 المتشابهة مع بنية جيدة وملزمة ثنائية الاتجاه ، ولكن فقط في المكان الذي تحتاج إليه حقًا ولن يسمح لك بتصوير ساقك على الفور (داخل مكون واحد). من السهل جدًا بدء كتابة التعليمات البرمجية تحت Vue.js - لقد رأيت هذا في فريقنا. لا يتطلب Vue.js أي مترجمين افتراضيين ، لذلك من السهل جدًا إضافة Vue.js إلى قاعدة التعليمات البرمجية القديمة وبدء نسخ تجزئة jQuery إلى رمز قابل للقراءة.

المقدار الصحيح من السحر


Vue.js بسيط للغاية للعمل سواء من حيث النهج المتمحور حول HTML ومن وجهة نظر مطوري JS: يمكنك إنشاء قوالب معقدة إلى حد ما دون فقدان التركيز على مهمة العمل ، وعادة ما يتم قراءة قالب HTML الناتج بشكل جيد حتى عندما إنه كبير بالفعل. بحلول هذا الوقت ، كقاعدة عامة ، تكون قد أحرزت تقدمًا جيدًا في حل مشكلة العمل وقد ترغب في إعادة تنظيم القوالب وتقسيمها إلى مكونات أصغر - في هذه اللحظة ترى "الصورة" الكاملة لتطبيقك أفضل بكثير مما كانت عليه في البداية. تُظهر تجربتي أن هذا يختلف اختلافًا كبيرًا عن النهج الذي يستخدمه مبرمجو رد الفعل عادة ، وهذا الاختلاف يوفر الكثير من الوقت والجهد للمبرمجين الذين يستخدمون Vue.js. في رد فعل أنت مجبر علىقم بتقسيم المكونات إلى مكونات دقيقة ووظائف دقيقة في وقت كتابة النسخة الأولية "المسودة" من التعليمات البرمجية ، وإلا سيتم دفنك حرفيا في خليط من الأقواس المتعرجة و HTML بينهما. في React ، أقضي الكثير من الوقت في تلميع الدعائم وإعادة بناء المكونات الصغيرة جدًا (والتي ، بالطبع ، لن يتم إعادة استخدامها مطلقًا) مرارًا وتكرارًا ، لأنني لا أراها بوضوح عندما أحتاج فجأة إلى تغيير منطق الشفرة في منتصف العملية.

النماذج


العمل مع نماذج HTML في Vue.js من دواعي سروري. هذا هو المكان الذي يساعد فيه الربط على الوجهين. حتى في الحالات الصعبة ، لا توجد مشكلة ، على الرغم من أن المراقبين قد يشبهون للوهلة الأولى تدفق البيانات أحادي الاتجاه في خدمتك دائمًا عند تقسيم المكونات.

التكنولوجيا


إذا كنت ترغب في التجميع ، فإن linting و PostCSS و ES6 ليست مشكلة . يبدو أن مكونات الملف الواحد أصبحت الطريقة الرئيسية لكتابة المكونات العامة في Vue.js 2. وبالمناسبة ، فإن فكرة Scoped CSS التي تعمل في مكونات الملف الواحد خارج الصندوق هي شيء يبدو لطيفًا حقًا ويمكن أن يقلل من الحاجة إلى قواعد تسمية CSS صارمة الطبقات والتقنيات مثل BEM .

إدارة الدولة


Vue.js لديها إدارة حالة بسيطة ومفيدة إلى حد ما من خلال طرق البيانات () والدعائم () - فهي تعمل بشكل جيد في التطوير الحقيقي. إذا طلبت الروح شيئًا أكثر لإدارة الدولة ، فهناك Vuex (الذي ، في رأيي ، مشابه لـ Mobx in React - الحالة قابلة للتغيير هناك). أعتقد أن نسبة جيدة من تطبيقات Vue.js لن تحتاج إلى إدارة الدولة من خلال Vuex ، ولكن من الجميل أن يكون لديك بديل.

الأداء


الموضوع كلي ، بشكل عام ، كلا من رد الفعل و vue.js سريع. ولكن مع ذلك ، يبدو أن vue.js في المتوسط ​​أسرع بشكل ملحوظ.

رابط رائع من التعليقات على تشغيل TodoMVC بالقياسات:
eigenmethod.imtqy.com/mol/app/bench/#bench=٪2Ftodomvc٪2Fbenchmark٪2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#

وهنا توجد حسابات أكثر تفصيلاً (من الطرف المعني ، مع ذلك) .

مقارنة قياسية أخرى مفصلة ومفصلة:
stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html

سلبيات VueJS


أخطاء قالب وقت التشغيل


أكبر: أخطاء وقت التشغيل غير سارة في القوالب. ضحية لراحة كتابة التعليمات البرمجية. هذا مشابه جدًا لـ Angular 1. تمكن Vue.js من إنشاء العديد من التحذيرات المفيدة لرمز JS: على سبيل المثال ، هناك تحذيرات عند محاولة تحوير الدعائم أو استخدام طريقة data () بشكل غير صحيح ، التأثير الإيجابي لـ React ملحوظ جدًا هنا. لكن أخطاء قالب وقت التشغيل لا تزال ضعف Vue.js. غالبًا ما تكون آثار مكدس الاستثناء عديمة الفائدة وتؤدي إلى طرق Vue.js الداخلية. في هذه الحالة ، في هذه الفئة من الأخطاء وتصحيح الأخطاء ، غالبًا ما يكون JSX أكثر متعة: نظرًا لتجميع "من JS إلى JS" ، يؤدي النقر على خطأ في وحدة تحكم المتصفح عادةً إلى المكان الذي حدث فيه هذا الخطأ بالضبط في التعليمات البرمجية.

مكتبات


البنية التحتية لـ Vue.js لا تزال صغيرة جدًا. في الواقع ، يمكن حساب المكونات المستقرة من المجتمع على الأصابع ، وقد تم بناء العديد منها لـ Vue.js 1 ، وغالبًا ما لا يكون من السهل على المبتدئين معرفة أي إصدار من Vue.js تم إنشاء مكتبة معينة له. يتم تخفيف هذه المشكلة من خلال حقيقة أنه يمكنك القيام بأشياء رائعة في Vue.js دون مواجهة حاجة كبيرة لمكتبات الطرف الثالث. ربما تحتاج فقط إلى مكتبة لطلبات Ajax ( ستكون vue-resource خيارًا جيدًا إذا كنت لا تهتم بالتطبيقات المتشابهة ، وإلا Axios ) وربما Vue-router ، الذي يعتبر مكتبة بدعم جيد من Vue.js.

مجتمع غير ناطق باللغة الإنجليزية


التعليقات الصينية في مدونة معظم المستودعات العامة ، وهذا ليس مفاجئًا: Vue.js أصبح حلًا شائعًا جدًا في الصين (Vue.js يتحدث الصينية)

مشروع شخص واحد.


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

Vue.js في دروبال


إخلاء المسؤولية: نحن لا نخطط لاستخدام Drupal 8 في أي وقت قريبًا في Qwintry ، نظرًا لأننا ننتقل إلى أطر عمل PHP و Node.js أكثر حداثة وأسرع وأبسط ، ولكن رمزنا القديم هو Drupal. نظرًا لأن الموقع الرئيسي qwintry.com يعمل على دروبال ، كان من المهم جدًا بالنسبة لنا التحقق من Vue.js في المعركة هنا. بصراحة ، أنا لست فخورًا بالعديد من أقسام الكود الخاص بنا في هذا المستودع ، فنحن نحاول ألا ندخل إلى بعض الأماكن البارزة أثناء العمل بطريقة ما على الأقل ، ولكن هذا المشروع القديم الذي له تاريخ يعمل بشكل جيد ويولد دخلنا ، لذلك نحن نحترمه ، تحسينه ، ويأتي هنا العديد من الميزات الجديدة. فيما يلي قائمة بالأشياء التي قمت ببنائها على Vue in Drupal: نموذج محرر كيان سريع يتضمن توليد فواتير العملاء بالإضافة إلى التحرير السريع لقوائم المنتجات.هنا كان من الضروري إنشاء واجهة برمجة تطبيقات JSON بسيطة لتحميل الكيانات وحفظها - لا يوجد شيء خاص ، سوى عدد قليل من عمليات الاسترداد. لوحتي تحكم ، من خلال Saas REST API للمنتجات التي نستخدمها لفريق الدعم لدينا ، بحيث لا يحتاج المشغلون للتشغيل عبر الصفحات الإدارية لمواقع الويب الفردية للتحقق من المعلومات المتعلقة بعميل معين. الآن كل هذا مدمج مباشرة في ملف تعريف العميل على موقعنا. أعلم أن العديد من مطوري الواجهة الخلفية لا يزالون عالقين في عام 2010 مع نظام Ajax Drupal kernel. أنا أعلم جيدًا مدى تعقيد كود دروبال عندما تحاول بناء نوع من أشكال معقدة متعددة المراحل باستخدام وظيفة Ajax من النواة - يكاد يكون من المستحيل الحفاظ على هذا الرمز لاحقًا. نعم ، أنا أتحدث عنك ، ctools_wizard_multistep_form () ، وأنتمن خلال Saas REST API للمنتجات التي نستخدمها لفريق الدعم لدينا ، بحيث لا يضطر المشغلون للتصفح عبر صفحات الإدارة لمواقع الويب الفردية للتحقق من المعلومات المتعلقة بعميل معين. الآن كل هذا مدمج مباشرة في ملف تعريف العميل على موقعنا. أعلم أن العديد من مطوري الواجهة الخلفية لا يزالون عالقين في عام 2010 مع نظام Ajax Drupal kernel. أنا أعلم جيدًا مدى تعقيد كود دروبال عندما تحاول بناء نوع من أشكال معقدة متعددة المراحل باستخدام وظيفة Ajax من النواة - يكاد يكون من المستحيل الحفاظ على هذا الرمز لاحقًا. نعم ، أنا أتحدث عنك ، ctools_wizard_multistep_form () ، وأنتمن خلال Saas REST API للمنتجات التي نستخدمها لفريق الدعم لدينا ، بحيث لا يضطر المشغلون للتصفح عبر صفحات الإدارة لمواقع الويب الفردية للتحقق من المعلومات المتعلقة بعميل معين. الآن كل هذا مدمج مباشرة في ملف تعريف العميل على موقعنا. أعلم أن العديد من مطوري الواجهة الخلفية لا يزالون عالقين في عام 2010 مع نظام Ajax Drupal kernel. أنا أعلم جيدًا مدى تعقيد كود دروبال عندما تحاول بناء نوع من أشكال معقدة متعددة المراحل باستخدام وظيفة Ajax من النواة - يكاد يكون من المستحيل الحفاظ على هذا الرمز لاحقًا. نعم ، أنا أتحدث عنك ، ctools_wizard_multistep_form () ، وأنتالآن كل هذا مدمج مباشرة في ملف تعريف العميل على موقعنا. أعلم أن العديد من مطوري الواجهة الخلفية لا يزالون عالقين في عام 2010 مع نظام Ajax Drupal kernel. أنا أعلم جيدًا مدى تعقيد كود دروبال عندما تحاول بناء نوع من أشكال معقدة متعددة المراحل باستخدام وظيفة Ajax من النواة - يكاد يكون من المستحيل الحفاظ على هذا الرمز لاحقًا. نعم ، أنا أتحدث عنك ، ctools_wizard_multistep_form () ، وأنتالآن كل هذا مدمج مباشرة في ملف تعريف العميل على موقعنا. أعلم أن العديد من مطوري الواجهة الخلفية لا يزالون عالقين في عام 2010 مع نظام Ajax Drupal kernel. أنا أعلم جيدًا مدى تعقيد كود دروبال عندما تحاول بناء نوع من أشكال معقدة متعددة المراحل باستخدام وظيفة Ajax من النواة - يكاد يكون من المستحيل الحفاظ على هذا الرمز لاحقًا. نعم ، أنا أتحدث عنك ، ctools_wizard_multistep_form () ، وأنتajax_render !

في الوقت نفسه ، يتم دفع هؤلاء المطورين إلى الأمام بسبب متطلبات الواجهات الحديثة ، ولكن تعقيد البنية التحتية الحديثة لـ JS يدفعهم إلى الركود. نعم ، أعرف نفسي قبل عام. حتى الرجال ، استمع لي! لن تجد لحظة وطريقة أفضل لتحسين واجهاتك من الآن اتخاذ Vue.js ، ووضعها في المواقع / جميع / المكتبات ، وإضافتها باستخدام drupal_add_js () إلى القالب والبدء في كتابة التعليمات البرمجية. ستصدم من مدى سهولة الحفاظ على نظام يكون فيه Drupal مسؤولًا فقط عن JSON الذي تم إنشاؤه عندما يتم تشغيل جميع تعليمات العميل بالكامل ، بما في ذلك النماذج ، بواسطة Vue.js.

Vue.js في Yii2


حقيقة ممتعة: تم إنشاء Yii بواسطة مطور اللغة الصينية Qiang Xue. وبالتالي ، يمكن للمرء أن يطلق على Yii + Vue.js مكدس ليس فقط مكدسًا ، يكاد يكون من المستحيل نطق اسمه في المحاولة الأولى ، ولكن أيضًا مكدس مع التراث الصيني (بطريقة جيدة). بالنسبة للإصدار الجديد من Qwintry.com (لم يتم نشره بعد) ، اخترنا Yii2 ، وهو في رأيي أحد أفضل وأسرع أطر عمل PHP. إنه بالتأكيد ليس شائعًا مثل Laravel ، الذي أخذ زمام المبادرة في عالم PHP ، ولكن مكدس Yii2 جيد جدًا معنا.(على الرغم من أننا ننظر إلى Laravel من وقت لآخر ، فإن المطورين هناك يسخرون ، وهناك بالطبع بنية أساسية أكثر نضجًا فيما يتعلق بالمكتبات). نعمل حاليًا على تقليل كمية HTML التي تنشئها Yii2 و PHP ، مع التركيز بشكل أكبر على REST API ، التي تنشئ JSON لجانب العميل ، والتي تعمل على Vue.js / Swift / Java. يتم استخدام نهج API الأول لمعظم نماذج Active Record في المشروع. نحن هنا جادون بالفعل بشأن واجهة برمجة التطبيقات ولهذا السبب ننفق الكثير من الوقت على وثائق واجهة برمجة التطبيقات الجيدة ، حتى لو لم تكن واجهة برمجة التطبيقات هذه عامة. في أقسام الكود حيث يتم إنشاء جزء HTML على مستوى PHP ، نستخدم حلولنا وحزمة الويب الخاصة بنا للتجميع والنشر الملائم لعناصر واجهة المستخدم Yii2 ، والتي بدورها تستخدم مكونات Vue أحادية الملف. مع PHP7 وأحدث MySQL ، لا يختلف وقت استجابة الواجهة الخلفية Yii2 JSON كثيرًا عن Node.شبيبة خلفية (أنا أتحدث عن سرعة استجابة من 15-20 مللي ثانية) ، هذه ليست أرقامًا كونية ، بصراحة ، ولكن هذا أكثر من كافٍ لاحتياجاتنا ، والأهم من ذلك ، إنه أسرع 10-20 مرة مما يمكن أن يعطيه موقعنا دروبال القديم. في الوقت نفسه ، هذا هو PHP قديم جيد (وممل ، ربما) مع كل قوة مكتبات الملحن وقاعدة تعليمات برمجية مستقرة. إن استجابة الواجهات المبنية على Yii2 و Vue.js مقبولة جدًا ، ومن وجهة نظر قراءة التعليمات البرمجية ، كل شيء هنا أيضًا.إن استجابة الواجهات المبنية على Yii2 و Vue.js مقبولة جدًا ، ومن وجهة نظر قراءة التعليمات البرمجية ، كل شيء هنا أيضًا.إن استجابة الواجهات المبنية على Yii2 و Vue.js مقبولة جدًا ، ومن وجهة نظر قراءة التعليمات البرمجية ، كل شيء هنا أيضًا.

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

الخلاصة


نحن نكتب كود Vue.js كل يوم لمدة 4 أشهر في مشاريع مختلفة ، والنتائج مثيرة للإعجاب. 4 أشهر ليست شيئًا في العالم الخلفي ، ولكن بالنسبة لعالم JS هذه فترة لائقة ولدت فيها خمسة أطر وتموت :) دعنا نرى ما سيحدث بعد ذلك. أعتقد أن Vue.js سيكون الحل الرئيسي لـ JS في الـ 16-24 شهرًا القادمة إذا اتخذ إيفان أنت الخطوات الصحيحة ، على الأقل بين الفرق الأمامية والخلفية الصغيرة. ستكون مجموعة React هي السائدة في عام 2017 ، خاصة إذا استمرت React Native في النمو والتحسن بنفس السرعة التي هي عليها الآن.

UPD: ضربت هذه المقالة أعلى HackerNews، وتلا ذلك نقاش مفيدة (250+ تعليق): news.ycombinator.com/item؟id=13151317

في أعلى رديت WEBDEV زرنا أيضا، 60+ تعليقات هنا. رأي تعليق مضحك حول Angular2 من هناك:
تشبه جميع وثائق Google قراءة مستندات Microsoft من أوائل العقد الأول من القرن الحادي والعشرين.
"إن إعداد مشروع الزاوي هو قطعة من الكعكة! فقط تأكد من أن النموذج الأولي المرجعي بدون حالة يرث من الكائن القديم لمحمل الذاكرة الأساسية الذي يقوم بتنفيذ موفر خدمة MODOK (ليس جزءًا من المركز: انظر هنا للحصول على تفاصيل غير قابلة للقراءة على قدم المساواة). ستكون جاهزًا بعد ذلك لتجميع نواة Angular الخاصة بك ، مع توخي الحذر لاستخدام Webpack 2.3.9 (ملاحظة: ليس 2.3.8 كما هو مرفق مع المستودع). هذا كل ما تحتاج إلى معرفته للبدء في مشروع Angular رائع. الزاوي: جعل التنمية بسيطة وممتعة مرة أخرى! "

أسئلة من القراء:


JSX رائع وصحيح ، لكنك لست كذلك! إذا كنت تريد حقًا شروطًا - قم ببرمجة مكون If الخاص بك ، فهذه ثلاثة أسطر!

من غير المريح اختيار إطار عمل ، ثم القيام بهذه الأشياء ضده ، سيسألك كل مطور جديد يأتي إلى المشروع عن مثل هذه القرارات ، وفي مكونات الأشخاص الآخرين سوف تتعثر عينيك دائمًا على الانكماش.
علاوة على ذلك ، إذا كان المكون المكتوب "جبهته" سيواجه مشاكل في أن المكونات الداخلية يتم تنفيذها دائمًا. ولكن هناك حلول أكثر إثارة للاهتمام: github.com/AlexGilleran/jsx-control-statements

فماذا تقترح ، عزيزي ، أنت الآن بحاجة إلى إسقاط رد الفعل وإعادة كتابة كل شيء إلى Vue.js على وجه السرعة؟

لا لا! React هو إطار عمل ممتاز ، ويسمح لك بكتابة تعليمات برمجية قابلة للقراءة والمدعومة ، وأيضًا تم كتابة عدد كبير من المكتبات عالية الجودة من أجله (والمكونات الدقيقة والقيود الخاصة بـ JSX ، التي "قمت بتوبيخها" أعلاه ، تلعب دورًا إيجابيًا هنا ، بالنسبة للمكتبات العامة هذا مبررة بالفعل في كثير من الأحيان) ، والتي ليست لأي حل JS آخر. إذا كنت أنت وفريقك سعداء بكل شيء في JSX ولا تهتم بالكتابة كثيرًا ، ربما لا فائدة من التبديل إلى Vue.js ، فإن اللعبة ببساطة لا تستحق الشمعة. كان العديد من عشاق JS يحبون مؤخرًا القفز من إطار إلى إطار. لا تسيء استخدامه ، في رأيي ، من الأفضل قضاء هذا الوقت على شيء أكثر إثارة للاهتمام سيلاحظه المستخدمون في مشروعك.

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

لم أقرأ المقالة بأكملها ، ولكن في العنوان قلت شيئًا سلبيًا هناك حول الحصانة ، فربما أنت لست أرثوذكسيًا بسبب قلة خبرتك وغبائك ولا تفهم كم هو رائع النهج الوظيفي!

دعونا نفصل الحصانة كنموذج وظيفي (نحن نحترم إلى حد كبير النهج الوظيفي ، ومفهوم المناعة ونقاء الوظائف) والحالة الحالية لعالم JS ومكتباته. إذا قام مطور ، بعد قراءة مدونة Facebook ، بقبض على Immutable.js بفرح ووضعها في الإنتاج ، ثم أدرك أنه ليس لديه رصيف جيد جدًا ، لا يعمل لوداش وكل ما تبقى من الشفرة التي كتبها الجيل السابق من المطورين (نعم ، أنا على علم حول الأغلفة الثابتة حول Lodash ، شكرا) ، وبالتالي فشل المطور في الموعد النهائي - وهذا يعني أن المطور لم يشتري النموذج الوظيفي ، بل الضجيج حول المكتبة المحددة. لا تعتقد أنه إذا كان لدى Facebook مشاكل حقيقية يحلونها باستخدام Immutable.js ، فهذا يعني أنك ستواجه مشاكل من نفس الترتيب في صفحتك المقصودة أو SPA.على الأرجح لا ، بالأحرىسوف ينفد المستثمرون من الأموال الخاصة بك ، ستحتاج إلى طرح ميزات العمل في أسرع وقت ممكن ، ويكفي أن يكون الرمز عاديًا ولا يتغير حيث لا يكون ضروريًا ، ولا يحتاج إلى استخدام Immutable.js لهذا (اقرأ الرأي حول Immutable.js ، على سبيل المثال ، هنا ). بشكل منفصل ، ألاحظ أن عددًا كبيرًا من مطوري JS ، الذين رأيت آرائهم كميزة قاتلة رئيسية في Immutable.js ، لا تسمى نقاء وموثوقية الشفرة الناتجة ، ولكن - الانتباه! - زيادة الإنتاجية (نتحدث عن مقارنات سريعة للهياكل)! هناك شيء ما في هذا العالم خاطئ إذا دفع الناس قطعة وظيفية من هذا المستوى من أجل تحسين الأداء في مشروعهم. يبدو أن الموضة تدخلت مرة أخرى ...

إذا كنت ترغب في تبسيط حياتك ، فقط توقف عن تغيير حالتك ، وانتقل إلى الدعائم ، وهذه الأشياء البسيطة ستحسن حياتك الآن.

Source: https://habr.com/ru/post/ar400227/


All Articles