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

Mason Freed

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

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

أحداث الطفرة هي اسم المجموعة التالية من الأحداث:

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

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

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

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

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

بسبب هذه العيوب، تم إيقاف الأحداث نهائيًا من المواصفات في عام 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.

• https://github.com/mfreed7/mutation-events-polyfill#readme
• https://www.npmjs.com/package/mutation-events

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

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

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