متى يعمل useLayoutEffect مقارنةً بـ useEffect

يُنفَّذ useLayoutEffect بشكل متزامن فورًا بعد أن يطبّق React تعديلات DOM، ولكن قبل أن تتاح للمتصفح فرصة رسم هذه التغييرات. ومن منظور المتصفح، يشكّل تأثير التخطيط وتعديلات DOM كتلة عمل متزامنة واحدة متصلة.

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

يمكنك التحقق من الفرق في التوقيت بتسجيل الطوابع الزمنية في كلا التأثيرين: أضف console.log('layout', Date.now()) داخل useLayoutEffect، وأضف console.log('passive', Date.now()) داخل useEffect. في وحدة التحكم، سيكون الطابع الزمني لتأثير التخطيط أسبق دائمًا من الطابع الزمني للتأثير السلبي، مما يؤكد ترتيب التنفيذ.

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

إذا استدعيت setState داخل useLayoutEffect، ينفّذ React فورًا دورة تصيير واعتماد أخرى قبل الرسم. ولا يرسم المتصفح سوى النتيجة النهائية؛ لذلك لا يرى المستخدم الحالة الوسيطة أبدًا. وهذه هي حالة الاستخدام الأساسية لـ useLayoutEffect: قياس DOM، وحساب قيمة جديدة، وتعيين الحالة، وضمان رسم واحد سليم.

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

في React Strict Mode، وفي بيئة التطوير فقط، يُستدعى كل من useLayoutEffect وuseEffect مرتين لكل عملية تركيب. ويكون التسلسل كالتالي: تركيب، وتنظيف، ثم تركيب من جديد. ويساعد ذلك على اكتشاف التأثيرات التي لا تُنظَّف بشكل صحيح. ولا يحدث الاستدعاء المزدوج في إصدارات الإنتاج.

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

لا يمكن تشغيل useLayoutEffect على الخادم، لعدم وجود DOM أو دورة رسم للمتصفح في بيئة الخادم. وإذا استُخدم داخل مكوّن يُصيَّر على الخادم، يصدر React تحذيرًا. والحل هو تخطي التأثير بشكل مشروط: التحقق من typeof window !== 'undefined'، أو التبديل إلى useEffect في الشيفرة المتوافقة مع SSR.

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

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

متى يُنفَّذ useLayoutEffect تحديدًا بالنسبة إلى تعديلات DOM ورسم المتصفح؟

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