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

Mason Freed

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

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

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

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

هذه الأحداث هي جزء قديم جدًا من مواصفات DOM من المستوى 2، وقد تم إيقافها نهائيًا منذ عام 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

هناك 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 وBeta قبل ذلك بوقت قصير، وذلك كإجراء تحذيري مبكر.

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