مختبر يعيد حالة النموذج بعد الرجوع للصفحة: مشاريع تخرج تطوير الويب

يكتب الطالب مسودة طلب، ينتقل إلى صفحة المراجعة، ثم يعود بزر المتصفح فيجد الحقول فارغة أو قديمة. في حالة أخرى تبقى قيمة لا ينبغي أن تبقى بعد تسجيل الخروج على جهاز مشترك. مشروع تخرج تطوير الويب ينشئ مختبراً يعيد هذه الخطوات ويفرق بين إعادة إنشاء الصفحة واستعادتها من back-forward cache. يوثق حدث pageshow حالات عرض الصفحة، ويشرح دليل Page Lifecycle بعض انتقالات التجميد والاستعادة. لا ينبغي افتراض أن كل رجوع يؤدي حدث load جديداً أو أن قيمة DOM تفسر وحدها مصدر الاستعادة.

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

حدد سياسة لكل نوع حقل

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

صمم صفحة harness قابلة لإعادة التهيئة

أنشئ routeين محليين: صفحة نموذج وصفحة مراجعة. ضع معرف run لكل تجربة، ثم سجل event name والوقت وحالة document visibility وحدث pageshow مع persisted إن كانت الخاصية متاحة. لا تحاول التحكم بقرار bfcache من صفحة الويب وحدها؛ أسباب عدم التخزين المؤقت قد تختلف بين المتصفحات والإضافات. أضف زر reset واضحاً يمسح fixtures كي تبدأ حالة جديدة، واعزل الاختبارات في origin منفصل عن أي حساب حقيقي. ما يجمعه harness هو trace تعليمي؛ لا يقرأ تاريخ التصفح أو محتوى صفحات خارج النطاق.

اختبر التسلسل الذي يراه المستخدم

املأ حقولاً معلومة، انتقل إلى صفحة المراجعة، استخدم الرجوع، ثم تقدم مرة أخرى وأعد التحميل. كرر السيناريو مع تبويب background ثم عودته، ومع إغلاق مؤقت للصفحة إذا كان المتصفح يدعم الاستعادة. سجل لكل حقل: القيمة قبل الانتقال وبعده، ومصدر القيمة المتوقع حسب سياسة التطبيق. تجنب screenshot وحده؛ يمكنه إظهار القيمة لكنه لا يبين إن كانت الصفحة restored أو rebuilt. أضف زر إلغاء ومرحلة تأكيد حتى تعرف إن كانت الحالة المحفوظة تتبع المسودة أم آخر نسخة مؤكدة.

افصل DOM عن التخزين المتعمد

قارن ثلاث نسخ: لا يوجد حفظ تطبيقي، تخزين مؤقت عبر sessionStorage، وحفظ خادمي وهمي ضمن fixture محلي. اشرح أن المتصفح قد يستعيد صفحة من bfcache، بينما التطبيق قد يعيد ملء القيمة من التخزين؛ ينبغي أن يميز التقرير بينهما. لا تحفظ كل حقل تلقائياً في localStorage، خصوصاً إذا احتوى معلومات شخصية أو بقي بعد إغلاق المتصفح. أضف زر clear draft ومدة احتفاظ محددة. HTML يحدد آليات التحكم في form controls، لكن سلوك الاستعادة النهائي قد يتأثر بالمتصفح والإعدادات وإضافاته.

معايير القبول وحالات الانقطاع

اكتب اختبارات: رجوع بعد إدخال نص، رجوع بعد تحديث قيمة، forward إلى المراجعة، reload، انقطاع اتصال عند حفظ المسودة، تسجيل خروج ثم back، وفتح الرابط مباشرة من جلسة جديدة. يجب ألا تظهر بيانات مستخدم سابق في سياق مختلف. تحقق من الحالات في متصفحين على الأقل وسجل الاسم والنسخة ونظام التشغيل، لأن السلوك قد يختلف. معيار النجاح لا يعني استعادة كل شيء؛ هو تحقيق سياسة معلنة لكل نوع حقل. إذا منعت الصفحة من bfcache بسبب listeners أو headers، وثق ذلك ولا تتجاوز حماية المتصفح لمجرد أن الاختبار يريد نتيجة أسهل.

راقب تجربة لوحة المفاتيح أيضاً

عند العودة، تحقق من موضع التركيز ورسالة توضح وجود مسودة أو عدمها، من دون نقل focus فجأة إلى حقل غير متوقع. اربط ملاحظات focus بأداة منفصلة عن خريطة انتقالات keyboard؛ نتيجة حفظ القيم لا تثبت سهولة استخدام النموذج. لا تعلن للمستخدم كل حقل عبر live region بعد restore، فقد يتحول ذلك إلى سيل من الرسائل لقارئ الشاشة. اختبر حقل required فارغاً وحالة خطأ كانت معروضة قبل الانتقال. اجعل سبب الاحتفاظ بالبيانات مفهوماً حتى لا يتفاجأ الشخص بما عاد إليه.

تسليم محدد لا وعد شامل

يشمل المشروع صفحات demo وscenario runner وسجل event ومصفوفة متصفحات وقرار الاحتفاظ لكل حقل. يمكن ربطه بـمشاريع التخرج وخدمة تطوير المواقع والتطبيقات. التقرير لا يثبت سلوك كل متصفح أو جهاز، ولا ينبغي استخدام بيانات حساسة لإظهار نجاح التجربة. النتيجة المفيدة هي أن يقدر المطور على إعادة حالة محددة، يعرف من أين جاءت القيمة، ويرى إن كان القرار مطابقاً لسياسة المنتج.