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

في بعض الأحيان يتم نشر عامل خدمات الأخطاء، ثم تكون هناك مشكلات. على سبيل المثال، يمكن تحليل مشغّل الخدمات في وقت التسجيل وإكمال عملية التثبيت بنجاح. ومع ذلك، قد يؤدّي الترميز الذي يتضمّن عيوبًا في حدث 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 كإجراء يتم اتخاذه إلى جانب نشر مشغّل خدمات لا يعمل.

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

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

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