التحقق من مدخلات المستخدم في JavaScript: منع الأخطاء وتحسين تجربة الاستخدام

إدخال المستخدم هو أكثر جزء غير متوقع في أي تطبيق. قد يترك الحقول فارغة، يكتب نصاً بدل رقم، أو يضع تنسيق بريد غير صحيح. هنا يأتي دور Input Validation.

الهدف من التحقق ليس فقط "منع الخطأ"، بل أيضاً توجيه المستخدم برسائل واضحة حتى يصل للنتيجة بسرعة.

1) التحقق من الحقول الفارغة

const name = document.querySelector("#name").value.trim();

if (name === "") {
  console.log("الاسم مطلوب");
}

ماذا يفعل هذا الكود؟ يزيل المسافات ثم يتحقق أن الاسم ليس فارغاً.

النتيجة المتوقعة: منع إرسال النموذج إذا لم يكتب المستخدم اسماً حقيقياً.

خطأ شائع: نسيان trim() فيُقبل إدخال عبارة عن مسافات فقط.

2) التحقق أن القيمة رقم

const ageValue = document.querySelector("#age").value;
const age = Number(ageValue);

if (ageValue === "" || Number.isNaN(age)) {
  console.log("أدخل عمراً رقمياً صحيحاً");
}

ماذا يفعل هذا الكود؟ يحوّل القيمة لرقم ويتأكد أنها صالحة.

النتيجة المتوقعة: قبول القيم الرقمية فقط.

خطأ شائع: استخدام isNaN بشكل مباشر على النص دون فهم التحويل الضمني.

3) التحقق من نطاق الرقم

if (age < 18 || age > 60) {
  console.log("العمر يجب أن يكون بين 18 و 60");
}

ماذا يفعل هذا الكود؟ يفرض حدوداً منطقية على القيمة المدخلة.

النتيجة المتوقعة: عدم قبول قيم غير واقعية.

خطأ شائع: فحص النطاق قبل التأكد أن القيمة رقم أصلاً.

4) التحقق من البريد الإلكتروني (بسيط)

const email = document.querySelector("#email").value.trim();
const hasBasicFormat = email.includes("@") && email.includes(".");

if (!hasBasicFormat) {
  console.log("صيغة البريد غير صحيحة");
}

ماذا يفعل هذا الكود؟ يفحص التنسيق الأساسي للبريد بشكل مبسط.

النتيجة المتوقعة: منع الصيغ الواضحة الخاطئة مثل abc.

خطأ شائع: الاعتقاد أن هذا الفحص يغطي كل حالات البريد الممكنة.

5) ربط التحقق بحدث submit

const form = document.querySelector("#registerForm");

form.addEventListener("submit", function (e) {
  const username = document.querySelector("#username").value.trim();

  if (username.length < 3) {
    e.preventDefault();
    console.log("اسم المستخدم يجب أن يكون 3 أحرف على الأقل");
  }
});

ماذا يفعل هذا الكود؟ يتحقق قبل الإرسال ويمنع العملية عند الخطأ.

النتيجة المتوقعة: النموذج لا يُرسل حتى تصبح البيانات صالحة.

خطأ شائع: نسيان preventDefault() فتُرسل البيانات الخاطئة.

مثال عملي كامل (أقرب للمشاريع)

function validateForm(data) {
  const errors = [];

  if (data.name.trim().length < 3) {
    errors.push("الاسم يجب أن يكون 3 أحرف على الأقل");
  }

  const age = Number(data.age);
  if (Number.isNaN(age) || age < 18) {
    errors.push("العمر يجب أن يكون رقماً أكبر أو يساوي 18");
  }

  if (!data.email.includes("@")) {
    errors.push("البريد الإلكتروني غير صالح");
  }

  return errors;
}

ماذا يفعل هذا الكود؟ يجمع أخطاء التحقق في مصفوفة بدلاً من إيقاف الفحص عند أول خطأ.

النتيجة المتوقعة: عرض كل المشاكل للمستخدم دفعة واحدة.

خطأ شائع: عرض خطأ واحد فقط كل مرة، مما يربك المستخدم ويبطئه.

Story قصيرة: نموذج لا يسجل المستخدمين

فريق صغير كان يرسل النموذج مباشرة بدون تحقق. وصلت بيانات ناقصة وأعمار كنصوص، وتعطل جزء من النظام. بعد إضافة تحقق بسيط في الواجهة ورسائل واضحة، انخفضت الأخطاء بشكل كبير.

Client-side vs Server-side Validation

• Client-side (JavaScript): سريع ويحسن UX، لكنه غير كاف وحده.
• Server-side: أساسي للأمان ولا يمكن تجاوزه من المستخدم بسهولة.

القاعدة الذهبية: تحقق في الطرفين دائماً.

Checklist سريعة

• أستخدم trim() قبل التحقق من النصوص.
• أحوّل القيم إلى Number قبل الفحص الحسابي.
• أتحقق من النطاقات المنطقية (مثل العمر).
• أمنع submit عند وجود أخطاء وأعرض رسائل واضحة.
• لا أعتمد على JavaScript فقط، وأتحقق أيضاً في الخادم.

الأسئلة الشائعة — FAQ

لماذا Validation مهم؟

لمنع إدخال بيانات خاطئة، وتحسين تجربة المستخدم، وتقليل أخطاء النظام.

هل JavaScript Validation كافٍ؟

لا، يجب وجود تحقق في الخادم لأن تحقق الواجهة يمكن تجاوزه.

ما أفضل أسلوب لعرض الأخطاء؟

رسالة واضحة قرب الحقل مع اقتراح مباشر للتصحيح.

للمراجعة: User Interaction. للمتابعة: Timing.