مرحبا يا هبر!اليوم أردت أن أتطرق إلى موضوع الشفرة الصحيحة في العمل مع Angular. ستجعل هذه التوصيات التعليمات البرمجية الخاصة بك أكثر فعالية في الممارسة العملية ، كما ستسمح لي بأن أكون أقل تطلبًا على التعليمات البرمجية الصغيرة.
1. تجنب المنطق في الأنماط
وأول شيء أود أن أذكره هو المنطق في القوالب. إذا كان لديك نوع من المنطق في قوالبك ، حتى لو كان بسيطًا && ، فمن المفيد استخراجه في المكون الخاص بك. يعني وجود المنطق في القالب أنه من المستحيل اختباره ، وبالتالي فهو أكثر عرضة للأخطاء عند تغيير رمز القالب.
<p *ngIf="isShow"> Example </p>
public ngOnInit(): void { this.isShow = true; }
2. خطوط "آمنة"
افترض أن لديك متغيرًا من سلسلة النوع التي لا يمكن أن تحتوي إلا على مجموعة محددة من القيم. بدلاً من الإعلان عن ذلك على أنه نوع من السلاسل ، يمكنك إعلان قائمة القيم المحتملة هذه كنوع.
private value: 'One' | 'Two'; if (isShow) { value = 'One'; } else { value = 'Two' }
من خلال الإعلان عن نوع المتغير بهذه الطريقة ، يمكننا تجنب الأخطاء عند كتابة التعليمات البرمجية في وقت الترجمة ، بدلاً من وقت التشغيل.
3. حكم الطرق الطويلة
فيما يلي عرض توضيحي للرمز زائدة عن الحاجة. من المهم أن نفهم أنه لا أحد يحب الأساليب الطويلة.
عادةً ما تشير الطرق الطويلة إلى أنها تفعل الكثير من الأشياء. ربما تؤدي الطريقة نفسها شيئًا واحدًا ، ولكن يوجد بداخلها العديد من العمليات الأخرى التي يمكن وضعها في طريقة أخرى خاصة بها ، متابعة غرضها المنطقي. من الصعب قراءة وفهم وصيانة الطرق الطويلة. كما أنها عرضة للخطأ ، لأن تغيير شيء واحد يمكن أن يؤثر على أشياء أخرى كثيرة في هذه الطريقة. أنا متأكد ، ليس بالنسبة لي وحدي ، أن مثل هذه الأساليب تجعل إعادة البناء (وهو المفتاح في أي تطبيق) أكثر صعوبة مما يمكن أن يكون.
4. تكرار القانون
إذا كان لديك رمز يتكرر في أماكن مختلفة في المشروع. استخرج الكود المكرر في طريقة منفصلة واستخدمه بدلاً من الكود المكرر.
تكمن المشكلة في تكرار التعليمات البرمجية في أننا إذا أردنا إجراء تغييرات على منطق هذا الرمز ، فعلينا القيام بذلك في عدة أماكن. وهذا يجعل من الصعب الحفاظ على التعليمات البرمجية ، مما يزيد بدوره من خطر ظهور الأخطاء. يستغرق الأمر أيضًا وقتًا أطول لإجراء تغييرات على المنطق. مع رمز أقل تكرارًا ، سيكون التطبيق أسرع.
5. تراكبي
دعونا نقوم بتخفيف قائمة التفاصيل الدقيقة للعمل مع Angular.
غالبًا ما تستخدم من قبل ngFor للتكرار عبر مصفوفة في القوالب ، غالبًا ما يتم حرمانها عمليًا من وظيفة مثل trackBy. استخدامه في العمل مع ngFor. بفضل مثل هذه التفاهات ، ستحصل على معرف فريد لكل عنصر.
<li *ngFor="let item of items; trackBy: trackByFn">{{ item }}</li>
trackByFn(index, item) { return item.id;
عندما يتغير الصفيف ، يعيد Angular عرض شجرة DOM بأكملها. ولكن إذا كنت تستخدم trackBy ، فستعرف Angular أي عنصر قد تغير وستغير DOM فقط لهذا العنصر المعين.
6. اشترك في القالب
انتبه إلى مثال الاشتراك في المكون المرصود:
<p>{{ text }}</p>
blablaObservable .pipe( map(value => value.item), takeUntil(this._destroyed$) ) .subscribe(item => this.text = item);
لقد رأيت الآن كيف لا تفعل ذلك. ليس الأمر أنني حثتك على اتباع توصياتي بدقة ، بل إن المطورين غالبًا لا يتطرقون إلى ما يحدث في شفرتهم. فلماذا هي سيئة وكيف تعمل بشكل جيد؟ والحقيقة هي أننا نواجه خطر إلغاء الاشتراك عن طريق الخطأ من الاشتراك في أحد المكونات ، مما قد يؤدي إلى تسرب للذاكرة. الخيار الأفضل هو استخدام اشتراك في القالب نفسه:
<p>{{ text$ | async }}</p>
this.text$ = blablaObservable .pipe( map(value => value.item) );
بفضل التزامن ، لا داعي للقلق بشأن إلغاء الاشتراك ، لأنه يقوم بذلك تلقائيًا ، وهذا يبسط الرمز ، مما يلغي الحاجة إلى إدارة الاشتراكات يدويًا. كما أنه يقلل من خطر إلغاء الاشتراك عن طريق الخطأ من المكون الذي ذكرته أعلاه.
7. تحميل كسول
كلما أمكن ، استخدم تحميل الوحدة البطيئة في تطبيق Angular الخاص بك. التحميل البطيء هو عندما تقوم بتنزيل شيء فقط عند استخدامه ، على سبيل المثال ، تحميل مكون فقط عندما تحتاج إلى رؤيته. سيؤدي هذا إلى تقليل حجم التطبيق القابل للتنزيل ويمكن أن يحسن وقت تحميل التطبيق دون تحميل وحدات غير مستخدمة.
// app.routing.ts
{ path: 'dashboard', loadChildren: 'lazy-load.module#DashboardModule' }
8. الاشتراك داخل الاشتراك
في بعض الأحيان قد تحتاج إلى قيم من أكثر من واحد يمكن ملاحظته لإكمال الإجراء. في هذه الحالة ، تجنب الاشتراك في واحد قابل للملاحظة في كتلة الاشتراك في آخر قابل للملاحظة. بدلاً من ذلك ، استخدم عوامل التسلسل المناسبة. يتم تشغيل عبارات السلاسل على ملاحظات من البيان الموجود أمامهم. بعض مشغلي السلسلة ، مثل withLatestFrom ، و combineLatest ، إلخ ...
إلى:
oneObservable$.pipe( take(1) ) .subscribe(oneValue => { twoObservable$.pipe( take(1) ) .subscribe(twoValue => { console.log([oneValue, twoValue].join(', ')); }); });
بعد:
oneObservable$.pipe( withLatestFrom(twoObservable$), first() ) .subscribe(([oneValue, twoValue]) => { console.log([oneValue, twoValue].join(', ')); });
9. التخزين المؤقت
عند تقديم طلبات إلى API ، غالبًا لا تتغير الاستجابات من بعضها. في هذه الحالات ، يمكنك إضافة آلية التخزين المؤقت وحفظ القيمة من API. عندما يجب تكرار الطلب إلى نفس واجهة برمجة التطبيقات ، تحقق مما إذا كان له قيمة في ذاكرة التخزين المؤقت ، وإذا كان الأمر كذلك ، فاستخدمه. بخلاف ذلك ، قم بإجراء مكالمة API وتخزين النتيجة مؤقتًا. إذا لزم الأمر ، يمكنك إدخال وقت ذاكرة التخزين المؤقت ، حيث يمكنك التحقق عندما كانت المرة الأخيرة ، وتحديد ما إذا كنت تريد الاتصال بواجهة برمجة التطبيقات. يؤدي وجود آلية للتخزين المؤقت إلى تجنب طلبات واجهة برمجة التطبيقات غير المرغوب فيها. بسبب هذا التجنب للطلبات المكررة ، تتحسن سرعة التطبيق ، حيث لا نحتاج إلى انتظار الرد وبالتالي تنزيل نفس المعلومات مرارًا وتكرارًا.
10. التكسير إلى مكونات قابلة لإعادة الاستخدام
قسم المكونات الكبيرة إلى مكونات أصغر. تبسيط هذه المكونات وجعلها غبية قدر الإمكان ، لأن هذا سيجعلها تعمل في المزيد من السيناريوهات. إن إنشاء مثل هذا المكون يعني أن المكون ليس لديه أي منطق خاص في حد ذاته ويعمل فقط على أساس المدخلات والمخرجات المقدمة إليه. عادةً ما يكون آخر سليل في شجرة المكونات هو الأبسط على الإطلاق. يتم ذلك استنادًا إلى سهولة استخدام هذه المكونات ، فهذه المكونات أقل احتمالًا للحصول على أخطاء. تقلل المكونات القابلة لإعادة الاستخدام أيضًا من تكرار التعليمات البرمجية ، مما يجعل من السهل الحفاظ عليها وإجراء التغييرات.
هل ترغب في متابعة هذا العمود؟