يسرّنا الإعلان عن واجهة برمجة التطبيقات الجديدة moveBefore() DOM API، المتوفّرة في الإصدار 133 من Chrome، والتي تسهّل نقل العناصر في DOM بدون فقدان الحالة. تابِع القراءة لمعرفة كيفية استخدامها في مشاريعك.
فقدان الحالة أثناء عمليات تغيير DOM
هل تستخدِم واجهة برمجة التطبيقات appendChild() لإدراج عناصر جديدة في DOM؟ يفعل الكثيرون ذلك، ولكن هل حاولت من قبل استدعاء هذه الواجهة أو insertBefore() أو أي واجهة برمجة تطبيقات أخرى لإدراج المحتوى باستخدام عنصر متوفّر في DOM؟ إذا كان الأمر كذلك، من المحتمل أنّك لم تلاحظ أنّ هذا الإجراء يتم بشكلٍ هادئ من خلال إزالة العنصر أولاً من العنصر الرئيسي القديم وإعادة إدراجه في العنصر الرئيسي الجديد. ويعود السبب في ذلك إلى أنّ نموذج تمثيل المستندات لم يتضمّن سوى العنصرَين الأساسيَين remove وinsert منذ تقديم أول مسودة لـ DOM Standard في عام 1998. عندما تعتقد أنّك "تنقل" عنصرًا في DOM من مكان إلى آخر، تكون في الواقع تزيله وتُدرجه.
لا يؤثر عادةً في تجربة المستخدم أنّ "نقل" الملفات هو في الواقع "إزالتها وإدراجها". على سبيل المثال، عند "نقل" <p> في DOM، لا تترتّب عن هاتين العمليتين أيّ تأثيرات جانبية مزعجة، ولكن عند نقل العقد المعقدة التي تحتوي على حالة مهمة، مثل عناصر <iframe> والعناصر المعروضة بملء الشاشة والصور المتحركة في CSS وما إلى ذلك، تؤدي عملية "الإزالة" الضمنية إلى إعادة ضبط جميع أنواع الحالات.
ويمكن أن يكون لهذا الإجراء تأثيرات جانبية مفاجئة.
يمكنك الاطّلاع على نوع الحالة التي تتم إعادة ضبطها في الموقع الإلكتروني التجريبي الذي يحافظ على الحالة من خلال إجراء تغييرات في شجرة DOM. يعرض المثال التالي الصور المتحركة في CSS وإعادة ضبط حالة <iframe> عند نقل العناصر من حاوية رئيسية إلى أخرى.
يمكن أن يجعل هذا القيد إنشاء تجارب ديناميكية للمستخدمين أمرًا صعبًا أو حتى مستحيلًا. يشعر المستخدمون بالضيق والارتباك عندما تتم إعادة ضبط حالة التطبيق بشكل غامض، ويتحمل مؤلفو إطار عمل JavaScript العبء الأكبر من ذلك من خلال قضاء ساعات لا حصر لها في إعادة تصميم رمز الواجهة الأمامية لهذه المشكلة، أو إنشاء مكتبات معقّدة مثل MorphDOM، أو من خلال تلقّي تقارير أخطاء تسلّط الضوء على المشاكل التي لا يمكنهم حلّها.
واجهة برمجة التطبيقات الجديدة moveBefore()
سعينا إلى حلّ هذه المشكلة من خلال إضافة عملية أساسية جديدة إلى DOM. ويُطلق عليه بشكل مناسب اسم العنصر الأساسي "move"، ويتم عرضه للمطوّرين من خلال واجهة برمجة التطبيقات الجديدة moveBefore() DOM API.
تأخذ دالة moveBefore() الوسيطات نفسها التي تأخذها دالة insertBefore()، ولكن بدلاً من إزالة العقد وإعادة إدراجها عندما تكون مرتبطة بـ DOM، تعمل واجهة برمجة التطبيقات الجديدة هذه على نقل العقدة المستهدَفة إلى العنصر الرئيسي الجديد بدون إعادة ضبط معظم الحالات. يتيح ذلك أخيرًا لمطوّري JavaScript إنشاء تجارب ديناميكية باستخدام صور متحركة قابلة للتحريك وإطارات iframe وعناصر ملء الشاشة وغير ذلك. يمكنك تجربة هذه الميزة بنفسك من خلال تفعيل العلامة التجريبية chrome://flags/#atomic-move وزيارة موقعنا الإلكتروني التجريبي، أو باستخدام الإصدار 133 من Chrome بعد طرحه في 4 شباط (فبراير) 2025.
في ما يلي أمثلة على السلوكيات التي ستسمح هذه العنصر الأساسي الجديد لمؤلفي JavaScript بتحقيقها:
- الحفاظ على حالة تشغيل الفيديو أثناء تنقّل المستخدم في موقع إلكتروني (سواء كان الفيديو متوفرًا من عنصر
<video>أو<iframe>) - الحفاظ على تركيز حقل إدخال المستخدم أثناء نقله في نموذج DOM
- اسمح للرسومات المتحركة بالانتهاء بسلاسة عند إضافة محتوى جديد أو إزالته من نموذج DOM.
- خوارزميات تحويل بدرجة أعلى من الدقة لمواءمة مخطّطات DOM الحالية مع المحتوى الجديد
- يجب إبقاء مربّعات الحوار والنوافذ المنبثقة والعناصر التي تظهر على ملء الشاشة مفتوحة.
نحن نعمل جاهدين على توفير واجهة برمجة التطبيقات هذه لمنصّة الويب مع المتصفّحات الأخرى، ويسعدنا أن نوفّرها للمطوّرين قريبًا، ما يلبي طلبات المطوّرين التي تم تقديمها على مدار سنوات ويسدّ فجوة كبيرة في منصّة الويب.
وكما هو الحال دائمًا، يُرجى إخبارنا برأيك على Twitter أو في التعليقات أدناه وإرسال الأخطاء إلى crbug.com/new.