في محرر طلبات افتراضي، يكتب الموظف ملاحظة في الطلب A ثم يختار B من القائمة. يتغير العنوان، لكن نص A يبقى في الحقل لأن المكون نفسه يحتفظ بحالته. قبل تعديل كل حقل يدويًا، اسأل هل النموذجان يجب أن يتشاركا الحالة أصلًا.
هوية المكون قرار مقصود
يحتفظ React بالحالة عندما يبقى المكون الموافق في الموضع نفسه من الشجرة. استخدام key مختلفة للسجل يغير الهوية، فيُزال النموذج القديم وتبدأ حالة الجديد. استخدم معرفًا مستقرًا من البيانات، لا قيمة عشوائية تتغير كلما كتب المستخدم حرفًا.
المرجع: React preserving and resetting state.
ضع الحد حول النموذج المعني
إذا كانت القائمة الجانبية والفلتر يجب أن يبقيا كما هما، لا تضع المفتاح حول الصفحة كلها. اجعله على جزء محرر السجل. قرر أيضًا هل تُفقد المسودة عند المغادرة أم يُطلب تأكيد أم تُحفظ لكل سجل؛ تغيير المفتاح لا يحفظ المدخلات وحده.
اختبر انتقالًا له أثر واضح
اكتب ملاحظة تجريبية في A دون حفظ، وانتقل إلى B. تحقق أن B يعرض ملاحظته الخاصة أو نموذجًا فارغًا، ثم عد إلى A واختبر سياسة المسودة المتفق عليها. كرر تغيير قيمة أخرى في الصفحة دون تبديل المعرف، وتأكد أن النموذج لا يُعاد إنشاؤه على كل تحديث عادي.
لا تستخدم key بدل التحقق من الطلب
إذا وصل تحميل A متأخرًا بعد اختيار B، تحتاج طبقة البيانات إلى ربط الاستجابة بالمعرف الصحيح. وعند الحفظ، تحقق أن معرف الطلب المرسل يطابق النموذج الحالي وأن الخادم يراجع التفويض. افحص كذلك موضع التركيز بعد إعادة إنشاء النموذج، خاصة عند التنقل بلوحة المفاتيح.
لربط الاختبار بتنفيذ مشروعك، راجع تطوير المواقع والمتاجر وأنظمة إدارة علاقات العملاء.
صورة توضيحية أصلية لشرح الفكرة، وليست لقطة نظام عميل أو نتيجة قياس فعلية.
