تحطيم بودكاست الحلقة 26 مع ناتاليا تبلوهينا: ما الجديد في Vue 3.0؟

في حلقة البودكاست هذه ، نتحدث كل شيء عن VueJS. ما الجديد في الإصدار 3.0 ، وما مدى صعوبة الترحيل؟ درو ماكليلان يتحدث إلى عضو الفريق الأساسي ناتاليا تبلوهينا لمعرفة الإجابة.

وتظهر الملاحظات

• VueJS
• دليل الهجرة Vue 3
• ناتاليا على تويتر
• Webste الشخصية لناتاليا

تحديث اسبوعي

• طرق مختلفة لتصميم صفحات المنتجات الرقمية
  بقلم سوزان سكاكا
• اختبار الوحدة في تطبيقات React الأصلية
  كتبه Fortune Ikechi
• 5 طرق تساعد Google Analytics مطوري الويب في تصميم UI / UX
  بقلم كلارا بوينكونسيجو
• فهم جينات TypeScript
  كتبه جيمي كوركهيل
• كيفية استخدام حركة الوجه للتفاعل مع الطباعة
  كتبه إدواردو كافازا

نسخة طبق الأصل

درو ماكليلان: إنها مطورة ويب شغوفة وخبيرة مطور برامج Google ومتحدث ومؤلف في المؤتمر. حاليًا هي مهندس واجهة موظفين في GitLab ، لكنك قد تعرف أفضل ما لديها كعضو في فريق Vue JS Core. من الواضح أنها تعرف طريقها حول Vue أفضل من أي شخص تقريبًا. لكن هل تعلم أنها علمت الكنغر ذات مرة أن يغني. أصدقائي المحطمون ، يرجى الترحيب بـ ناتاليا تبلوهينا.

درو: مرحبًا ناتاليا ، كيف حالك؟

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

درو: حسنًا ، لقد بذلت جهدًا. لكن السؤال المهم هو ، هل تحطمون؟

ناتاليا: بالطبع أنا كذلك.

درو: هذا جيد. لذلك أردت أن أتحدث إليكم اليوم عن بعض الأخبار المثيرة حقًا التي لدينا في سبتمبر مع إصدار Vue 3.0. لقد كان إصدارًا رئيسيًا من حيث رقم الإصدار ولكنه حقًا إصدار كبير لـ Vue ، وكان قيد التشغيل لبعض الوقت ، ألم يحن الوقت؟

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

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

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

ناتاليا: كان الأداء هو التالي. لا يزال Vue 2 يتمتع بأسوأ أداء ولم يكن لديه ، ولكن كان لدينا بعض الأفكار حول كيفية جعل Vue أسرع. وأيضًا كانت هناك نقطة ألم واحدة لجزء معين من ، دعنا نقول جمهورنا ، الأشخاص الذين يستخدمون Vue. كان TypeScript. تمت كتابة Vue 2 داخليًا في Flow ، والذي لا يزال مكتوبًا بقوة ، ولكن الكتابة باستخدام TypeScript كانت كابوسًا حقيقيًا خاصة إذا كنت تعمل مع إدارة الدولة Vuex. كان هذا مرة أخرى جزءًا كبيرًا. وآخرها ، لقد فاتنا نوعًا ما وظيفة المنطق المجرد ، ليس من حيث المكونات بل الأجزاء المنطقية المعقدة. مثل مساعدي الوظائف وما إلى ذلك ، لكن يجب أن يكونوا قادرين على تضمين نشاط المشاهد أيضًا. يمكن أن يكون React Hooks مثالًا رائعًا هنا ، فهي تسمح لك بتلخيص أجزاء الوظيفة وكان هذا مفقودًا بوضوح في Vue. وأنا أعلم أنه يبدو الآن مثل ، "لقد سرقت الميزة من React." ليس في الحقيقة. أعتقد أن التلقيح المتبادل للأفكار هو جزء كبير ولطيف في نظامنا البيئي ، كما أنه يساعد المطورين على التبديل بين المفضلات ، أليس كذلك؟

