قد يغيّر المستخدم عامل التصفية بسرعة فيرسل التطبيق طلبين، ثم تصل استجابة الطلب الأقدم بعد الأحدث وتستبدل النتائج الصحيحة. هذه مشكلة ترتيب أحداث لا مشكلة سرعة شبكة فقط. تصميم واجهة متينة يحتاج تحديد أي استجابة ما زالت صالحة للتطبيق على الحالة الحالية.
أعد إنتاج السباق عمدًا
جرّب البحث عن كلمة ثم تغييرها بسرعة قبل وصول الرد، وأضف تأخيرًا مصطنعًا مختلفًا لكل طلب في بيئة الاختبار. راقب معرف الطلب والفلتر الحالي وترتيب وصول الاستجابات. لا تعتمد على تكرار النقر يدويًا وحده لأن المشكلة قد لا تظهر على اتصال سريع.
اربط الاستجابة بالحالة التي أنشأتها
امنح كل عملية بحث معرفًا أو رقم إصدار، ولا تطبق النتيجة إلا إذا كانت تطابق أحدث حالة مقصودة. قد تستخدم AbortController لإلغاء طلب لم يعد مطلوبًا، لكن الإلغاء لا يضمن أن الخادم أوقف العمل بالفعل. لذلك يظل فحص صلاحية الاستجابة ضروريًا.
ميز القراءة عن الكتابة
تجاهل نتيجة قراءة قديمة غالبًا آمن، لكن تكرار طلب حفظ أو إلغاء عملية دفع يحتاج قواعد مختلفة. استخدم معرفات عمليات ثابتة وآليات تمنع تكرار الأثر عندما تكون العملية حساسة. لا تجعل ترتيب ظهور الأزرار بديلًا عن حماية الخادم من التنافس.
اختبر التحميل والأخطاء المتداخلة
قد يفشل الطلب القديم بعد نجاح الجديد، فتظهر رسالة خطأ رغم أن النتائج المعروضة صحيحة. اربط حالة التحميل والخطأ بمعرف العملية الحالية، وتأكد أن انتهاء طلب سابق لا يخفي مؤشر انتظار الطلب الأحدث. اختبر كذلك الرجوع في المتصفح وتغيير الصفحة أثناء الطلب.
أضف اختبار انحدار حتميًا
استخدم اعتراض الشبكة للتحكم في ترتيب الردود: أرسل الطلب A ثم B، وأعد B أولًا ثم A. يجب أن تظل بيانات B هي الظاهرة إذا كانت أحدث اختيار للمستخدم. راجع السجلات دون تخزين استعلامات حساسة بلا حاجة. النجاح أن تتبع الواجهة نية المستخدم الأخيرة لا ترتيب وصول الشبكة.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…