نمط الاستطلاع الطويل ومنطق إعادة الاتصال

يعمل الاستطلاع الطويل في دورة متكررة: يرسل العميل طلب HTTP، ويبقي الخادم الاتصال مفتوحًا حتى تتوفر بيانات جديدة (أو تنتهي مهلة، عادةً من 30 إلى 60 ثانية)، ثم يرسل الخادم استجابة بالبيانات، ويرسل العميل طلبًا آخر فورًا. وينشئ ذلك اتصالًا شبه مستمر بخصائص تشبه دفع البيانات من الخادم.

يستخدم الاستطلاع الطويل في React دالة غير متزامنة استدعائية تكراريًا داخل useEffect. تنفذ الدالة طلب fetch، وتعالج الاستجابة، ثم تستدعي نفسها مجددًا. وتوقف إشارة AbortController التكرار عند إزالة المكوّن. وتستمر الدالة في التكرار ما دام المكوّن مركبًا ولم تتم الإشارة إلى الإلغاء.

أنشئوا AbortController في بداية useEffect، ومرروا controller.signal إلى كل استدعاء fetch. وفي دالة التنظيف، استدعوا controller.abort(). يؤدي ذلك إلى إلغاء أي طلب قيد التنفيذ عند إزالة المكوّن، مما يمنع تحديثات الحالة في المكوّنات التي أزيلت ويحول دون تسرب موارد الشبكة.

عند فشل طلب استطلاع طويل، لا تعيدوا المحاولة فورًا، بل انتظروا قبل المحاولة التالية. يضاعف التراجع الأسي مدة الانتظار مع كل فشل متتالٍ: 1s و2s و4s و8s و16s، على ألا تتجاوز 30s. ويمنع ذلك إرهاق خادم متعطل، ويمنحه وقتًا لمعالجة المشكلات المؤقتة. أعيدوا مدة الانتظار إلى 1s عند نجاح الاستجابة.

عندما يستطلع عدد كبير من العملاء الخادم نفسه، يؤدي التراجع الأسي من دون عشوائية إلى ظاهرة «تدافع القطيع»: يتراجع جميع العملاء بالمدة نفسها ويعيدون المحاولة في الوقت نفسه، مما يرهق الخادم مجددًا. أضيفوا العشوائية عبر جعل مدة الانتظار عشوائية: delay + Math.random() * delay. يؤدي ذلك إلى توزيع المحاولات على نافذة زمنية، مما يقلل ارتفاعات الحمل على الخادم.

احتفظوا بحالة الاتصال لتعكس دورة حياة الاستطلاع: isConnecting (الاتصال الأولي أو إعادة الاتصال بعد حدوث خطأ)، وisConnected (نجاح آخر استطلاع)، وisError (حالات فشل متتالية أو بلوغ الحد الأقصى للمحاولات). اعرضوا هذه الحالة في واجهة المستخدم حتى يفهم المستخدمون مدى موثوقية البيانات الآنية.

أثناء مهلة التراجع التي تسبق إعادة المحاولة التالية، يمكنكم عرض عدّ تنازلي مثل: «إعادة الاتصال خلال 8 ثوانٍ...» مع مؤشر تقدّم. احسبوا الطابع الزمني لإعادة المحاولة عند ضبط مؤقت التراجع، وحدّثوا العرض كل ثانية. وتمنح هذه الشفافية المستخدمين الثقة بأن التطبيق يحاول الاستعادة بنشاط.

استخدموا setTimeout الاستدعائي التكراري (استدعاء الاستطلاع التالي داخل معالج الاستجابة) بدلًا من setInterval للاستطلاع. إذ يعمل setInterval على فواصل زمنية ثابتة بغض النظر عن مدة الطلب السابق، وقد تؤدي الطلبات طويلة التنفيذ إلى استطلاعات متداخلة. أما setTimeout الاستدعائي التكراري فلا يبدأ الاستطلاع التالي إلا بعد اكتمال السابق.

أتِيحوا فترة الاستطلاع كخيار ضبط في الخطاف الخاص بكم: useLongPoll({ url, interval: 5000 }). تحتاج مصادر البيانات المختلفة إلى درجات مختلفة من الحداثة؛ فقد يُجرى استطلاع مؤشر «من المتصل؟» كل 30s، بينما قد تُستطلع حالة مهمة كل 5s. تجنبوا تثبيت الفواصل الزمنية داخل كود التنفيذ.

مع نضج واجهة API الخاصة بكم، قد تستبدلون الاستطلاع بـ SSE لتحسين الكفاءة. ينبغي فصل مكوّن React الذي يستخدم خطاف الاستطلاع عن طبقة النقل. فإذا عرض الخطاف الواجهة نفسها (onData وstatus وerror)، فلن يتطلب الانتقال من الاستطلاع إلى EventSource في الخلفية أي تغييرات في المكوّن الذي يستخدم الخطاف.

عندما يبقي الخادم اتصال الاستطلاع الطويل مفتوحًا ولا تصل أي بيانات، يجب أن يرسل استجابة بانتهاء المهلة (200 مع جسم فارغ، أو 204 No Content) لمنع بقاء الاتصال معلقًا إلى أجل غير مسمى. ثم يجري العميل استطلاعًا جديدًا فورًا. وتختلف مهلة الخادم هذه (30–60s) عن مهلة fetch لدى العميل، التي تكون أطول (مثلًا 90s).

لماذا يستخدم الاستطلاع الطويل التراجع الأسي عند إعادة المحاولة بعد أخطاء الاتصال؟

الاستطلاع الطويل: يرسل العميل طلبًا، ويبقي الخادم الاتصال مفتوحًا حتى تتوفر البيانات أو تنتهي المهلة، ثم يعيد العميل إرسال الطلب فور تلقي الاستجابة. نفذوه باستخدام fetch غير متزامن واستدعائي تكراريًا داخل useEffect، مع AbortController للتنظيف. عند حدوث خطأ: استخدموا التراجع الأسي (1s و2s و4s... بحد أقصى 30s) مع العشوائية لمنع تدافع القطيع. استخدموا setTimeout الاستدعائي التكراري بدلًا من setInterval لمنع تداخل الاستطلاعات. وتتبعوا حالات isConnecting وisConnected وisError لعرض معلومات الحالة في واجهة المستخدم.