حذف کارگران سرویس کالسکه، حذف کارگران سرویس کالسکه

تنها کاری که معمولاً برای مقابله با یک سرویس کار باگ نیاز است، استقرار یک سرویس دهنده اولیه بدون عملیات است که بلافاصله بدون کنترل کننده رویداد 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 دارند ، و به این دلیل که آنها محتوای یک سرویس‌کار را برای به‌روزرسانی بررسی‌های بایت به بایت انجام می‌دهند. این پیش‌فرض‌ها امکان استقرار یک جایگزین بدون عملیات را برای یک سرویس‌کار باگ برای رفع سریع مشکل فراهم می‌کنند.