ما هو الجديد في الزاوي 8 الإصدار

خرجت الزاوية الزاوية 8 ، وتتضمن معاينة Ivy ودعمًا للعاملين في الخدمة والتحميل التفاضلي وبعض اللمسات الأخيرة. يشرح مانفريد شتاير أهم التغييرات في الإصدار الأخير.

كما هو مخطط له ، لم تكن هناك مفاجآت: يمكن تحديث إطار العمل و CLI باستخدام تحديث ng ، والميزات الجديدة هي إضافة لطيفة إلى شعار "التطور بدلاً من الثورة".

في هذه المقالة ، يتحدث المؤلف عن أهم الميزات الجديدة في Angular 8 و Angular CLI 8. يمكن العثور على الأمثلة المستخدمة في هذه المقالة على GitHub .

تحت القطع:

• أول اطلالة له على اللبلاب
• عمال الويب
• تحميل التفاضلية
• وحدات التحميل كسول
• التغييرات الحرجة في ViewChild و ContentChild
• ميزات جديدة ngUpgrade

أول اطلالة له على اللبلاب

الأخبار الكبيرة التالية التي ينتظرها مجتمع Angular هي Ivy ، وهو مترجم جديد ، وأيضًا محرك عرض جديد. يمكن أن تنشئ اللبلاب حزمًا أصغر بكثير ، وتجميعًا تزايديًا ، كما أنها تشكل أساسًا للابتكار في المستقبل في Angular.

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

مع Angular 8 ، تتوفر نسخة أولية من Ivy للاختبار. والغرض من هذا الإصدار هو الحصول على ردود فعل سريعة. لذلك ، يوصي الفريق الزاوي بعدم استخدام Ivy في المنتج الآن ، ولكن الاستمرار في استخدام محرك العرض الكلاسيكي (الشكل 1)


بفضل التحميل التفاضلي (كما هو موضح أدناه) ، يمكن تحسين أحجام الحزمة الآن.

وفقًا لـ Brad Green ، CTO من فريق Angular في Google ، في ngconf 2019 ، ستعمل Ivy على تحسين أحجام العبوات في وضع التوافق جنبًا إلى جنب مع التحميل التفاضلي. وبالتالي ، يمكن أن daredevils بالفعل اختبار Ivy API في المستقبل. هذا الوضع ، على وجه الخصوص ، لديه إمكانات كبيرة للتحسين. لا تزال واجهة برمجة التطبيقات خاصة. بالنظر إلى فصوله ووظائفه ، يمكنك القول: إنها تبدأ برمز خاص ɵ.

إذا كنت ترغب بالفعل في تجربة Ivy ، فيمكنك إنشاء مشروع جديد باستخدام مفتاح التبديل للتمكين:

ng new ivy-project --enable-ivy 

يخبر هذا المفتاح CLI بحفظ الإدخال التالي في تكوين tsconfig.app.json:

 "angularCompilerOptions": { "enableIvy": true } 

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

 ng serve --aot 

بالإضافة إلى ذلك ، يجب الانتباه إلى حجم التطبيق الذي تم إنشاؤه باستخدام ng build. مع الزاوي 9 ، يجب تنشيط اللبلاب بشكل افتراضي. حتى ذلك الحين ، يخطط الفريق Angular لمواصلة العمل لضمان التوافق مع الإصدارات القديمة.

عمال الويب

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

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

 ng generate worker n-queens 

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

 import nQueens from './n-queens'; addEventListener('message', ({ data }) => { const result = nQueens(data.count); postMessage(result, undefined); }); 

