محاكي تحديث تطبيق الويب دون خلط الإصدارات: مشاريع تخرج تطوير الويب

بدأ الحادث بعد نشر إصدار جديد: مستخدم فتح الصفحة قبل دقائق، وآخر فتحها بعد النشر، وثالث عاد من offline. اختلفت ملفات HTML وJavaScript التي يراها كل تبويب، فظهر سلوك لا يمكن تفسيره من رقم الإصدار وحده. محاكي مشاريع تخرج تطوير الويب يعيد timeline لهذا الحادث ويبين waiting worker والصفحات التي ما زالت تحت تحكم النسخة السابقة. راجع MDN Service Worker API وشرح دورة حياة Service Worker.

مثال تبويبين وإصدارين

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

حدد لكل نافذة وقت فتحها، worker controller، ونسخة الأصول المحملة. عند وصول التحديث، سجل install ثم waiting، ولا تفترض أن التبويب المفتوح انتقل فوراً. أعد بناء الحادث زمنياً من منظور كل عميل. هذا ليس إبطالاً لذاكرة HTTP أو Redis: تلك طبقات أخرى لها مفاتيح وسياسات expiry مستقلة، ويمكن أن تظل قديمة حتى بعد انتقال العامل إلى نسخة جديدة.

اعرض الحالات كما تصفها المنصة

توثق وثائق Chrome عن دورة حياة Service Worker مراحل التثبيت والانتظار والتفعيل، وتحذر من أن التخطي المبكر للانتظار ونقل التحكم قد يؤثران في الصفحات المفتوحة. يوضح شرح MDN لاستخدام Service Workers متى يتفعل العامل الجديد وما دور skipWaiting وclients.claim، بينما تحدد مواصفة Service Workers سلوك الواجهة والمعيار. ابنِ العرض وفق حالة registration الفعلية ولا تخترع مرحلة جديدة لتسهيل الرسم.

منع خلط ملفات واجهة متعارضة

المشكلة المهمة ليست وجود عاملين فقط، بل أن HTML قديم يطلب chunk حُذف من نشر جديد. اربط كل build ببيان assets ذي أسماء مبصومة، واحتفظ بالأصول القديمة فترة انتقال مناسبة في بيئة الاختبار. يمكن أن تعرض اللوحة إصدار HTML والعامل والملفات التي تم تحميلها. إذا وصل طلب إلى ملف غير موجود، سجل fallback المستخدم وأظهره للمطور. لا تمسح كل cache باسم واحد أثناء التفعيل قبل فهم الصفحات المفتوحة؛ واجعل تنظيف النسخ السابقة خطوة يمكن اختبارها بعد التأكد أن العامل الجديد استحوذ على الملفات المطلوبة.

جهز نسختين قابلتين للتبديل

أنشئ صفحة بسيطة تعرض build ID وقائمة أصولها، وعامل خدمة يخزن ملفات v1. افتح تبويبين؛ ثم قدم worker جديداً مع ملف JS متغير واسمه أو hash مختلف. يسجل المحاكي installing وwaiting وactive، ويعرض controller لكل صفحة. اجعل زر «تفعيل الآن» خياراً صريحاً يحاكي إرسال رسالة إلى العامل، لا استدعاءً مخفياً في كل تثبيت. في الإصدار الأول، ضع محتوى ثابتاً وبطاقات تجريبية بدلاً من بيانات مستخدمين. لا تستخدم عناوين العامل المختلفة بلا داع، لأن تغيير URL العامل قد يغير طريقة اكتشاف تحديثه.

اختبارات القبول والفشل

خط الأساس هو دورة تحديث افتراضية بلا skipWaiting، ثم قارنها بقرار تفعيل فوري بعد رسالة المستخدم. اختبر فشل تنزيل asset أثناء install، تبويباً قديماً مفتوحاً، انقطاع الشبكة، cache مفقوداً، إعادة فتح الصفحة بعد التفعيل، وتحديثاً لا يغير ملفات العامل. يجب ألا يظهر إصدار «جاهز» إذا لم يكتمل تثبيت الملفات، وأن يستطيع المستخدم إكمال عمله قبل reload إن كانت الصفحة تحتوي تغييرات محلية. سجل عدد حالات النسخة المختلطة وطلبات الملفات الفاشلة ووقت الانتقال، ولا تقيس النجاح بمجرد أن الحدث activate وقع.

اختبر عميلين مفتوحين أثناء النشر، وعميل offline، وفشل تنزيل asset جديد، ثم عودة الاتصال. راقب أن HTML لا يشير إلى chunk غير موجود في cache وأن الرجوع إلى الإصدار السابق ممكن وفق سياسة المشروع. افصل نتائج Cache API عن HTTP cache في التقرير، ولا تقدم clear-site-data كحل عام قبل تحليل الأثر على بيانات المستخدم.

اختيار سلوك التحديث قرار منتج

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