🎁 ⛏️ 🤵🏾 6 مفاهيم يحتاجها مهندس التطبيق الزاوي لإتقان 🕺🏼 👶🏽 🧘🏿

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

1. العمارة والوحدات والمكتبات

في عالم تطوير الويب ، تعد هندسة وحدات Angular شيئًا مميزًا. ربما ، هذه واحدة من تلك الأفكار التي هي أسوأ من الأفكار الأخرى التي يتبناها المبتدئون.

الجزء الأصعب هنا هو أن تطوير الويب يستخدم بالفعل بنية معيارية. بالطبع ، أنا أتحدث عن واردات ES6.

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

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

types أنواع مختلفة من الوحدات الزاوية

هناك أنواع مختلفة من الوحدات الزاوية التي يجب الانتباه إليها:

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

إليك المواد التي يمكنك أن تجد فيها تفاصيل حول الوحدات الزاويّة.

▍ مكتبة أو وحدة؟

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

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

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

إليك بعض الأسئلة التي يجب طرحها قبل كتابة وحدة نمطية:

? — , . , . , .
, ? . , , . , , .

2. ,

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

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

▍ شرط

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

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

with العمل مع DOM

ربما يجب أن تتم معظم التلاعبات DOM في التوجيهات. تخيل أن أحد المكونات مزود بوظيفة السحب والإفلات.

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

وصف مظهر المكون.
تحديد سلوك المكون.

التوجيهات هي ميزة زاوية تتيح لك وصف الآليات القابلة لإعادة الاستخدام. في كل مشروع عملت عليه تقريبًا ، لاحظت عدم كفاية استخدام التوجيهات. يمكن أن تأخذ التوجيهات حصة كبيرة من مسؤولية المكونات.

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

3. تغيير الكشف والعرض

عندما يتعلق الأمر بإعادة عرض واجهة المستخدم ، يتم عمل كل شيء في Angular كما لو كان بالسحر ، باستخدام الآليات الداخلية للإطار.

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

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

detection تحسين الكشف عن التغيير

من أجل تحسين عملية الكشف عن التغيير المستخدمة في المشروع ، فمن المنطقي أن تبدأ بالأفكار التالية:

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

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

coming التغلب على قيود الأداء الزاوي

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

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

4. التوجيه

التوجيه ليس مجرد تمثيل لـ SPA في شكل العديد من الصفحات الافتراضية. كما أنه يقوم بتحميل حزم التطبيقات عند الطلب باستخدام إمكانات التحميل البطيئة لمواد نظام التوجيه الفرعي الزاوي.

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

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

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

▍ مثال: مكون مبوب

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

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

إذا كنت تريد شيئًا مستوحى قبل تطبيق هذه الأفكار ، أقترح إلقاء نظرة على وثائق مكون @ angular / material / tabs ، الذي ينفذ النمط أعلاه.

5. النماذج

تتكون معظم تطبيقات CRUD بشكل أساسي من العديد من الأشكال. من المحتمل جدًا أنك تقضي الكثير من الوقت في إنشاء النماذج. لذلك ، من المهم لمن يريد أن يكون مهندسًا زاويًا أن يتقن العمل مع النماذج بشكل صحيح.

من المرجح أن تستخدم معظم النماذج الخاصة بك وحدة نمطية ReactiveFormsModule. وإذا لم تتكون من عنصر تحكم واحد ، فعندئذٍ سيتم استخدامها ngModelلربط البيانات في اتجاهين.

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

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

6. RxJS

والأخير في قائمتنا ، على الرغم من أنه ليس الأقل ، هو تقنية RxJS.

أنا مقتنع بأن إحدى أقوى ميزات Angular هي التكامل العميق لهذا الإطار مع Rx والبرمجة التفاعلية الوظيفية.

من أجل إتقان Angular حقًا ، مما يمهد الطريق لتصميم تطبيقات عالية الجودة ، تحتاج أولاً إلى دراسة Rx ، أو على الأقل أهم العوامل. من الصعب أن تكون مطورًا زاويًا متقدمًا حقًا دون قضاء الكثير من الساعات في فهم Rx.

هناك سببان لتعلم Rx لمساعدتك في تطوير تطبيقات Angular: الأداء ومعالجة البيانات غير المتزامنة.

تعتبر معالجة البيانات غير المتزامنة مهمة صعبة بشكل خاص في التطبيقات الحديثة شديدة التفاعل. لذلك ، يجب عليك نسيان الوعود ، أوه setTimeoutويا setInterval، والبدء في العمل بأسلوب Rx.

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

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

ملخص

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

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

وماذا تنصح بالدراسة لأولئك الذين يرغبون في تعلم كيفية تصميم تطبيقات Angular عالية الجودة؟

6 مفاهيم يحتاجها مهندس التطبيق الزاوي لإتقان