ستتم إزالة أحداث التغيير من Chrome.

الإعلان عن الإيقاف النهائي والإزالة المخطَّط لها لأحداث التغيير، ومشاركة كيفية نقل الرموز البرمجية قبل الإزالة في تموز (يوليو) 2024

Mason Freed
Mason Freed

لقد أوقف Chromium أحداث التغيير نهائيًا رسميًا ونخطط لإزالة التوافق من الإصدار 127 الذي سيتم تطبيقه على الإصدار الثابت في 23 يوليو 2024. توضّح هذه المشاركة سبب إزالة أحداث التغيير، كما توفّر مسارًا لنقل البيانات قبل إزالتها من المتصفّح.

ما هي أحداث التغيُّر؟

وتكون أحداث التغيُّر هي اسم مجموعة الأحداث التالية:

  • DOMNodeInserted
  • DOMNodeRemoved
  • DOMSubtreeModified
  • DOMCharacterDataModified
  • DOMNodeInsertedIntoDocument
  • DOMNodeRemovedFromDocument
  • (غير متوافق مع أي متصفح حديث) DOMAttrModified
  • (غير متوافق مع أي متصفح حديث) DOMAttributeNameChanged
  • (غير متوافق مع أي متصفح حديث) DOMElementNameChanged

تُعدّ هذه الأحداث جزءًا قديمًا جدًا من مواصفات المستوى الثاني في نموذج العناصر في المستند (DOM)، وقد تم إيقافها نهائيًا منذ عام 2011. وقد تم استبدالها بـ واجهة MutationObserver التي متاحة في جميع المتصفحات الحديثة منذ عام 2013.

سجلّ أحداث التغيُّر

بدت أحداث التغيُّر كفكرة جيدة منذ فترة طويلة، ولكن اتضح أنّ هناك بعض العيوب الفادحة:

  • فهي تكون مطولة وتطلق نار كثيرًا. يتم تنشيط حدث لكل عقدة تتم إزالتها.
  • تُعد عمليات التحسين هذه بطيئة بسبب نشر الأحداث وتمنع العديد من عمليات التحسين في وقت تشغيل Universal Analytics.
  • غالبًا ما تتسبب في حدوث أعطال. وقد تسببت في حدوث العديد من الأعطال وأخطاء الأمان في المتصفحات، نظرًا لأن أدوات معالجة الأحداث يمكنها تغيير نموذج كائن المستند (DOM) بالكامل ضمن عملية قيد التشغيل في نموذج العناصر في المستند (DOM).

وبسبب هذه العيوب، تم إيقاف الأحداث وفقًا للمواصفات في عام 2011 وإنشاء واجهة برمجة تطبيقات (MutationObserver) بديلة في عام 2012. وقد تم تنفيذ واجهة برمجة التطبيقات الجديدة وهي تعمل منذ أكثر من 10 سنوات.

سبب إزالة أحداث التغيُّر

يختلف دعم أحداث التغيُّر باختلاف المتصفِّحات. بعض الأحداث، مثل DOMNodeInsertedIntoDocument وDOMNodeRemovedFromDocument، غير متاحة في بعض المتصفّحات. وبالنسبة إلى الأحداث الأخرى، سيختلف السلوك المعيّن بسبب عدم توفّر أي مواصفات متفق عليها. ومع ذلك، قد يكون هناك سؤال منطقي: لمَ لا نتركها هناك، بما أنها "منجزة" وتؤدي إلى إبطاء الصفحات التي تستخدمها فقط؟ تأتي الإجابة في جزأين.

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

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

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

كيفية نقل البيانات

استخدام MutationObserver كبديل

تتوفر وثائق MutationObserver على MDN، وهي كاملة إلى حد ما. يعتمد استبدال قاعدة الرموز على كيفية استخدام هذه الأحداث، ولكن كمثال:

// Old mutation event usage:  
target.addEventListener('DOMNodeInserted',event => doSomething(event.target));

// Replacement mutation observer code:  
const observer = new MutationObserver(mutationList =>  
  mutationList.filter(m => m.type === 'childList').forEach(m => {  
    m.addedNodes.forEach(doSomething);  
  }));  
observer.observe(target,{childList: true, subtree: true});  

مع أنّ رمز MutationObserver يظهر بحجم أكبر من رمز معالجة الحدث الأصلي من DOMNodeInserted، لاحِظ أنّه يمكنه معالجة جميع التغييرات التي تحدث على شجرة كاملة في استدعاء واحد، بدلاً من طلب عمليات استدعاء متعدّدة لمعالِج الحدث.

الملء التلقائي

هناك رمز polyfill يحاول السماح بمواصلة عمل الرمز البرمجي الحالي مع تشغيله من خلال MutationObserver. توجد دالة polyfill على GitHub أو كحزمة npm.

معلومات عن الفترة التجريبية للإيقاف النهائي والمخطط الزمني

ستتم إزالة أحداث التغيُّر من الإصدار Chrome 127 لجميع المستخدمين* وسيتم نقل هذه الأحداث إلى الإصدار الثابت في 23 يوليو 2024. ستبدأ إزالة الفعاليات من قنوات إصدار Canary وDev والقناة التجريبية قبل ذلك التاريخ، كتحذير مبكر.

  • إذا كنت بحاجة إلى وقت إضافي (بعد تموز/يوليو 2024) لنقل بيانات الرموز الخاصة بك، نقدّم لك فترة تجريبية للإيقاف تُعيد تفعيل الأحداث مؤقتًا على مواقع إلكترونية محدّدة. هناك أيضًا سياسة Enterprise تُسمى MutationEventsEnabled وتعمل بطريقة مماثلة لمستخدمي الإصدار الخاص بالمؤسسات. ويمنح أي من هذين الخيارين فترة تسعة أشهر تقريبًا من الوقت الإضافي لإجراء عملية النقل، إذا لزم الأمر.