ينقر موظف CRM على العميل A ثم ينتقل سريعًا إلى B. يصل رد B أولًا، وبعده رد A البطيء فيستبدل الشاشة بمعلومات قديمة بينما العنوان ما زال يشير إلى B. هذه مشكلة ترتيب استجابات، وقد تحدث حتى لو كانت صلاحيات API صحيحة وكل طلب يعيد بياناته المطلوبة.
اربط النتيجة بالاختيار الذي أنشأها
تعرض وثائق React الخاصة بـuseEffect مثالًا يستخدم cleanup لتجاهل النتيجة السابقة، لأن ردود الشبكة قد تصل بترتيب مختلف عن الإرسال. وتناقش بدائل جلب البيانات عبر إطار العمل أو كاش مناسب. اختر الآلية التي تناسب بنية التطبيق، بدل جعل كل مكون يخترع سياسة مستقلة.
لا يكفي مسح الاسم عند الضغط على العميل الجديد. يجب أن يظل تحديث البيانات مرتبطًا بهوية الطلب والعميل الحالي، بما في ذلك رسالة الخطأ ومؤشر التحميل. كما أن تجاهل نتيجة قديمة في الواجهة لا يلغي بالضرورة العمل الذي نفذه الخادم.
اصنع ترتيبًا معكوسًا في الاختبار
| التسلسل المصطنع | النتيجة المطلوبة |
|---|---|
| بدء قراءة A ثم اختيار B | إعلان تحميل B بهويته الصحيحة |
| اكتمال B قبل A | عرض بيانات B |
| وصول A متأخرًا | عدم استبدال بيانات B |
| فشل A بعد نجاح B | عدم إظهار خطأ A كأنه يخص B |
راجع المغادرة والعودة
استخدم بيانات مصطنعة وتأخيرًا محكومًا في بيئة اختبار، ثم غادر شاشة العميل قبل اكتمال القراءة. عد وافتحه مجددًا وفق آلية الجلب المعتمدة. سجل معرف الطلب واختيار الواجهة وتوقيت النتيجة، دون نسخ أسماء عملاء حقيقيين إلى سجل تطوير مشترك.
إن اعتمدت كاشًا، راجع مفاتيحه ونطاقه؛ منع الرد القديم لا يصلح مفتاحًا يخلط شركتين أو حسابين. ولمراجعة صلاحية النسخة المخزنة، اقرأ اختبار ETag وعزل بيانات المستخدمين. افحص كذلك حالة اختيار العميل نفسه مجددًا، وتغير معايير البحث، وأي تبويب فرعي يرسل طلبه المستقل.
اعتمد سلامة العرض قبل سرعة التنقل
ضمن تطوير CRM وواجهات الويب سلّم سيناريو قابلًا للتكرار مع إثبات أن العنوان والبيانات والخطأ والتحميل تخص الاختيار نفسه. هذا فحص لقراءة البيانات في الواجهة؛ حفظ تعديل عميل يحتاج تحققًا مستقلًا من هويته وصلاحياته على الخادم، حتى عندما تبدو الشاشة صحيحة.
