أهمية Debounce وThrottle في واجهات المستخدم

تُطلَق بعض أحداث DOM بمعدلات عالية للغاية. يُطلَق حدث keypress مع كل ضغطة مفتاح. ويُطلَق حدث scroll عشرات المرات في الثانية أثناء التمرير. أما حدث resize فيُطلَق باستمرار أثناء سحب المستخدم لحافة النافذة. قد تؤدي معالجة كل حدث على حدة إلى إرهاق المتصفح والخادم معًا.

إذا كان معالج keypress يجري استدعاءً لواجهة API مع كل ضغطة مفتاح، فإن مستخدمًا يكتب "React hooks" (11 حرفًا) يطلق 11 طلبًا عبر الشبكة، معظمها لاستعلامات غير مكتملة. وبالمثل، يؤدي تحديث رسوم متحركة للمنظور ثلاثي الأبعاد مع كل بكسل أثناء التمرير إلى مئات عمليات إعادة التصيير في React كل ثانية. وهذا يهدر وحدة المعالجة المركزية والشبكة والبطارية.

يؤخر Debounce التنفيذ حتى يتوقف الحدث عن الإطلاق لمدة محددة. إذا استمر المستخدم في الكتابة، يُعاد ضبط المؤقت مع كل ضغطة مفتاح. ولا يُنفَّذ المعالج مرة واحدة إلا بعد مرور N من المللي ثانية من الصمت. يجيب Debounce عن السؤال: "شغّل هذا بعد أن ينتهي المستخدم من القيام بشيء ما."

يحدّ Throttle التنفيذ بحد أقصى مرة واحدة خلال فترة زمنية، بغض النظر عن عدد الأحداث التي تُطلَق. إذا مرّر المستخدم بسرعة، يضمن Throttle مضبوط على 100ms ألا يعمل المعالج أكثر من 10 مرات في الثانية. يجيب Throttle عن السؤال: "شغّل هذا بانتظام، ولكن ليس أكثر من مرة كل N من المللي ثانية."

يكون Debounce الخيار الصحيح عندما تهتم فقط بالقيمة النهائية بعد توقف المستخدم. ومن الحالات الشائعة: حقل البحث، حيث يُرسَل طلب API بعد توقف الكتابة؛ ومعالج تغيير حجم النافذة، حيث يُعاد حساب التخطيط بعد انتهاء تغيير الحجم؛ والتحقق من حقول النماذج الذي يفحص خادمًا، حيث ينبغي الانتظار حتى يكتمل الإدخال قبل التحقق.

يكون Throttle الخيار الصحيح عندما تريد تحديثات منتظمة أثناء نشاط مستمر. ومن الحالات الشائعة: معالج موضع التمرير لتحديث شريط تقدم القراءة أو رأس ثابت بحد أقصى 30fps؛ وتتبع حركة الفأرة لتسجيل موضع المؤشر لأغراض التحليلات؛ ومعالجات أحداث السحب لتحديث موضع عنصر قابل للسحب بسلاسة دون إغراق التطبيق بالأحداث.

تؤدي كتابة Debounce أو Throttle من الصفر دون فهم كامل إلى أخطاء مثل فقدان الحدث الأخير (الحافة اللاحقة)، أو الإطلاق عند حواف غير صحيحة، أو عدم تنظيف المؤقتات عند إلغاء تركيب المكوّن. يكون من الأفضل عمومًا استخدام تنفيذات مجرّبة جيدًا من مكتبات مثل lodash، إذ تتعامل مع جميع الحالات الطرفية على نحو صحيح.

توفر Lodash الدالتين _.debounce(fn, wait) و_.throttle(fn, wait) مع خيارات للتحكم في سلوك الحافة الأولى والحافة اللاحقة. وتمتلك الدالة المُعادة الأسلوب .cancel() لإلغاء استدعاء معلّق، والأسلوب .flush() لتنفيذه فورًا. ينبغي تغليف هاتين الدالتين باستخدام useRef في React لتجنب إعادة إنشائهما عند إعادة التصيير.

حتى 50 عملية إعادة تصيير إضافية في الثانية بسبب معالج تمرير غير مقيّد يمكن أن تستهلك قدرًا ملحوظًا من وحدة المعالجة المركزية، لا سيما على الأجهزة المحمولة منخفضة الإمكانات. وتعني ميزانية الإطار البالغة 16ms (60fps) أن كل عملية إعادة تصيير يجب أن تكتمل خلال أقل من 16 مللي ثانية لتجنب إسقاط الإطارات. يُعد Debounce وThrottle خط دفاعك الأول ضد مشكلات معدل الإطارات.

لا تحتاج جميع المعالجات عالية التواتر إلى Debounce. فإذا كان معالج الحدث يقرأ قيمة فقط دون تحديث الحالة أو استدعاء واجهات API — مثل تسجيل آخر موضع للفأرة في ref — فلا حاجة إلى Debounce. استخدم Debounce أو Throttle فقط مع المعالجات التي تطلق عمليات مكلفة، مثل تحديثات الحالة أو استدعاءات API أو قياسات DOM.

عند إلغاء تركيب مكوّن، ينبغي إلغاء أي استدعاء معلّق يستخدم Debounce لمنع تحديث الحالة بعد إلغاء التركيب. إذا استخدمت useRef لتخزين الدالة المؤجَّلة، فاستدعِ debouncedFn.cancel() في عملية التنظيف الخاصة بـ useEffect. توفر دوال Lodash التي تستخدم Debounce هذا الأسلوب لهذا الغرض تحديدًا.

أي تقنية ينبغي استخدامها لإطلاق استدعاء API عندما يتوقف المستخدم عن الكتابة في حقل بحث؟

قد تسبب الأحداث عالية التواتر، مثل keypress وscroll وresize، مشكلات في الأداء إذا نُفذت المعالجات مع كل حدث. ينتظر Debounce فترة الصمت، وهو الأنسب لحقول البحث ومعالجات تغيير الحجم. أما Throttle فيحدّ من التواتر، وهو الأنسب للتمرير والسحب. استخدم تنفيذات Lodash المخزّنة في المراجع، واحرص دائمًا على إلغائها عند إلغاء تركيب المكوّن.