الانتقال من AngularJS إلى Angular الحديث: ما الذي يتعطل وكيف تخططون للترحيل

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

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

ماذا يعني انتهاء دعم AngularJS فعليًا قبل ترحيله

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

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

لماذا لا يُعد AngularJS وAngular الإطار نفسه

التسمية مربكة فعلًا. يُعرف AngularJS، ويُسمى أيضًا Angular 1، بأنه إطار JavaScript مبني حول الربط الثنائي للبيانات ونظام حقن التبعيات الخاص به. أما Angular، بإصداراته من 2 فصاعدًا، فهو إعادة كتابة كاملة: بنية مختلفة، وTypeScript بحسب العرف بدلًا من JavaScript العادية، ونموذج مكونات لا يتطابق واحدًا لواحد مع وحدات التحكم والتوجيهات في AngularJS. لا يوجد مسار ترقية تلقائي من أحدهما إلى الآخر، ولهذا يُسمى الانتقال بينهما ترحيلًا بحق لا تحديثًا.

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

يشترك AngularJS وAngular في الاسم وقليل غير ذلك. خططوا للانتقال كترحيل، لا كترقية.

ما الذي يتعطل عادةً في ترحيل AngularJS

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

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

ترحيل AngularJS تدريجيًا بدلًا من إعادة كتابة كل شيء دفعة واحدة

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

الترتيب العملي لشركة في دبي هو ترحيل الشاشات المستقلة والأقل خطورة أولًا لإثبات النمط، ثم التوجه نحو المجالات التي تحمل أثقل منطق خاص بـ AngularJS، مثل التوجيهات المعقدة والخدمات المشتركة، بمجرد أن يكتسب الفريق إيقاعًا عمليًا. عادةً ما تستحق الخدمات المشتركة والتوجيه الترحيل مبكرًا حتى مع كونها أكثر خطورة، لأن تركها في AngularJS لأطول فترة يعني أن كل شاشة رُحِّلت حديثًا لا تزال مضطرة للتواصل مع كود قديم غير مدعوم تحتها.

1. تدقيق تطبيق AngularJS الحالي

   اسردوا كل توجيه وخدمة وتبعية خارجية مخصصة، وحدّدوا أيها لا بديل مدعوم له في Angular قبل الالتزام بجدول زمني.

2. إعداد البيئة الهجينة

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

3. الترحيل بحسب الخطورة والقيمة

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

4. إزالة AngularJS بمجرد ألا شيء يعتمد عليه

   تأكدوا من ألا مسار أو خدمة أو مكون ما زال يستدعي AngularJS قبل إزالته من البنية نهائيًا، لإغلاق التعرض الناتج عن الكود غير المدعوم نهائيًا.

اختبار ترحيل AngularJS إلى Angular بشكل صحيح

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

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

أخطاء شائعة في ترحيل AngularJS

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

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

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

كيف يمكن لـ Digital Marketing Dubai المساعدة

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

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