دورة TanStack Form الكاملة › دورة TanStack Form الكاملة 1 / 1 السابق التالي

ملاحظات حول إرسال النموذج (Notes on Form Submission)

الدرس 14 من 21 · دورة TanStack Form الكاملة · 6 دقيقة و11 ثانية

الفيديو الأصلي باللغة الإنجليزية. إذا تعذّر تشغيله هنا، شاهده على موقع المؤلف. التفريغ النصي العربي الكامل أدناه.

مستودع شيفرة هذا الدرس

الفرع: submission

[00:00] فلنتحدث قليلًا عن إرسال نموذجنا (submission) قبل أن نرتّب الأمور في نموذجنا. فكما رأينا بالفعل أنّه في نموذجنا، عندما نستخدم الخُطّاف (hook) useForm، يكون لدينا هذا الخيار (option) onSubmit، ويمكننا أن نفعل شيئًا ما عندما نرسل نموذجنا

[00:16] بقيمنا. فلنفتح console لدينا هنا، ولنحاول إرسال نموذجنا من خلال امتلاك نموذج صالح هنا. سأكتب أشياء هنا فقط. فلنزِل أيضًا هذه الطباعة (log) المزعجة من هنا.

[00:32] إذًا سأوافق على الشروط (acceptTerms) وأظنّ أنّه ينبغي أن نكون الآن قادرين على الإرسال.

[00:39] إذًا عذرًا — أدركتُ أنّه لا يمكننا إرسال نموذجنا لأنّه في المخطط (schema) لدينا قواعد للتحقق من الصحة (validation) تخصّ بريدنا الإلكتروني. ففي هنا لدينا أنّ email ينبغي أن يكون بريدًا إلكترونيًا، ولدينا أيضًا city وstate وهلمّ جرا. وإنّنا في الواقع لا نمتلك

[00:53] هذه الحقول هنا بعد. ولهذا نحصل على أخطاء التحقق من الصحة رغم أنّنا لا نستطيع رؤيتها. فأعتذر عن ذلك. لكن في هذه اللحظة، سأقتصر على عدم تمرير email وعدم تمرير هذه الأشياء عدا street التي

[01:07] لدينا حقل لها.

[01:09] وأيضًا في المخطط لدينا أظنّ — نعم، لدينا email كاختياري (optional). إذًا الآن لا ينبغي أن نحصل على خطأ إن لم نمرّر email، كما أنّ هذه الأشياء — city وstate وهلمّ جرا — اختيارية أيضًا. فإذًا الآن ينبغي أن نكون

[01:23] قادرين على إرسال نموذجنا. فسأكتب أي شيء الآن فقط. والآن إن أرسلت، فينبغي أن نحصل — عذرًا، يبدو أنّ لديّ خطأً ما. الآن إن أرسلت، فينبغي أن يكون لدينا أشياؤنا في console لدينا، وهي قيم النموذج.

[01:42] غير أنّه أمر بالغ الأهمية ينبغي الانتباه إليه هنا هو أنّه إن كنت على معرفة بـ Zod فأنت تعلم أنّ مدخل (input) Zod يمكن أن يختلف عن مخرَج (output). فحين يكون لدينا كائن (object) ما نحتاج إلى التحقق من صحته ونستخدم Zod للتحقق من

[01:56] صحته، فبعد التحقق من الكائن يمكن لـ Zod في الواقع أن يُنتج مخرَجًا مختلفًا.

[02:01] غير أنّه ما نحصل عليه هنا هو المدخل لا المخرَج. وفلأعطيك فعلًا مثالًا: عندما نُعرِّف مخطط Zod يمكن أن يكون لدينا أشياء قادرة على تحويل المدخل إلى شيء مختلف. فمثلًا لديك هذه

[02:16] دالة coerce التي يمكنها إكراه سلسلة (string) إلى عدد (number) وهلمّ جرا. ولدينا تحويلات (transforms) أيضًا. فربما هنا، بعد المخطط لدينا، يمكن أن يكون لدينا transform. ويمكننا أن نفعل شيئًا ما لتحويل مدخلنا عندما نتحقق من

[02:30] صحة المخطط لدينا. فلنفترض مثلًا هنا. في التحويل (transform) تتوفّر لنا بياناتنا أيضًا داخل دالة (function)، ويمكننا أن نفعل شيئًا ما سيحوّل بياناتنا. ففي هنا سأعيد على الأرجح كائنًا آخر يضمّ

