إجراءات النماذج: استبدال مسارات API بعمليات التعديل

في تطبيقات Next.js التقليدية، يتطلب إرسال النماذج استخدام مكوّن عميل يحتوي على معالج onSubmit يستدعي fetch() لإرسال البيانات عبر POST إلى مسار API. ينجح هذا النمط، لكنه يتطلب كتابة منطق fetch على جانب العميل ومعالج المسار على جانب الخادم وصيانتهما بشكل منفصل.

باستخدام إجراءات الخادم، تستبدلون استدعاء fetch ومسار API بدالة واحدة. ويتلقى عنصر النموذج إجراء الخادم باعتباره الخاصية action: <form action={serverAction}>. ويتولى React اعتراض الإرسال واستدعاء الإجراء ببيانات النموذج تلقائيًا.

يتلقى إجراء الخادم تلقائيًا كائن FormData باعتباره وسيطه عند تشغيله بواسطة نموذج. ويمكنكم الوصول إلى الحقول الفردية باستخدام formData.get('email') الذي يعيد القيمة كسلسلة نصية. وتتوفر جميع أساليب FormData القياسية، بما في ذلك getAll() لحقول الاختيار المتعدد.

يمكن لإجراء الخادم إعادة قيمة قابلة للتسلسل ليستفيد منها العميل. فإعادة كائن خطأ مثل { error: 'Email already exists' } أو علامة نجاح مثل { success: true } تتيح للعميل تحديث واجهة المستخدم وفقًا لذلك من دون إعادة تحميل الصفحة بالكامل.

بما أن إجراء النموذج هو إجراء من إجراءات الخادم، فلا يلزم أن يكون مكوّن الصفحة الذي يستضيف النموذج مكوّن عميل. يعرض الخادم النموذج بصيغة HTML ثابتة، ولا تحتاج إلا الأجزاء التفاعلية، مثل عرض الأخطاء، إلى JavaScript على جانب العميل. ويؤدي ذلك إلى تقليل حجم حزمة العميل بدرجة كبيرة.

يعمل النموذج الذي يحتوي على action={serverAction} من دون تفعيل JavaScript. إذ ينفذ المتصفح إرسال POST قياسيًا لنموذج HTML، وينفذ الخادم الإجراء، ثم يعيد الصفحة المحدّثة. ويعني هذا التحسين التدريجي الحقيقي أن النموذج يظل قابلًا للاستخدام بسلاسة في جميع البيئات.

بعد أن يعدّل إجراء الخادم البيانات، يجب تحديث بيانات الصفحة المخزّنة مؤقتًا. ويؤدي استدعاء revalidatePath('/dashboard') داخل الإجراء إلى إبطال ذاكرة التخزين المؤقت في Next.js الخاصة بهذا المسار، مما يجعل الطلب التالي يجلب بيانات جديدة. وهذه هي الطريقة القياسية لإبقاء الصفحات المعروضة على الخادم محدّثة بعد عمليات التعديل.

يوفر revalidateTag('user-data') إبطالًا أكثر دقة لذاكرة التخزين المؤقت مقارنةً بـ revalidatePath. إذ تضعون وسمًا على استدعاءات الجلب باستخدام next: { tags: ['user-data'] }، ثم تبطلون جميع البيانات التي تحمل هذا الوسم دفعة واحدة من داخل إجراء الخادم، بغض النظر عن المسارات التي تعرض تلك البيانات.

يمكن لإجراءات الخادم إعادة توجيه المستخدم إلى صفحة جديدة بعد نجاح عملية التعديل، وذلك باستدعاء redirect('/success') من الوحدة next/navigation. وتُعالج عملية إعادة التوجيه على الخادم، مما يعني أن المتصفح يتلقى استجابة تنقّل صحيحة بدلًا من إعادة توجيه على جانب العميل.

لا تقتصر إجراءات الخادم على إرسال النماذج. فعند تشغيلها من خلال نقرات الأزرار أو غيرها من المحفزات التي لا تعتمد على النماذج، غلّفوا استدعاء الإجراء داخل startTransition(() => action(arg)). ويحدد ذلك عملية التنقّل باعتبارها انتقالًا، مما يتيح لـ React إبقاء واجهة المستخدم الحالية ظاهرة أثناء تنفيذ الإجراء على الخادم.

تُعد إجراءات الخادم المكان المناسب لإجراء التحقق من الصحة على الخادم. تحققوا من حقول FormData، وأعيدوا أخطاء التحقق إذا فشلت، ولا تتابعوا عملية التعديل إلا إذا كانت جميع الحقول صالحة. وتتكامل مكتبات مثل Zod جيدًا مع هذا الأسلوب؛ إذ تحللون FormData وفق مخطط ذي أنواع، ثم تعيدون خريطة الأخطاء عند الفشل.

ما الوسيط الذي يتلقاه إجراء الخادم عند تشغيله نتيجة إرسال نموذج؟

تستبدل إجراءات الخادم نمط fetch + مسار API المستخدم في عمليات تعديل النماذج. إذ تقبل الخاصية action في النموذج إجراءً من إجراءات الخادم مباشرةً، ويتلقى هذا الإجراء كائن FormData. وتعيد الإجراءات نتائج قابلة للتسلسل لتحديث واجهة المستخدم لدى العميل، وتدعم revalidatePath وrevalidateTag لإبطال ذاكرة التخزين المؤقت، كما تعمل تدريجيًا من دون JavaScript.