ناتاليا: لذلك كنا نعمل على هذه الميزات الرئيسية لإنشاء Vue 3 كإصدار رئيسي.

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

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

ناتاليا: أنا أعارض بشدة ، مثل ، "أنت تسرق الأفكار". هذا ليس سرقة ، هذا مجرد تلقيح متبادل.

درو: بالضبط ، أجل. لقد ذكرت أن الترحيل إلى TypeScript ، لذا Vue 3 نفسها مكتوبة باستخدام TypeScript الآن ، فهل هذا صحيح؟

ناتاليا: نعم ، نعم. وثق بي ، درو ، كنت أكتب التوثيق ، المستند الصغير حول كيفية استخدام Vue مع TypeScript. وكنت مثل ، حسنًا ، ربما بطريقة ما مثل Vue 2. وقد بالغت في تعقيد المستند بشدة ، كنت أحب كتابة كل شيء بشكل صريح. تبدو جيدة كل شيء كتبته. يمكنني رؤية الأنواع ، لذا فإن رابط ts الخاص بي سعيد ، جيد جدًا حتى الآن. ثم قال أحد مطورينا الذي كان يعمل مع TypeScript ، "لست بحاجة إلى القيام بذلك". كيف كيف؟ "لا تحتاج إلى القيام بأنواع صريحة من البيانات. أنت فقط تعطيه قيمة أولية و ts-link يعرف رقمه. لقد كتبته بالفعل. " مثل ، كيف يحدث ذلك؟ "أزلت 90٪ من الأنواع الصريحة من المستند. هناك شيئان فقط ستحتاج إلى كتابتهما وهما وكيل المكون ، وسوف يكون للخصائص المحسوبة. لا يزالون بحاجة إلى أنواع العودة. لكن الباقي يشبه ، يكتب تلقائيًا ، فقط اكتب مكونًا بطريقة نسميها تعريف المكون. وهذا كل شيء. لقد كتبته ".

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

درو: هذا رائع ، لذا فهو مفيد لكل من Vue Core Project ، وللمطورين الذين يبنون تطبيقات باستخدام Vue لأنهم يستطيعون استخدام TypeScript في تطبيقاتهم بشكل جيد مع Vue الآن ، حيث لم يتمكنوا من استخدام 2.0 ، وأي إصدار جيد 2.0 بسهولة. أولئك الذين هم على دراية بمجتمع Vue سيدركون أن منشئ Vue Evan You لا يزال يقود المشروع بنشاط كبير. كيف يعمل الفريق الأساسي؟ كيف يتم تنظيمها عندما يتعلق الأمر بعملية التطوير؟ ليس كل شيء هو إيفان؟

ناتاليا: هذا سؤال رائع ، درو ، لأنه لسنوات ، حرفيًا ، كان الناس يتحدثون عن Vue كما أقتبس هذا وسأبدو قاسيًا ، لكن آسف ، إنه مثل ، "إطار عمل لشخص صيني واحد ، مثل إطار صيني حتى" . وأعني أنه حتى مع Vue 1.X ، كان هناك فريق بالفعل وكان هناك فريق كبير خلف Vue 2 وفريق أكبر خلف Vue 3. الشيء هو أننا جميعًا لدينا مسؤوليات مختلفة عندما نتحدث عن Vue.

ناتاليا: هناك أشخاص يعملون على Core ، وهذا ليس إيفان نفسه فحسب ، إنه يقوم بمعظم العمل على Vue Core ، بالتأكيد ، ويقود المشروع أيضًا. ولكن هناك أشخاص يعملون في Vue Core ، وإسهاماتهم لا تقدر بثمن على الإطلاق. وهناك عدد قليل من الأشخاص الجدد ، الذين ينضمون إلى فريق Vue أيضًا ، يعملون في Core. وهناك أيضًا فرق أصغر تعمل على النظام البيئي ، وهناك أشخاص يعملون على Pure Router ، مثل Eduardo ، وهناك أشخاص يعملون على Vue CLI ، على Vuex ، على التوثيق أيضًا.

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

