Form Validation هي عملية التحقق من جميع حقول النموذج للتأكد من صحتها قبل إرسال البيانات إلى الخادم. على عكس التحقق من حقل فردي، تراعي Form Validation العلاقات بين الحقول: تأكيد كلمة المرور، اعتماد حقل على آخر، الإلزام الشرطي. وفقًا لـ Google Developers, 2026، يجب أن يتحقق Form Validation من النموذج بأكمله عند الإرسال ويقدم للمستخدم ملخصًا لجميع الأخطاء. يزيد التحقق الصحيح من النموذج من معدل تحويل التسجيل بنسبة 25-35% ويقلل من عدد الأخطاء أثناء الإدخال.
الخلاصة
Form Validation هي عملية تضمن أن جميع البيانات التي أدخلها المستخدم في النموذج تتوافق مع متطلبات العمل قبل إرسالها إلى الخادم. يتضمن التحقق من النموذج فحص كل حقل على حدة، بالإضافة إلى الفحوصات المتقاطعة: هل كلمة المرور تطابق التأكيد، هل تم تحديد مربع اختيار واحد على الأقل، هل تم ملء جميع الحقول الإلزامية، هل التاريخ صحيح (على سبيل المثال، تاريخ الميلاد ليس في المستقبل).
الفرق عن التحقق البسيط من الحقل هو أن Form Validation تتعامل مع النموذج كوحدة واحدة. يمكنها حظر الإرسال إذا لم يتم ملء حقل شرطي، أو عرض ملخص للأخطاء في نافذة حوار. في النماذج المعقدة (التسجيل، إتمام الطلب، الاستبيانات)، يعد التحقق من النموذج طبقة منطقية منفصلة يتم اختبارها بشكل مستقل عن واجهة المستخدم.
وفقًا لأبحاث تجربة المستخدم من NN Group، يكمل المستخدمون النموذج 3 مرات أكثر إذا رأوا الأخطاء مباشرة بعد الإرسال، بدلاً من بعد كل حقل على حدة. ومع ذلك، فإن أفضل نتيجة تأتي من الجمع بين: التحقق الفوري من الحقول البسيطة (الطول، التنسيق) + الفحص الكامل عند الإرسال للحقول المتقاطعة ومنطق الأعمال.
التحقق من الحقل يجيب على السؤال: هل الإدخال في هذا الحقل المحدد صحيح؟ البريد الإلكتروني له تنسيق user@domain.com، الهاتف يتكون من أرقام، كلمة المرور أطول من 6 أحرف. التحقق من الحقل معزول — لا يعتمد على الحقول الأخرى ويمكن إجراؤه في الوقت الفعلي. النتيجة: خطأ لحقل محدد أو عدم وجود خطأ.
التحقق من النموذج يجيب على السؤال: هل يمكن إرسال النموذج بالكامل؟ إنه لا يراعي كل حقل فحسب، بل يراعي أيضًا مجموعاتها: يجب أن تتطابق كلمة المرور والتأكيد، لا يمكن أن يكون تاريخ البدء متأخرًا عن تاريخ الانتهاء، يجب أن يساوي مجموع الحقول 100%. يتم إجراء التحقق من النموذج عند الإرسال ويعيد نتيجة إجمالية: النموذج صالح أم لا.
من الناحية المعمارية، يتم وضع التحقق من الحقل في طبقة واجهة المستخدم (جزء، ViewModel)، بينما يتم وضع التحقق من النموذج في طبقة المجال (حالة استخدام، متفاعل). يتيح ذلك إعادة استخدام التحقق من النموذج عبر مكونات واجهة مستخدم مختلفة واختباره بدون محاكي. في الهندسة النظيفة، التحقق من النموذج هو قاعدة عمل، وليس منطق واجهة مستخدم.
| المعيار | التحقق من الحقل | التحقق من النموذج |
|---|---|---|
| موضوع الفحص | حقل واحد | جميع الحقول + علاقاتها |
| وقت التنفيذ | في الوقت الفعلي / عند فقدان التركيز | عند إرسال النموذج |
| النتيجة | خطأ في حقل محدد | الحالة العامة للنموذج + قائمة الأخطاء |
| طبقة الهندسة | طبقة واجهة المستخدم | طبقة المجال |
هناك نهجان رئيسيان لـ Form Validation. الأول هو الأمرّي: يكتب المطور دالة تتحقق بالتسلسل من كل حقل وتجمع قائمة بالأخطاء. هذا النهج بسيط للفهم، لكن الكود ينمو مع كل حقل جديد. بالنسبة لنموذج يحتوي على 5 حقول، لا يزال النهج الأمرّي مريحًا؛ أما بالنسبة لـ 15 حقلاً، فهو إشكالي بالفعل.
النهج الثاني هو التصريحي: يتم وصف قواعد التحقق باستخدام التعليقات التوضيحية أو التكوين. المكتبة نفسها تتنقل عبر جميع الحقول، وتطبق القواعد، وتعرض النتيجة. مثال: التعليق التوضيحي @Email على حقل emailData، و @ConfirmPassword على حقل التأكيد. يقلل النهج التصريحي من كود التحقق بمقدار 3-5 مرات ويجعله قابلًا للقراءة.
النهج الثالث هو التفاعلي باستخدام RxJava أو Kotlin Flow. يتم تمثيل كل حقل كـ Observable أو StateFlow. يشترك التحقق من النموذج في التغييرات في جميع الحقول ويعيد حساب الحالة العامة مع كل تغيير. يصبح زر الإرسال نشطًا تلقائيًا عندما تكون جميع الحقول صالحة. يتطلب هذا النهج فهم البرمجة التفاعلية، لكنه يوفر أفضل تجربة مستخدم.
لنفكر في نموذج تسجيل بثلاثة حقول: البريد الإلكتروني، كلمة المرور، وتأكيد كلمة المرور. يتضمن التحقق من النموذج: التحقق من البريد الإلكتروني عبر Patterns.EMAIL_ADDRESS، التحقق من أن كلمة المرور بطول أدنى 8 أحرف وتحتوي على رقم واحد على الأقل، التحقق من تطابق كلمة المرور والتأكيد. فقط عندما تجتاز الفحوصات الثلاثة، يمكن إرسال النموذج.
data class RegistrationForm(
val email: String,
val password: String,
val confirmPassword: String
)
fun validateRegistration(form: RegistrationForm): ValidationResult {
if (!Patterns.EMAIL_ADDRESS.matcher(form.email).matches())
return ValidationResult(false, "Invalid email address")
if (form.password.length < 8)
return ValidationResult(false, "Password too short")
if (form.password != form.confirmPassword)
return ValidationResult(false, "Passwords do not match")
return ValidationResult(true)
}
في المثال، تأخذ validateRegistration فئة بيانات النموذج وتعيد ValidationResult. إذا فشل فحص واحد على الأقل، فإنها تعيد false مع رسالة مقابلة. تعتمد إدارة زر الإرسال على النتيجة: إذا كان isValid = true، يكون الزر نشطًا. لتحديث الحالة في الوقت الفعلي، يمكن استخدام LiveData
النهج التفاعلي مع Kotlin Flow يسمح بإعادة حساب حالة النموذج تلقائيًا. يتم تمثيل كل حقل كـ MutableStateFlow
Android Saripaar هي مكتبة التحقق الأكثر شيوعًا لنظام Android. تسمح بتعليق الحقول وطرق العرض مباشرة: @Email، @NotEmpty، @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). يتم تشغيل التحقق بسطر واحد validator.validate() مع رد اتصال. يقوم Saripaar تلقائيًا بتعيين الخطأ عبر setError على EditText. تدعم المكتبة أيضًا التعليقات التوضيحية المخصصة لقواعد العمل المحددة.
RxBinding + RxJava هو نهج تفاعلي بدون مكتبة تحقق منفصلة. ينشر كل حقل تغييراته عبر RxTextView.textChanges(). يقوم عامل combineLatest بدمج جميع الحقول وحساب الحالة العامة. الميزة: تحكم كامل في خط أنابيب التحقق، وإمكانية إضافة debounce و throttle و filter. العيب: يتطلب معرفة بـ RxJava.
Material Design Components توفر دعمًا مدمجًا لـ TextInputLayout و TextInputEditText. لا توفر المكتبة التحقق في حد ذاته، ولكنها تعطي واجهة مستخدم لعرض الأخطاء: setError()، setHelperText()، setCounterEnabled(). للتحقق نفسه، لا تزال هناك حاجة إلى منطق يدوي أو Saripaar. تتولى Material Components مسؤولية العرض، وليس الفحص.
الخطأ الأول هو التحقق من جانب العميل فقط. Form Validation على العميل مخصصة لتجربة المستخدم، وليس للأمان. يمكن للمهاجم إرسال طلب مباشرة إلى API، متجاوزًا التحقق. يجب على الخادم التحقق من جميع الحقول مرة أخرى. لا ينبغي أن يكون التحقق من جانب العميل هو الحماية الوحيدة — إنها طبقة إضافية لراحة المستخدم، وليس لأمن البيانات.
الخطأ الثاني هو حظر زر الإرسال بدون رسائل. إذا كان الزر غير نشط، يجب أن يرى المستخدم الحقول التي تحتاج إلى تصحيح. الزر الرمادي بدون شرح هو أحد أكثر أسباب انخفاض تحويل النماذج شيوعًا. اعرض دائمًا أخطاء الحقول بجانبها، حتى إذا كان الزر معطلاً. يجب أن يفهم المستخدم ما الذي يمنع الإرسال بالضبط.
الخطأ الثالث هو تجاهل الفحوصات المتقاطعة. التحقق من كل حقل على حدة غير كافٍ. يمكن أن تعتمد الحقول على بعضها البعض: كلمة المرور والتأكيد، تاريخ البدء وتاريخ الانتهاء، البلد والمدينة. يجب أن يتحقق Form Validation من هذه العلاقات. التحقق من الحقول الفردية فقط يخلق إحساسًا زائفًا بالأمان — قد يتم إرسال النموذج ببيانات غير متسقة.
| الخطأ | النتيجة | الحل |
|---|---|---|
| تحقق من جانب العميل فقط | ثغرة أمنية | فحص إلزامي من جانب الخادم |
| زر بدون رسائل | انخفاض تحويل النموذج | إظهار أخطاء الحقول |
| لا فحوصات متقاطعة | بيانات غير متسقة | التحقق من علاقات الحقول |
| فحوصات متكررة جدًا | إزعاج المستخدم | Debounce والتحقق عند فقدان التركيز |
الأسئلة الشائعة
التحقق من الحقل يتحقق من قيمة واحدة مقابل متطلبات التنسيق أو الطول. يتحقق Form Validation من جميع الحقول معًا، بما في ذلك الفحوصات المتقاطعة: تطابق كلمات المرور، اعتماد الحقول على بعضها. يتم التحقق من الحقل في طبقة واجهة المستخدم، Form Validation — في طبقة المجال كقاعدة عمل.
استخدم النهج التفاعلي: ادمج جميع الحقول في Flow أو Observable واحد واشترك في التغييرات. مع كل تغيير في أي حقل، أعد حساب الحالة العامة للنموذج. إذا كانت الحالة صالحة — يكون الزر نشطًا. استخدم Kotlin Flow مع combine أو RxJava مع combineLatest للتحديثات التلقائية.
Android Saripaar هو الخيار الأفضل للتحقق التصريحي مع التعليقات التوضيحية. إذا كان المشروع يستخدم RxJava — يوفر RxBinding نهجًا تفاعليًا بدون مكتبة منفصلة. للنماذج البسيطة، يكفي التحقق اليدوي باستخدام Patterns و TextUtils بدون تبعيات خارجية.
بالتأكيد. التحقق من جانب العميل يحسن تجربة المستخدم ولكنه لا يوفر الأمان. يجب على الخادم التحقق من جميع البيانات مرة أخرى لأن API متاح مباشرة. لا تعتمد أبدًا على التحقق من جانب العميل فقط للحماية من البيانات غير الصحيحة أو الضارة.
في Jetpack Compose، استخدم Kotlin Flow أو StateFlow لتخزين حالة كل حقل. تأخذ دالة التحقق حالة النموذج وتعيد ValidationResult. يشترك زر الإرسال في الحالة العامة. لعرض الأخطاء، استخدم isError في OutlinedTextField أو TextField في Compose.
الملخص
سنقوم بتطوير تطبيق جوال جاهز
تقدم IT Sectr تطبيقات iOS وAndroid للشركات الناشئة والشركات منذ عام 2017. سوف نقدم لك النصح ونقترح أفضل حل.