إزالة عربات موظفي الخدمات التي تحتوي على عربات

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

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

نشر عامل خدمة بلا عمليات

فكل ما يتطلبه الأمر عادةً للتعامل مع عامل خدمة يحمل أعطالاً هو نشر نظام عامل الخدمات no-op الذي يثبِّت وينشط فورًا بدون معالج أحداث fetch:

// sw.js

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

سيتم تثبيت مشغّل الخدمات هذا وتفعيله في الحال من خلال الاتصال. self.skipWaiting() في فعالية install. اختياريًا، يمكن نشر رمز إضافي في حدث activate لفرض إعادة تحميل أي علامات تبويب مفتوحة أخرى باستخدام WindowClient الذي يتحكم فيه عامل الخدمات.

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

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

التدابير الإضافية التي يجب اتخاذها

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

ماذا لو كنت لا تعرف عنوان URL الخاص بعامل تشغيل الخدمات القديم؟

أحيانًا يكون عنوان URL لمشغِّل الخدمات الذي تم تثبيته مسبقًا غير معروف. قد يرجع ذلك إلى أنّه تم تحديد إصدار له (على سبيل المثال، يحتوي على تجزئة في اسم الملف). وفي هذه الحالة، قد يكون من الصعب نشر مشغّل خدمات غير متاح ويتطابق مع عنوان URL لكل مشغّل خدمات قديم قد يكون مسجَّلاً. يخالف ذلك أفضل الممارسات. لأنّ المطوّرين على الأرجح لن يتذكّروا كل تجزئة لكل إصدار من إصدارات مشغّل الخدمات تم نشره.

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

بالنسبة إلى عمليات النشر المستقبلية لمشغّلي الخدمات، يجب الالتزام بأسماء مواد العرض التي لم يتم إصدارها بعد (مثل sw.js). وهذا سيجعل الأمور أقل تعقيدًا بكثير لاحقًا.

ضبط عنوان Clear-Site-Data

ستلغي بعض المتصفحات تسجيل جميع مشغّلي الخدمة في مصدر ما إذا تم ضبط عنوان الاستجابة Clear-Site-Data بقيمة 'storage'. ومع ذلك، هناك بعض الأمور التي ينبغي أن تكون على دراية بها باستخدام هذا النهج:

  • احذر من أنّ هذا الإجراء سيؤدي إلى محو كل مساحة التخزين للمصدر المرتبط. يشمل ذلك localStorage وIndexedDB وsessionStorage ومساحة تخزين أخرى (ولكن ليس ذاكرة التخزين المؤقت HTTP الخاصة بالمصدر).
  • هذا الرأس غير متاح في بعض المتصفّحات.

نظرًا لأن دعم هذا العنوان ليس شاملاً، لا يمكن الاعتماد عليه وحده لحل المشكلة. وبالتالي، من الأفضل النظر إلى Clear-Site-Data كإجراء يجب اتخاذه بالإضافة إلى نشر مشغّل خدمات بدون عمليات.

الضرر غير دائم

قد يكون الأمر مخيفًا عندما يتم تعطيل تجربة المستخدم بواسطة عامل خدمة به أعطال - خاصة بالنسبة إلى مواقع الويب الكبيرة والمعروفة جيدًا - ولكن الضرر مؤقت ويمكن عكسه!

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