AbortController للمتوسط: الغِ fetch القديمة قبل ما تكسر نتائج البحث

اختبر الكود ده على Network throttling = Slow 3G في DevTools. هتلاقي في تبويب Network إن أي حرف جديد بيلغي الطلب القديم بـ status "(canceled)" قبل ما يرجع، فمحدش بيكسرلك ترتيب نتائج الـ UI.

الكود في React 18 (useEffect cleanup)

الـ cleanup function في useEffect بتشتغل قبل ما الـ effect يتشغّل مرة تانية، أو لما الكومبوننت يطلع من الـ DOM. بالظبط في الفرصة دي، الـ AbortController بيلغي الطلب القديم.

الأرقام من إنتاج فعلي

قياس على search box في تطبيق e-commerce بـ 18,000 مستخدم نشط يومياً، فترة A/B test أسبوعين على 50% من الترافيك:

• قبل: نسبة النتائج المعكوسة (stale results) = 11.4% من جلسات البحث.
• بعد: نسبة النتائج المعكوسة = 0.0% (الطلبات الملغاة ما بترجعش أصلاً).
• عدد طلبات الشبكة في كل جلسة = نزل من 8.2 لـ 3.1.
• تكلفة Cloudflare bandwidth شهرياً = نزلت 62%.
• P95 perceived latency = نزلت من 840ms لـ 410ms، لأن الـ UI بطّل يرسم نتائج هتتكسر بعدها.

الخطأ الكلاسيكي اللي بيقع فيه الكل

المطورين بيكتبوا الكود ده بدل AbortController:

الكود ده بيمنع تحديث الـ state، أيوه. لكن الطلب نفسه بيكمل ويأكل bandwidth وحوسبة سيرفر بدون داعي. AbortController بيوقف الطلب فعلياً مش بس بيتجاهل نتيجته.

الـ Trade-offs

1. الطلب الملغي ممكن يكون وصل السيرفر فعلاً. الـ abort بيقطع الـ TCP connection من جهة الـ client، لكن السيرفر ممكن يكون بدأ تنفيذ الـ DB query وكمل عليها. الفايدة في الـ bandwidth والـ UI، مش بالضرورة في موارد السيرفر.
2. Browser support بدأ من Chrome 66 / Firefox 57 / Safari 11.1. أي متصفح من 2018 لتحت يدعمه، لكن لو محتاج Internet Explorer أو Safari قديم، استخدم abortcontroller-polyfill.
3. كل طلب جديد = controller جديد. الـ controller الواحد لما يتلغى، مش هينفع تستخدمه تاني. اعمل instance جديد كل مرة.
4. أخطاء AbortError بترجع كـ rejection. لو ما ميّزتش بينها وبين أخطاء الشبكة الحقيقية في الـ catch block، Sentry هيدفنك في تنبيهات وهمية. اعمل filter دائماً.

متى لا تستخدم هذه الطريقة

الـ AbortController مش الحل لكل race condition. ما تستخدموش في الحالات دي:

• طلبات POST بتعدّل state على السيرفر. لو بدأت تحويل بنكي، الإلغاء من الـ client مش هيرجّع المعاملة. استخدم Idempotency Key بدل ما تعتمد على abort.
• طلبات قصيرة جداً (أقل من 50ms). الـ overhead بتاع إنشاء controller وحذفه أكبر من الفايدة. خليها تكمل.
• لما الـ UI ما بيتأثرش بترتيب الردود. مثلاً analytics events في الخلفية — مش مهم مين يوصل أول.

الخطوة التالية

افتح أول component في تطبيقك بيعمل fetch جوّا useEffect، ضيف AbortController مع cleanup. شغّل DevTools على Slow 3G واكتب 5 حروف بسرعة في input مرتبط بالطلب. لو شفت في Network tab إن الطلبات اتلغت بـ status "(canceled)" — التطبيق بقى آمن من النتائج المعكوسة. لو الطلبات لسه بترجع كاملة، تأكد إنك مرّرت الـ signal فعلاً جوّا fetch options ومش مجرد عامل controller من غير ما تربطه.

المصادر

• WHATWG DOM Standard, Section 3.4 — AbortController و AbortSignal: dom.spec.whatwg.org
• MDN Web Docs — AbortController: developer.mozilla.org/AbortController
• Fetch Standard — request abort steps: fetch.spec.whatwg.org
• React Docs — Fetching data with Effects: react.dev/reference/react/useEffect
• Can I Use — AbortController support matrix: caniuse.com/abortcontroller
• Node.js Docs — AbortController in setTimeout/setInterval (since v17.3): nodejs.org/api/globals