تطبيقات عملية: البحث والتمرير وتغيير الحجم

في مكوّن البحث الفوري، احتفظ بمتغيري حالة منفصلين: inputValue للإدخال الخام، وهو يتحدّث مع كل ضغطة مفتاح ويحافظ على استجابة حقل الإدخال، وdebouncedQuery الناتج من useDebounce(inputValue, 300)، وهو يتحدّث بعد 300ms من توقف الكتابة ويُطلق استدعاء API. يوفّر هذا الفصل تغذية مرئية فورية دون إرسال عدد مفرط من الطلبات.

اعرض مؤشر تحميل بمجرد أن يبدأ المستخدم بالكتابة، وليس فقط عند بدء استدعاء API. عيّن isLoading: true كلما كان inputValue !== debouncedQuery — إذ تكون القيمتان غير متزامنتين أثناء انتظار debounce. بعد استقرار الاستعلام واكتمال fetch، أعد القيمة إلى false. وهكذا يرى المستخدمون مؤشر تحميل متجاوبًا طوال العملية.

يتحدّث تأثير parallax أو شريط تقدّم القراءة استنادًا إلى موضع التمرير. حدّد معدل معالج التمرير بحد أقصى 60 إطارًا في الثانية باستخدام تأخير قدره 16ms: const throttledScrollY = useThrottle(scrollY, 16). تتحدّث واجهة المستخدم بسلاسة دون كلفة إعادة حساب الموضع مع كل بكسل من التمرير.

من الأفضل استخدام debounce، لا throttle، عند الاستماع إلى تغيير حجم النافذة لإعادة حساب التخطيط. فلا يلزم تشغيل حساب التخطيط إلا مرة واحدة بعد انتهاء المستخدم من تغيير الحجم. استخدم debounce بقيمة 200ms لأبعاد النافذة. أثناء سحب المستخدم لتغيير الحجم، يمكن لواجهة المستخدم عرض حالة مبسطة، ثم يظهر التخطيط المعاد حسابه عند توقف تغيير الحجم.

عند تغيّر debouncedQuery، أنشئ AbortController جديدًا ومرّر قيمة signal الخاصة به إلى fetch(url, { signal }). أعد دالة تنظيف تستدعي controller.abort(). يؤدي ذلك إلى إلغاء أي طلب سابق قيد التنفيذ عند وصول استعلام مؤجّل جديد، ويمنع حالات السباق التي يستبدل فيها رد بطيء من الاستعلام السابق ردًا أسرع من الاستعلام اللاحق.

من دون AbortController، إذا كتب المستخدم "re" وانتظر، ثم كتب "react"، فقد يصل الاستعلام الثاني قبل الأول بسبب التخزين المؤقت. ستعرض نتائج البحث مؤقتًا نتائج React، ثم تُستبدل بنتائج "re" القديمة. يمنع AbortController ذلك بإلغاء الطلب السابق بالكامل.

تجمع القائمة المنسدلة بين debounce لاستدعاءات API وحالة فورية لعرض الإدخال. يتحكم inputValue في النص الظاهر داخل حقل الإدخال. وتحدد useDebounce(inputValue, 250) وقت إطلاق جلب الاقتراحات. وتُعرض قائمة الاقتراحات من حالة نتائج الجلب، وهي منفصلة عن حالتي الإدخال كلتيهما.

ينبغي استخدام debounce للتحقق غير المتزامن من النموذج، مثل التحقق مما إذا كان البريد الإلكتروني موجودًا مسبقًا، لتجنب إرهاق الخادم بطلب عند كل ضغطة مفتاح. استخدم debounce بقيمة 400ms لقيمة الحقل، وأطلق طلب التحقق داخل useEffect يعتمد على القيمة المؤجّلة. اعرض مؤشر تحميل في الحقل أثناء انتظار التحقق.

يُعد Debounce مناسبًا جدًا لحفظ محتوى النموذج تلقائيًا أثناء كتابة المستخدم. عيّن debounce بقيمة 1000ms لكائن قيم النموذج. عند تغيّر القيمة المؤجّلة، أطلق عملية حفظ إلى localStorage أو إلى نقطة نهاية في API. سيرى المستخدم مؤشر "Saving..." أثناء انتظار debounce، ثم "Saved" عند اكتمال الطلب.

تُعد قيم التأخير قرارات مرتبطة بتجربة المستخدم. بالنسبة إلى البحث، يوازن 200-300ms بين سرعة الاستجابة وتقليل عدد الطلبات. وبالنسبة إلى تغيير الحجم، يُعد 150-200ms مقبولًا لأن المستخدمين يتوقعون استقرار التخطيط بعد الانتهاء من تغيير الحجم. أما الحفظ التلقائي، فتمنح قيمة 1000ms المستخدم وقتًا لكتابة جملة قبل الحفظ. اضبط القيمة وفق سرعة التفاعل المتوقعة.

غالبًا ما تحتاج التطبيقات الفعلية إلى عدة تحسينات في الوقت نفسه. فقد يستخدم محرر المستندات debounce للحفظ التلقائي (1s)، وthrottle لحساب عدد الكلمات (500ms)، وIntersectionObserver للتحليلات. تتكامل هذه التقنيات جيدًا لأن كل واحدة منها تعمل بشكل مستقل وفق مؤقتها ونطاقها.

لماذا ينبغي استخدام AbortController مع استعلام بحث يستخدم debounce؟

استخدم useDebounce لحقول البحث ومعالجات تغيير الحجم والحفظ التلقائي للنماذج. واستخدم useThrottle للتمرير وحركة الفأرة. احرص دائمًا على دمج استدعاءات API المؤجّلة مع AbortController لمنع حالات السباق. اعرض حالة التحميل كلما كان inputValue !== debouncedQuery للحفاظ على استجابة واجهة المستخدم وإفادتها للمستخدم.