يضيف المستخدم ثلاثة بنود إلى نموذج طلب، ويكتب ملاحظة في البند الثاني. يحذف البند الأول فتظهر الملاحظة بجوار بند آخر. قد تكون البيانات الأصلية لم تنتقل في الخادم، لكن الواجهة أعادت استعمال حالة مكون لصف مختلف. قبل مطاردة التنسيق، راجع الهوية التي تستخدمها قائمة React.
افصل موضع الصف عن هويته
توضح وثائق React للقوائم أن key يساعد على مطابقة العناصر عند الإضافة والحذف وإعادة الترتيب. يجب أن يكون فريدًا بين العناصر الشقيقة وثابتًا، وتوليده أثناء العرض قد يعيد إنشاء المكونات ويفقد مدخلاتها. كما أن المكون لا يتلقى key تلقائيًا كخاصية عمل.
اختر هوية مرتبطة بالبند لا برقم ترتيبه الحالي. للبند الجديد غير المحفوظ، يمكن تخصيص معرف محلي عند الإنشاء والاحتفاظ به طوال عمره. لا تولد معرفًا مختلفًا في كل إعادة عرض، ولا تفترض أن معرف الواجهة يثبت ملكية سجل في الخادم.
جهز نموذجًا بثلاث هويات واضحة
- أنشئ بنودًا مصطنعة بأسماء مختلفة وملاحظة مميزة في كل واحد.
- احذف البند الأول وراجع ملاحظات البنود الباقية وقيمها.
- أعد ترتيبها ثم أضف بندًا جديدًا في المنتصف.
- فعّل تحققًا يعرض خطأ على بند واحد، وتأكد أنه بقي مرتبطًا بالبند الصحيح.
افحص الحالة المحلية داخل مكون الصف والبيانات التي سترسل عند الحفظ كلًا على حدة. قد تبدو القيم صحيحة لأن كل الحقول مضبوطة من حالة مركزية، بينما يبقى مكون فرعي أو رسالة تحقق مرتبطة بمفتاح غير مناسب.
راجع الحفظ والعودة إلى المسودة
في مثال افتراضي لنموذج ERP، يحصل البند على معرف قاعدة بيانات بعد الحفظ. حدد كيف يحتفظ المحرر بهوية مستقرة عند وصول الرد، حتى لا يؤدي تحديث البيانات إلى ضياع مدخل لم يُحفظ بعد. اختبر أيضًا ظهور نسخة محدثة من الخادم أثناء التحرير وفق السياسة المعتمدة.
اعتمد النتيجة على البند نفسه
ضمن نموذج ERP وتجربة المستخدم وثق معرف كل بند وقيمه قبل الحركة وبعدها، دون بيانات حقيقية. معيار القبول بقاء الحالة والاختيار والتحقق مع هوية البند، مع فحص مستقل لصلاحيات البيانات عند إرسال الطلب. ترتيب العنصر وسيلة عرض، وليس هوية دائمة له.
