نماذج متعددة الخطوات ونماذج المعالج
تعلم كيفية هيكلة النماذج متعددة الخطوات كنظم عرض منسقة، حيث تستمر الحالة المشتركة، ويكون التقدم واضحًا، وتؤدي بوابات التحقق من صحة الخطوات المتعددة إلى عمليات الالتزام، ويتم جدولة انتقالات الخطوات دون هدم واجهة المستخدم الحالية.
غالبًا ما تُصبح النماذج متعددة الخطوات واجهة المستخدم الأكثر عرضةً للمخاطر في أي منتج، ليس لتعقيدها، بل لطول مدة التفاعل معها. قد يقضي المستخدم دقائق في إدخال البيانات عبر خطوات متعددة. ويتوقع أن تبقى البيانات المدخلة آمنة، وألا يُؤثر زر "الرجوع" على التقدم المُحرز، وأن يبقى نموذج سلسًا حتى في حال بطء التطبيق. وعندما لا تتحقق هذه التوقعات، يتلاشى الشعور بالثقة سريعًا لأن تكلفة الفشل باهظة: إعادة إدخال المعلومات، أو فقدان التقدم، أو التخمين بشأن ما حدث أثناء الانتقال بين الخطوات.
يبدأ التنفيذ النموذجي ببساطة. الخطوة الأولى عبارة عن مكون ذي حالة محلية. الخطوة الثانية عبارة عن مكون آخر ذي حالة محلية. يقوم العرض المشروط بتبديل أحدهما بالآخر. عند النقر على "متابعة"، يتم تحديث قيمة الخطوة وتتغير واجهة المستخدم. تتم إضافة التحقق من الصحة إلى معالج الإرسال. يتم عرض التقدم من خلال تسمية بسيطة "الخطوة 1 من 3". هذا مناسب للتدفقات الصغيرة.
تبدأ المشاكل عند وصول متطلبات الإنتاج. يستغرق التحقق غير المتزامن أو إعداد الخطوة التالية وقتًا أطول. تمت إضافة الحفظ الجزئي. تم إدخال خطوات اختيارية. تتطلب خطوة المراجعة جميع البيانات السابقة. يجب أن يحافظ التنقل للخلف على المدخلات السابقة. تعتمد القيم الافتراضية المحسوبة على الحقول السابقة. كل متطلب جديد يزيد من احتمالية تسبب تغيير الخطوة في تمزق واجهة المستخدم أو وميضها أو إعادة ضبطها.
هنا تظهر المشاكل للمستخدمين. قد يؤدي بطء الخطوة الثانية إلى اختفاء الخطوة الأولى فورًا، واستبدالها بخيار بديل، حتى وإن كان من الممكن إبقاء الخطوة الأولى قابلة للاستخدام. كما أن الرجوع للخلف قد يؤدي إلى إلغاء تحميل الخطوة الثانية ومسح حالتها المحلية، مما يؤدي إلى فقدان التقدم. وقد تظهر أخطاء التحقق فقط بعد الانتقال، مما يجبر المستخدم على الرجوع يدويًا. وقد ينتقل التركيز بشكل غير متوقع بسبب استبدال شجرة DOM. غالبًا ما يلجأ المطورون إلى حلول وقائية: مثل رفع الحالة بشكل متكرر، وتخزين الخطوات كاملة مؤقتًا، ومنع إلغاء التحميل، وعرض المكونات المخفية، أو تحويل الخطوات إلى مسارات للحفاظ على استقرار الحالة.
تكمن المشكلة الأعمق في البنية المعمارية. يُعامل المعالج كسلسلة من الصفحات التي تحل محل بعضها البعض. يُنتج هذا النموذج الذهني عدم استقرار لأن الاستبدال يعني إلغاء التحميل، وإلغاء التحميل يُدمر حالة الخطوة ويقطع الاستمرارية. لا يُنظر إلى المعالج على أنه تنقل بين الصفحات، بل كتفاعل واحد متواصل مع نقاط تفتيش.
يُقدّم React 19 طريقةً أفضل لنمذجة ذلك. فبدلاً من "تبديل الشاشات"، يُمكن التعامل مع المعالج كمشكلة تنسيق: ما هي واجهة المستخدم التي تمّت الموافقة عليها حاليًا، وما هي المهمة التي يتمّ تجهيزها لاحقًا، وما هي البيانات التي يجب أن تبقى بغض النظر عن الخطوة الظاهرة، وما هي قواعد التحقق التي يجب استيفاؤها قبل السماح لخطوة جديدة بالموافقة. عندما تتوافق المعالجات مع نموذج العرض والموافقة في React، يتوقف سلوك التحميل عن كونه أمرًا يُستهان به، ويصبح أمرًا يُمكن التحكم فيه.
يُظهر الرسم التخطيطي أعلاه هيكل نموذج واحد ثابت يمتلك جميع حالات نموذج . بداخله،Step A يتم الالتزام به حاليًا وهو مرئي. عندما يتقدم المستخدم،Step B يبدأ العرض في الخلفية بينماStep A يبقى تفاعليًا. بمجردStep B عندما يصبح جاهزًا، يقوم React بتثبيته، ويستبدلهStep A في انتقال واحد وهادئ. لا تتم إعادة ضبط الصدفة أو اختفاء الحالة في أي مرحلة.
خطوات المعالج هي حدود الالتزام، وليست شاشات
يكمن التحول الفكري مفتاح في التالي: لا يتعلق المعالج بإخفاء وإظهار المكونات، بل بالتحكم في وقت السماح لأجزاء واجهة المستخدم المختلفة بالاستمرار في العمل. تمثل كل خطوة حدًا للغرض، وليس حالة تطبيق جديدة. تتمثل مهمة React في الحفاظ على استقرار واجهة المستخدم الملتزمة بالفعل أثناء إعداد العمل الجديد.
في React 19، لم يعد العرض شيئًا نتصوره ذهنيًا على أنه "إعادة عرض كل شيء". بدلاً من ذلك، فكر من حيثrender المراحل وcommit المراحل. عندما ينتقل المستخدم من خطوة إلى أخرى، يمكننا تحديد ما إذا كان هذا الانتقال عاجلاً، أي يجب تغيير واجهة المستخدم فوراً، أو غير عاجل، أي يمكن أن تظل الخطوة الحالية مرئية أثناء تحضير الخطوة التالية. هذا التمييز بالغ الأهمية في النماذج، حيث يؤدي فقدان التركيز أو مسح المدخلات أو ظهور أخطاء التحقق إلى فقدان الثقة.
مفهوم آخر مهم هو ملكية الحالة. في تطبيقات المعالج الهش، تمتلك كل خطوة حالتها الخاصة. عند إلغاء تحميل الخطوة، تختفي تلك الحالة. يقوم React بما طلبناه منه بالضبط، لكن تصورنا الذهني خاطئ. في المعالج المنسق، تنتمي حالة نموذج طويلة الأمد إلى عنصر أب ثابت، بينما تصبح الخطوات عناصر عرض قابلة للعرض فوق تلك الحالة. يمكن للخطوات أن تظهر وتختفي؛ ولا تتم إعادة ضبط نموذج .
أخيرًا، فكّر في الحدود. يُعدّ حدّ الخطوة مكانًا مناسبًا للعرض المؤجل، أو التحقق من الصحة، أو حتى التحضير غير متزامن . يتيح لك نموذج التزامن في React 19 الانتقال بين الخطوات دون تعطيل واجهة المستخدم الحالية، طالما أنك تُصمّم المعالج حول الانتقالات بدلًا من التبديلات المباشرة.
ننتقل الآن من النموذج الذهني إلى مثال عملي. لا يهدف هذا الكود إلى توضيح كيفية بناء نموذج ، بل إلى إثبات أن تغييرات الخطوات هي قرار جدولة، وليست عملية تنقل.
مثال: المعالج كعرض منسق
يُقدّم هذا المثال نموذجًا لمعالج من خطوتين كعملية عرض منسقة، وليس كعملية تنقل بين الصفحات.
واجهة المعالج المستقرة (ملكية الحالة): يمتلك المعالج جميع بيانات نموذج طويلة الأمد، لذا فإن الانتقال بين الخطوات لا يعيد ضبط المدخلات أبدًا. ...