[02:42] لنقل كل بياناتنا. غير أنّه بالنسبة إلى المهارات لدينا، فلنقل أنّنا بدلًا من امتلاكنا مصفوفة الكائنات (objects)، نحتاج إلى أن نملك مصفوفة معرّفات (ids) لمهاراتنا. فإذًا يمكننا أن نأخذ بياناتنا — data.skills — ونستدعي map، ثم لكل

[02:58] مهارة، يمكننا أن نعيد id فقط.

[03:02] إذًا بفعل هذا وإرسال نموذجنا مرة أخرى، في المهارات لدينا، وكما ترى، نحصل مع ذلك على مصفوفة الكائنات لأنّ هذا هو المدخل. فإن احتجنا إلى الحصول على مخرَج Zod، فسنحتاج إلى فعل ذلك بأنفسنا. فإذًا في دالة onSubmit لدينا،

[03:18] نحصل هنا على بعض الأخطاء بسبب التحويل الذي قمنا به، لكننا سنزيله بعد قليل. ففي دالة onSubmit لدينا نحتاج إلى تحليل (parse) مدخلنا بأنفسنا باستخدام Zod. فإذًا يمكننا استخدام formSchema.parse

[03:31] ثم تمرير قيمنا هنا. وبهذا — عذرًا — console.log. وبهذه الطريقة سنحصل على مخرَج Zod. فإذا حفظت ثم أرسلت الآن، نحصل على المدخل الذي يضمّ مصفوفة الكائنات للمهارات، وعلى المخرَج

[03:47] من Zod الذي يضمّ الآن مصفوفة المعرّفات. فاحفظ هذا في ذهنك: عندما تستخدم Zod وتحصل على القيمة هنا عند الإرسال، فالقيمة هي المدخل لا المخرَج من Zod. لكن فلنزِل الآن هذا transform الذي

[04:01] لأنّه يتسبّب في بعض الأخطاء.

[04:04] ولدينا أيضًا خطأ ما في مكانٍ ما هنا.

[04:08] نعم — من الـ listeners، إنّنا لا نستخدم هذا. فلنزِله أيضًا في الواقع.

[04:14] وأمرّ آخر وددتُ أن أذكره عند الإرسال هو أنّه يمكننا تمرير بعض البيانات الوصفية (metadata) عندما نرسل نموذجنا. ففي هنا تذكّر أنّه عندما نرسل نموذجنا نستدعي form.handleSubmit.

[04:26] عندما نستدعي form.handleSubmit. يمكننا تمرير أي كائن اعتباطي (arbitrary) هنا. يمكننا تمرير بعض البيانات الوصفية.

[04:33] فلنفعل ذلك الآن بـ key وقيمة (value) فقط. وعندما نرسل نموذجنا، سنحصل في دالة onSubmit لدينا على أي شيء نمرّره هنا. ففي هنا نحصل على meta أيضًا.

[04:47] فلنطبع إذًا هذا عبر console.log ولنحفظ. والآن إن أرسلنا، فينبغي أن نحصل على المفتاح وقيمته هنا. وهذا يمكن أن يكون مفيدًا. فعلى سبيل المثال، فلنقل أنّه عند إرسالك نموذجك، يمكنك أن ترسله عبر أزرار إرسال متعددة. فإذًا

[05:02] ربما يمكنك أن تملك زر الإرسال (submit button) هذا هنا. فلنقل أنّ هذا يحفظ النموذج مثلًا. ولنقل أنّ لديك آخرًا. فإذًا فلنلفّ كل شيء فعلًا بـ div هنا. ولنقل أنّ لديك زرًا آخر ينبغي أن

[05:17] يحفظ ثم ربما يعود إلى الوراء؛ أي save and go back.

[05:23] وبناءً على الزر الذي نقرتَ عليه، يلزمنا معرفة هذه المعلومة. يلزمنا أن نعرف أيّ زر نُقرّ في دالة الإرسال (submit) لدينا، وفي نداء الإرسال (submit callback) لدينا، لكي تتمكّن من اتخاذ إجراء بعد إرسال نموذجك. فإذًا يمكننا

[05:35] أن نضيف ربما معالج onclick هنا، وعند النقر يمكننا أن نستدعي من هنا form.handleSubmit بدلًا من استدعاء form.handleSubmit في النموذج نفسه عندما نرسل نموذجنا، وهنا يمكننا تمرير بياناتنا.

[05:50] فلنقل ربما submitAction فلنقل save، ولنفعل الأمر نفسه، ويجب أن يكون هذا ربما go back أو شيئًا من هذا القبيل. فبتوفّر هذا، إن نقرنا على save فسنحصل على submitAction بقيمة save. وإن نقرنا على save

[06:07] ثم go back، فينبغي أن نحصل على submitAction بقيمة go back.