يفتح نموذج العميل قبل وصول API فتكون قيمة الملاحظة undefined، ثم تصبح نصًا بعد التحميل. يظهر تحذير React عن الانتقال من uncontrolled إلى controlled. حل التحذير يبدأ بتحديد من يملك قيمة الحقل طوال عمره، ثم فصل حالة التحميل عن معنى النص الفارغ.
قيمة أولية أم قيمة يتحكم فيها التطبيق؟
توضح وثائق React للحقل input أن value النصية تجعل الحقل متحكمًا فيه، وتحتاج onChange يحدّث القيمة. يجب أن تظل قيمة الحقل المتحكم فيه نصًا، لا null أو undefined. أما defaultValue فتحدد قيمة أولية للحقل غير المتحكم فيه، وليست آلية لتحديثه مع كل استجابة.
في مثال افتراضي لملاحظات CRM، يمكن تهيئة حالة النص بسلسلة فارغة، لكن ذلك لا يعني أن التحميل اكتمل أو أن الخادم أعاد ملاحظة فارغة. احتفظ بحالة تحميل أو فشل منفصلة، وقرر هل يسمح المنتج بالتعديل قبل وصول السجل.
اختبر الرحلة لا أول كتابة فقط
| الخطوة | ما تراجعه |
|---|---|
| فتح النموذج على شبكة بطيئة | نوع قيمة ثابت وحالة تحميل مفهومة |
| عودة ملاحظة فارغة من API | لا خلط بينها وبين فشل الجلب |
| كتابة المستخدم | تحديث متزامن مع القيمة المعروضة |
| إعادة جلب أثناء وجود تعديل | لا محو صامت للنص غير المحفوظ |
لا تجعل التطبيع يخفي خطأ العقد
قد يناسب value={note ?? ''} عقدًا يعامل null كغياب ملاحظة، لكنه لا يثبت أن كل أنواع استجابة API صحيحة. راجع النوع المتوقع عند الحد الفاصل مع الخادم، ولا تحول كائنًا غير متوقع إلى نص عشوائي لمجرد إسكات التحذير.
كذلك تختلف مربعات الاختيار: checked تحتاج قيمة منطقية. لا تطبق معالجة النص الفارغ على كل عناصر النموذج. وإذا تجمد الحقل أثناء الكتابة، راجع مسار التحديث بدل إضافة defaultValue بجانب value.
اجعل القبول مفهومًا للمستخدم
في تطوير الويب اختبر فشل التحميل وإعادة المحاولة والتعديل ببيانات مصطنعة. وتراجع تجربة الاستخدام توقيت إتاحة الحقول ورسائل الحالة. اختفاء التحذير من وحدة التحكم علامة محدودة؛ معيار القبول حفظ النص المقصود دون التباس أو فقد تعديل.
