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

گاهی اوقات یک کارگر سرویس کالسکه مستقر می شود و سپس مشکلاتی به وجود می آید. به عنوان مثال، یک سرویسکار ممکن است در زمان ثبت نام تجزیه شود و نصب با موفقیت کامل شود. با این حال، کد باگ در یک رویداد fetch ممکن است باعث شود که به درخواست‌ها پاسخ ندهد و در نتیجه صفحه خالی ایجاد شود. احتمال دیگر این است که نشانه‌گذاری صفحه به‌شدت در حافظه پنهان ذخیره می‌شود، و یک سرویس‌گر فقط برای بازدیدهای بعدی، پاسخ‌های نشانه‌گذاری قدیمی را از یک نمونه Cache برمی‌گرداند.

راه های زیادی وجود دارد که یک کارگر خدماتی می تواند نتیجه معکوس داشته باشد، و این مشکل ترسناکی است که در وب سایت تولیدی وجود دارد. با این حال، همه چیز از دست رفته نیست. راه هایی برای اصلاح وضعیت و بازگشت به مسیر وجود دارد.

یک کارگر خدمات بدون عملیات مستقر کنید

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

در مورد استقرار کارکنان خدمات آتی، از نام دارایی های بدون نسخه استفاده کنید (مثلا sw.js ). این امر باعث می شود که بعداً اوضاع بسیار کمتر پیچیده شود.

یک هدر Clear-Site-Data تنظیم کنید

اگر سرصفحه پاسخ Clear-Site-Data با مقدار 'storage' تنظیم شود، برخی از مرورگرها همه سرویس‌دهندگان را برای یک مبدا لغو ثبت می‌کنند. با این حال، چند نکته وجود دارد که در این رویکرد باید از آنها آگاه بود:

• هشدار داده شود که با این کار تمام فضای ذخیره سازی برای مبدا مرتبط پاک می شود. این شامل localStorage ، IndexedDB، sessionStorage ، و سایر فضای ذخیره‌سازی است (اما نه حافظه پنهان HTTP برای مبدا).
• این هدر در همه مرورگرها پشتیبانی نمی شود .

از آنجایی که پشتیبانی از این هدر کامل نیست، نمی توان به تنهایی برای رفع مشکل به آن اعتماد کرد. بنابراین بهتر است Clear-Site-Data به عنوان اقدامی در کنار استقرار یک کارگر خدمات بدون عملیات مشاهده کنید.

آسیب دائمی نیست

زمانی که تجربه کاربری توسط یک کارمند خدمات حشره دار مختل شود، می تواند ترسناک باشد - به خصوص برای وب سایت های بزرگ و شناخته شده - اما آسیب موقت و قابل برگشت است!

اگر لازم است یک کارگر خدمات بدون عملیات برای رفع این وضعیت مستقر شود، بعد از این واقعیت زمان بگذارید تا دقیقا متوجه شوید که چه مشکلی رخ داده است. در آینده، اطمینان حاصل کنید که یک کارگر خدماتی تنها به درخواست هایی که انتظار می رود رسیدگی می کند. مرتباً در مرحله‌بندی آزمایش کنید و فقط در صورت اطمینان از به‌روزرسانی‌ها استفاده کنید.