تجنّب اضطراب التخطيط والوميض المرئي

يحدث Layout Thrash عندما تتناوب JavaScript بين قراءة خصائص DOM والكتابة إلى DOM ضمن حلقة. فكل قراءة بعد عملية كتابة تجبر المتصفح على إعادة حساب التخطيط بشكل متزامن لإعادة قيمة دقيقة. وقد يحوّل ذلك ما يفترض أن يكون عملية حساب تخطيط واحدة إلى عشرات العمليات، مما يضر بالأداء بشدة.

يجمع React كل استدعاءات setState داخل معالجات الأحداث والتأثيرات في إعادة تصيير واحدة. ويمنع هذا التجميع الطبيعي نمط القراءة-الكتابة-القراءة الذي يسبب Layout Thrash ضمن دورة تصيير واحدة. وفي React 18، يمتد التجميع أيضًا إلى عمليات الاستدعاء غير المتزامنة وPromises، مما يقلل Layout Thrash الناتج عن تحديثات الحالة المتزامنة.

يحدث الوميض عندما يقرأ useEffect DOM، ثم يحدّث الحالة، مما يؤدي إلى إعادة التصيير، فيرسم المتصفح مرتين: مرة بالحالة الأولية ومرة بالحالة المصححة. يظهر الرسم الأول للحظات قبل استبداله. ويكون ذلك أوضح ما يكون في التأثيرات التي تعدّل خصائص التخطيط مثل الارتفاع أو العرض أو الموضع.

افتحوا Chrome DevTools، وانتقلوا إلى تبويب Rendering عبر قائمة النقاط الثلاث ضمن More tools، ثم فعّلوا «Paint flashing». ستُبرز مناطق إعادة الرسم باللون الأخضر. إذا رأيتم مكوّناً يومض عند التصيير الأول ثم يُعاد رسمه فوراً بتخطيط مختلف، فهذا يؤكد حدوث رسم مزدوج بسبب تحديث حالة تقوده useEffect.

انقلوا قراءات DOM وتحديثات الحالة الناتجة عنها من useEffect إلى useLayoutEffect. يحدث القياس نفسه وتحديث الحالة الآن بشكل متزامن قبل الرسم، ثم يعيد React التصيير ويثبّت التغييرات ضمن الكتلة نفسها، فلا يرسم المتصفح إلا الحالة النهائية الصحيحة. ويختفي الوميض الأخضر في DevTools.

نمط تجنّب الوميض هو: قراءة DOM داخل useLayoutEffect، واستدعاء setState بالقياس، ثم يعيد React التصيير بشكل متزامن، ويثبّت DOM المصحح، ويرسم المتصفح مرة واحدة بالنتيجة النهائية. وهذا هو النمط القياسي لتحديد مواضع التلميحات، وإزاحات الرؤوس اللاصقة، وإعداد الرسوم المتحركة.

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

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

للدالتين التوقيع نفسه: useLayoutEffect(callback, deps) مقابل useEffect(callback, deps). والاختلاف الوحيد هو توقيت تنفيذ الدالة. يمكنكم التبديل بينهما بتغيير كلمة واحدة في الشيفرة. ابدؤوا باستخدام useEffect، ولا تغيّروه إلى useLayoutEffect إلا بعد التأكد من حدوث الوميض.

من الصحيح والشائع استخدام الدالتين معاً في المكوّن نفسه لمعالجة اهتمامات مختلفة. فعلى سبيل المثال، قد يستخدم مكوّن مخطط useLayoutEffect لقياس عرض الحاوية وتعيين SVG viewBox بشكل متزامن، ثم يستخدم useEffect لجلب بيانات المخطط بشكل غير متزامن. تتولى كل دالة الاهتمام الذي يكون التوقيت مهماً بالنسبة إليه.

إلى جانب وميض الرسم في DevTools، يمكنكم إضافة عدّاد إلى وحدة التحكم داخل المكوّن لعدّ عمليات التصيير. إذا سجّل مكوّن كلمة «render» مرتين عند التركيب الأول، مرة بالحالة الأولية ومرة بالقياس المصحح، فهذه حالة رسم مزدوج. من المفترض أن يؤدي نقل القياس إلى useLayoutEffect إلى تقليل ذلك إلى تسجيل تصيير واحد بعد التركيب، مع استثناء التكرار الذي يضيفه Strict Mode.

ما السيناريو الذي يبرّر استخدام useLayoutEffect بدلاً من useEffect؟

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