نماذج المعاملات باستخدام React 19

تُعدّ النماذج نقطة التقاء بين الدقة وثقة المستخدم. يُدخل المستخدم البيانات في الحقول ثم ينقر على زر الإرسال، متوقعًا أن تُحفظ البيانات التي أدخلها وتُدقّق وتُؤكّد بدقة. مع ذلك، في العديد من تطبيقات React ، يُصمّم الإرسال كحدث واحد مُعطِّل: setisSubmitting لتفعيل صحيح، قم بتعطيل كل شيء، وانتظر خادم، ثم قم إما بإعادة ضبط نموذج أو عرض خطأ.

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

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

تكمن المشكلة الأساسية في البنية. تتعامل التطبيقات التقليدية مع عملية الإرسال كأثر جانبي يتم تفعيله بواسطة زر. يتم تغيير الحالة في أماكن متعددة. علامات مثلisSubmitting ،hasError ، وisSuccess تصبح قيمًا منطقية غير مترابطة. لا يوجد حد فاصل واحد للمعاملة يحدد المرحلة التي وصل إليها الإرسال. نختزل عملية متعددة المراحل إلى علامة واحدة ونسأل: هل يتم إرسال نموذج ؟ بينما السؤال الحقيقي هو: ما هي مرحلة المعاملة النشطة حاليًا؟

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

يقدم React 19 عناصر أساسية تسمح لنا بتنظيم عملية الإرسال كعملية عرض منسقة بدلاً من مجموعة من معالجات الأحداث.useActionState يوفر حدودًا مستقرة لدورة الحياة مرتبطة بإجراء غير متزامن.useOptimistic يُتيح هذا النظام عرض واجهة المستخدم بشكل افتراضي قبل التأكيد. كما تُتيح عمليات الانتقال إمكانية استكمال عمليات التأكيد غير العاجلة دون حجب تحديثات النوايا العاجلة.

بدلاً من السؤال عما إذا تم تقديم نموذج ، نطرح أسئلة أكثر دقة.

• ما هي الدولة ذات السلطة؟

• ما هو التفاؤل؟

• ما الذي لا يزال في الجو؟

• ما الذي يجب إلغاؤه إذا رفض خادم الإجراء؟

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

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

دورة حياة نموذج التفاعلي: النية، والتوقع، والالتزام

يفصل نموذج المعاملاتي بين النية والتوقع المتفائل والالتزام الموثوق به بحيث تظل واجهة المستخدم صحيحة في ظل زمن الاستجابة وإعادة المحاولات والتفاعلات المتزامنة.

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