يتم تنفيذ الحدث عندما يرسل سلسلة الرسائل الرئيسية رسالة إلى العامل. تحتوي المعلمة على المعلومات المرسلة من الدفق الرئيسي. في هذه الحالة ، يقتصر على خاصية العد ، والتي تحدد حجم رقعة الشطرنج. بعد تقييم وظيفة nQueens ، التي تم حذفها هنا ، يرسل eventListener النتيجة مرة أخرى إلى سلسلة الرسائل الرئيسية من خلال postMessage. وبالتالي ، حرائق المتصفح حدث رسالة.
يتم استخدام فئة العامل في مكون الاستخدام للتفاعل مع البرنامج النصي العامل:

 const count = parseInt(this.count, 10); const worker = new Worker('../logic/n-queens.worker', { type: 'module' // Worker uses EcmaScript modules }); worker.postMessage({count}); worker.addEventListener('message', (event) => { // tslint:disable-next-line: no-console console.debug('worker result', event.data); // Update chessboard this.processResult(event.data); }); 

يرسل المكون رسالة بالحجم المطلوب من رقعة الشطرنج إلى العامل عبر postMessage وبالتالي يبدأ الحساب هناك. يتلقى النتيجة من خلال رسالة الحدث.
في المستقبل ، يعتني CLI بالتجميع الصحيح لنصوص العمال. يتعرف برنامج التحويل البرمجي لـ TypeScript في نهاية .worker.ts ، والذي يتم تسجيله في tsconfig.worker.json الذي تم إنشاؤه بواسطة الأمر ng تنشئ worker . لضمان عدم تأثير CLI على هذه الملفات مرة أخرى عند إنشاء التطبيق الرئيسي ، يضع ng تنشئ العامل قالب الملف نفسه في قسم الاستبعاد من tsconfig.app.json.
التنفيذ الكامل في المشروع مع أمثلة للمؤلف. للمقارنة ، يمكن حل مثال لمهمة N queens في كل من الخيط الرئيسي وعامل الويب. عندما تحاول حل مشكلة في رقعة الشطرنج 12 × 12 ، على سبيل المثال ، سترى أن واجهة المستخدم معلقة في الحالة الأولى ، في حين أن حساب الخلفية مع عامل الويب لن يقلل من الأداء.

تحميل التفاضلية

حتى الآن ، كان من المعتاد تجميع التطبيقات في ES 5 القديمة الجيدة ، لأن هذا الإصدار من "JavaScript من آبائنا" يعمل في كل مكان تقريبًا. وهذا يعني أن كلاً من IE11 و Google crawler على الويب يمكنهما تنفيذ هذا الرمز.
ومع ذلك ، فإن ES 2015 الجديد والإصدارات اللاحقة له أكثر فاعلية: فهي تسمح لك بإنشاء المزيد من الحزم المدمجة ويمكن للمتصفح أيضًا تفسيرها بشكل أكثر كفاءة. نظرًا لأنه كان من المعتاد في السابق الرجوع إلى ES 5 باعتباره القاسم المشترك الأقل شيوعًا ، لم تستطع المتصفحات الحديثة ، للأسف ، الاستفادة من الإصدار الجديد من اللغة.
لقد انتهى الآن: بدءًا من الإصدار 8 ، تحتوي CLI على ميزة تسمى التحميل التفاضلي. تتمثل الفكرة في توفير مجموعتين من الحزم: واحدة تستند إلى ECMAScript 5 ومصممة للمتصفحات القديمة ، والثانية تعتمد على إصدار جديد من ECMAScript ، مثل ECMAScript 2015 ، وتوفر للمتصفحات الحديثة المزايا السابقة.
لا تحتاج إلى القيام بالكثير من العمل لتمكين التحميل التفاضلي: كل ما هو مطلوب هو تعيين الحدود العليا والدنيا للإصدارات المدعومة من ECMAScript. يشار إلى الحد العلوي في tsconfig.json على النحو التالي:

 "target": "es2015" 

يتم تعريف الحد الأدنى في ملف قائمة المتصفحات. يتضمن هذا الملف متصفحات سيتم دعمها وفقًا لمعايير معينة ، مثل حصة السوق ، على سبيل المثال. يمكن حفظها ، على سبيل المثال ، في ملف قائمة المتصفحات ، والذي تنشئه CLI في جذر المشروع عند إنشاء مشروع جديد:
> 0.5%
last 2 versions
Firefox ESR
not dead
IE 9-11

في هذه الحالة ، تتضمن قائمة المستعرضات المتصفحات ES 5 مع إدخال IE 9-11. وبالتالي ، يُعرّف CLI الحد الأدنى بأنه هذا الإصدار. عندما يتلقى CLI أمر ng build ، سيتم تشغيل عملية البناء لكلا الإصدارين:

عيب هذه العملية هو: الوقت اللازم للتجميع يتضاعف.
يمكن للمتصفحات الآن تحديد إصدار الحزم المراد تنزيلها. للقيام بذلك ، يحصلون على روابط إلى البرامج النصية في index.html الوظيفة الإضافية: أولئك الذين يشيرون إلى حزم ECMAScript 5 يتلقون إضافة nomodule. وبالتالي ، لن تتجاهل المتصفحات التي تدعم ECMAScript ، وبالتالي دعم ECMAScript 2015+ هذا البرنامج النصي. من ناحية أخرى ، يتم تطبيق حزم ECMAScript 2015+ بواسطة CLI مع type = "module". وبالتالي ، ستتجاهل المتصفحات القديمة هذه النصوص:

 <script src="main-es2015.js" type="module"></script> <script src="main-es5.js" nomodule></script> 

على عكس ng build ، تستخدم بقية أوامر CLI فقط (!) الحد الأعلى لدعم ES. في حالتنا ، هذا هو ECMAScript 2015. يحدث هذا ، بما في ذلك لأسباب الكفاءة: أثناء تصحيح الأخطاء والاختبار ، عادةً ما يريد المطورون رؤية النتيجة في أسرع وقت ممكن ، دون انتظار الإنشاء الثاني.

وحدات التحميل كسول

من الأيام الأولى ، يدعم جهاز التوجيه الزاوي التحميل الكسول. حتى الآن ، تم تحقيق ذلك من خلال التعريف السحري للوحدة القابلة للتحميل:

 { path: 'lazy', loadChildren: () => './lazy/lazy.module#LayzModule' } 

تصف القيمة قبل # المسار المؤدي إلى ملف تنفيذ الوحدة النمطية ؛ القيمة بعد تعني الفئة الموجودة فيه. يعمل نمط الوصف هذا في Angular 8 ، ولكن تم إهماله فيما يتعلق بالواردات الديناميكية لـ ECMAScript:

 { path: 'lazy', loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule) } 

لا يزال خيار السجل الجديد يحتوي على اسم الملف كقيمة سحرية. ومع ذلك ، نظرًا لأن الواردات مدعومة من قبل العديد من IDE ، فإن القيم غير الصالحة ستُرجع خطأً على الفور.

التغييرات الحرجة في ViewChild و ContentChild

هناك تغييرات جوهرية في استخدام ViewChild و ContentChild ، والتي ، لسوء الحظ ، في الماضي لم تعمل دائمًا بشكل متوقع. إذا كان يتم استخدامها في الإصدارات السابقة من قبل أحد مكونات الاستعلام عن العناصر التي ليست داخل التوجيه الهيكلي ، مثل ngIf أو ngFor ، كانت نتيجة الاستعلام متاحة بالفعل في ngOnInit. خلاف ذلك ، لا يمكننا الوصول إليهم قبل ngAfterViewInit (أو ngAfterContentInit لـ ContentChild). بالنسبة للعناصر التي تم تحميلها في DOM لاحقًا بسبب ربط البيانات ، يجب أن يكون رمز البرنامج ngAfterViewChecked أو ، وفقًا لذلك ، ngAfterContentChecked.
نظرًا لأن هذا السلوك كان مربكًا ، يجب أن يشير المكون الآن إلى متى يجب أن تحدث الدقة:

 @ViewChild('info', { static: false }) paragraph: ElementRef; 

إذا كانت العلامة الثابتة صحيحة ، فسيحاول Angular العثور على العناصر عند تهيئة المكون. هذا يعمل فقط إذا لم تكن في التوجيه الهيكلي. عند استخدام static: false ، يتم تنفيذ الدقة بعد تهيئة العرض أو تحديثه.
سيحاول تحديث ng إدخال القيمة الصحيحة تلقائيًا ، إذا لم يكن ذلك ممكنًا ، فسيضيف تعليقًا مع TODO.
لن يؤثر هذا التغيير على الاستعلامات مع كل من عارلي ViewChildren و ContentChildren. كان لديهم دائمًا سلوك ديناميكي ، بعبارات جديدة بالمعنى الثابت: خطأ.

ميزات جديدة ngUpgrade

حتى الآن ، كانت إحدى المشكلات في AngularJS 1.X و Angular المختلطة مع ngUpgrade هي أن أجهزة التوجيه في كلا الإطارين كانت تتنافس بسبب عنوان URL. هذا أدى إلى صعوبة في تفسير الآثار الجانبية. لتجنب ذلك ، تمت إضافة القدرة على استخدام خدمة موقع URL واحد في كلا الإصدارين.
للقيام بذلك ، قام فريق Angular بتوسيع قدرات خدمات الموقع Angular ، وبالتالي قدم بديلاً لموقع $ في AngularJS.
لهذا السبب ، تمت إضافة طريقة onUrlChange جديدة إلى خدمة الموقع لتتبع تغييرات عنوان URL:

 export class AppComponent { constructor(loc: Location, pLoc: PlatformLocation) { loc.onUrlChange((url) => console.debug('url change', url)); console.debug('hostname: ', pLoc.hostname); } } 

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

استنتاج

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

ملاحظة: هذه هي أول ترجمة لي ، لذا يرجى ملاحظة التعليقات والاقتراحات والأخطاء في التعليقات.