درو: هذا رائع لأنه حالة يمكن للمساهمة في مشروع مفتوح المصدر أن تدفع فيه نوعًا ما إلى الفرد. يحصلون على بعض التقدير ويمكن أن يكون لذلك تأثير في حياتك المهنية وماذا لديك.

درو: للمستمعين الذين قد لا يكونون معتادين على Vue ولكن ربما يكونون على دراية بالأطر التفاعلية الأخرى ، مثل React و Angular وما إلى ذلك. ما هي التغييرات الكبيرة ، نوعًا ما ، في العنوان مع Vue 3 وعلى وجه التحديد ما هي المشاكل التي يحاولون حلها؟ لقد ذكرت التكوين سابقًا كأحد هذه الأشياء ، هل هذا من التغييرات الكبيرة؟

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

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

ناتاليا: مباشرة بعد هذا البيان ، كان RFC حيث اقترحنا التغيير للتو ، انفجر Reddit. كان رديت مليئًا بالمثل ، "أوه ، يا إلهي. سأحتاج إلى كتابة كل شيء. يا إلهي. Vue هو Angular جديد. سوف يكسرون كل الأشياء ". وكان هناك رجل أنشأ مقالًا على dev.to اسمه ، Vue's Darkest Day. بصراحة ، لقد كان أحلك يوم. شعرنا بذلك ، لكنني كنت أحاول نوعًا ما محاربة هذا الأمر على تويتر الخاص بي مثل ، "أشخاص لسنا كذلك حقًا ... كانوا يقولون إننا بدأنا في تغيير RFC ، أعتقد أن إيفان بدأ في تغيير RFC دون الإعلان عن التغييرات. لذلك قال ، "سأعيد كتابة هذا بسرعة. دعنا ندفع إلى الماجستير ". كان الناس غاضبين من هذا. نظرًا لأنهم كانوا يتجادلون حول نقاط معينة ، فأنت تقوم فقط بتحديث الصفحة ولم تعد هذه النقاط موجودة. تشعر وكأنني أحمق أم مجرد… ما هذا بحق الجحيم؟ أعني ، كان هناك. أتذكر هذا. وأعتقد أن استراتيجية الاتصال لدينا يمكن أن تكون أفضل وهذا ليس نحن.

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

درو: ما هو نوع المشكلة التي قد يضعها شخص ما في مكان يعتبر Composition API فيه شيئًا جديدًا يساعده على الخروج من هذه المشكلة؟ ما المشكلة التي تحلها؟

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

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

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

درو: كل النطاق مختلط تمامًا؟

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

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

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

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

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

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

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

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

ناتاليا: أولاً وقبل كل شيء ، تبلغ نسبة سطح API 90٪ مما كانت عليه. لم يكن لدينا الكثير من الأشياء المهملة أو الفلاتر المهملة التي يمكن استبدالها بمحاور أحداث مهملة. إذا كنت ترغب في استخدام EventEmitter ، فستحتاج إلى استبدال طريقة عرض تعتمد على بعض المكتبات الخارجية أيضًا. هذه تغييرات كبيرة ، لكن بالحديث عن الهجرة ... دعني أوضح ، أنا ممزق حقًا الآن ، لأنني من ناحية عضو فريق Vue JS الأساسي. من ناحية أخرى ، أنا مهندس موظفين في المشروع الكبير الذي يستخدم Vue. إذا كنت على وشك بدء الترحيل الآن ، لا أوصي بذلك. بادئ ذي بدء ، لم يتم إصدار النظام البيئي ، أعني إذا تحدثنا عن المكتبات الأساسية مثل Pure Router و PUX و Vue CLI ، فهذه في حالة جيدة لكنها لا تزال مرشحة للإصدار وليست إصدارات. وإذا تحدثنا عن أنظمة بيئية أخرى مثل ليس المكتبات الأساسية ، ربما ، مكتبات مكونات واجهة المستخدم ، وربما بعض مكتبات التحقق من صحة النماذج ، فهي ليست جاهزة ، في الغالب ، لـ Vue 3. وإذا كان لديك مشروع كبير ، فلديك الكثير من التبعيات التي تحتاجها رعاية. لذا فإن هذا أمر معقد.

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

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

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

