تعرض شاشة تعديل العميل كود الحساب بلون معطل لمنع تغييره. بعد الضغط على الحفظ يصل الاسم، لكن الكود غير موجود في الطلب. إذا عامل الخادم غياب الحقل كقيمة فارغة، قد تتغير بيانات لم يقصد المستخدم لمسها. ابدأ بفحص الطلب الفعلي بدل افتراض أن كل ما يظهر على الشاشة يُرسَل.
ما الذي تجمعه FormData من النموذج؟
توضح وثائق MDN لاستخدام FormData أن بناءها من نموذج يعتمد على الحقول المسماة، ولا يضم بيانات الحقول المعطلة أو مجموعات fieldset المعطلة. لذلك فإن وجود قيمة داخل input ظاهر لا يثبت وجودها في الحمولة الناتجة.
في مثال افتراضي، غيّر الاسم مع إبقاء كود الحساب disabled. التقط أسماء الحقول التي جُمعت قبل الإرسال، وقارنها بالعقد الذي يتوقعه مسار التحديث. لا تجعل القيمة التي تظهر في الشاشة مرجعًا موثوقًا لملكية الحساب أو صلاحياته؛ الخادم يحدد تلك البيانات من سياقه المصرح.
عرّف الغياب والفراغ صراحة
| الطلب | سؤال سياسة الحفظ |
|---|---|
| الحقل غير موجود | هل تبقى القيمة السابقة أم يرفض الطلب لنقص مطلوب؟ |
| الحقل موجود وقيمته فارغة | هل يسمح المستخدم بمسحه وفق قواعد الحقل؟ |
| الحقل موجود بقيمة جديدة | هل التغيير مسموح وصحيح ومخول؟ |
لا توجد قاعدة واحدة لكل مسارات النظام: إنشاء سجل جديد يختلف عن تعديل جزئي. المهم ألا يستنتج الخادم مسحًا حساسًا من غياب عرضي لحقل، وأن يكون سلوك الرفض أو الاحتفاظ موثقًا ومختبرًا.
انتبه لتوقيت تعطيل النموذج
قد يعطل الكود جميع الحقول أثناء الانتظار، ثم ينشئ FormData بعدها فتغيب القيم المقصودة. جرّب المسار البطيء وحالة النقر المتكرر، وافحص الترتيب الفعلي لتجميع البيانات وتعطيل الواجهة. حدد ما يُرسل أولًا ثم امنع التفاعل وفق تصميم يحافظ على البيانات، دون استعمال إعادة تمكين عشوائية لتجاوز القواعد.
تحقق من السجل بعد الحفظ
ضمن تطوير CRM وبناء نماذج الويب اختبر بقيم مصطنعة واحفظ مقارنة قبل وبعد. أرسل أيضًا قيمة معدلة لحقل حساس من عميل اختبار؛ يجب أن تظل حماية الخادم قائمة. معيار القبول ليس ظهور رسالة نجاح، بل وصول القيم المسموحة فقط وبقاء ما لم يُقصد تغييره وفق عقد واضح.