درو: لذا فإن أداة الترحيل التي ذكرتها تبدو ممتعة للغاية. هل هذه في الأساس أداة تحليل ثابتة تبحث في التعليمات البرمجية الخاصة بك و ...

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

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

ناتاليا: تعرف أن هذا يحدث للجميع. أنشأنا ملحمة ضخمة للعمل على هذا. ابحث عن كل المجموعات الحالية من بناء الجملة القديم. نحن نبذل جهدًا لاستبدال EventEmitters ، مرة أخرى ، مشروع عمره سبع سنوات ، لا تحكم علينا. لدينا EventEmitters. كان GitLab يعمل على EventHubs. استبدلنا متعة Vue بالمكتبات الخارجية. أود أن أوصي بفعل نفس الشيء. انتقل إلى دليل الترحيل للتحقق مما يمكن استبداله بالفعل والتغييرات التي يمكنك إجراؤها بالفعل للتحضير وبدء العمل على ذلك.

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

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

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

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

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

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

ناتاليا: نعم ، جزء كبير منها ، على سبيل المثال ، المرشحات ، هي بالتأكيد بعض الحالات البارزة لأنه حتى في GitLab ، وللمرة الثالثة ، بقاعدة بيانات عمرها سبع سنوات وأخرى كبيرة. كان لدينا مرة أو مرتين من الفلاتر ولم تعد مستخدمة. لقد كان شيئًا جيدًا أننا بحثنا عنها وأزلناها تمامًا لأن مثل ، "أوه ، رمز غير مستخدم" ومرة ​​أخرى ، من يهتم به موجود فقط.

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

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

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

درو: هناك لافتة صغيرة جدًا في الأعلى ، نعم.

ناتاليا: نعم ، مثل الصغيرة.

درو: نعم.

ناتاليا: أعتقد أننا يجب أن نجعلها أكبر. أكبر مع تباين ألوان أفضل. تظل مشاعري المتعلقة بإمكانية الوصول كما يلي ، "أوه ، لا يوجد أي تباين هناك".

درو: هذه أخبار جيدة. إذا كان شخص ما قد بدأ ، ربما ليس مشروعًا كبيرًا ، ولكن إذا كان شخص ما يبدأ مشروعًا شخصيًا أو يرغب في تعلم Vue ، بالتأكيد ، Vue 3 هو المكان المناسب للبدء؟

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

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

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

ناتاليا: في نفس الوقت الذي يقول فيه إيفان ، "أوه ، سنصنع Vue 3". الجميع يحبون ، "نعم ، رائع". ربيع عام 2019 أنتم العصا الأساسية. أعني أن GitLab كله مثل ، "أوه ، هذا لطيف. نحن جميعًا لدينا هجرة وأنت تعرف من المسؤول نوعًا ما عن هذا؟ " ويمكنك فقط أن تتخيل كيف يحدث ذلك عندما تكتب وثائق لـ Vue 3 ، سيقرأ الجميع وستكون شركتك الخاصة مثل ، "أوه ، أريد أن أتعلم شيئًا عن Vue 3 ، لا يمكنني فهم مستنداتك." لذا فأنت مثل ، "أوه ، هذا مؤلم للغاية" لأنك مطور هناك وكاتب تقني ، نوع من هنا.

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

درو: بالنظر إلى الجيل السابق من أطر عمل جافا سكريبت ، أعتقد أن أحد أكثرها نجاحًا كان jQuery ، في الماضي ، وأعتقد أنه اكتسب قوة جذب لأنه كان يحتوي على واجهة برمجة تطبيقات جيدة التصميم للغاية. هذا المفهوم الخاص بأخذ محدد CSS واستخدامه للاستعلام عن DOM في JavaScript كان شيئًا شاعه jQuery. And I think that really resonated with hardworking developers who didn't need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

درو: إنه كذلك حقًا.

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.