Czasami wdrażany jest nieprawidłowy skrypt service worker,
a potem pojawiają się problemy.
Na przykład skrypt service worker może zostać przeanalizowany podczas rejestracji i zakończyć instalację.
Jednak nieprawidłowy kod w zdarzeniu fetch
może sprawić, że nie będzie on odpowiadać na żądania, co doprowadzi do wyświetlenia pustej strony. Inną możliwą przyczyną jest agresywne zapisywanie znaczników strony w pamięci podręcznej, przez co w przypadku kolejnych wizyt skrypt service worker zwraca tylko nieaktualne znaczniki z instancji Cache
.
Skrypt service worker może się odrobić na wiele sposobów, co stanowi straszny problem w witrynie produkcyjnej. Mimo to nie wszystko stracone. Istnieją sposoby, aby rozwiązać problem i wrócić na właściwe tory.
Wdrażanie skryptu service worker no-op
Żeby radzić sobie z błędnym mechanizmem Service Worker, wystarczy wdrożyć podstawowy skrypt service worker no-op, który instaluje się i aktywuje natychmiast bez modułu obsługi zdarzeń 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);
});
});
});
Ten skrypt service worker zainstaluje i aktywuje natychmiast, wywołując metodę self.skipWaiting()
w zdarzeniu install
.
Opcjonalnie można wdrożyć w zdarzeniu activate
dodatkowy kod, aby wymusić ponowne załadowanie wszystkich innych otwartych kart za pomocą interfejsu WindowClient
sterowanego przez skrypt service worker.
Bardzo ważne jest, aby skrypt service worker no-op nie zawierał modułu obsługi zdarzeń fetch
.
Gdy skrypt service worker nie obsługuje żądań, są one przekazywane do przeglądarki tak, jakby nie było żadnego skryptu service worker.
Po wdrożeniu skryptu service worker bez działania można go naprawić i wdrożyć jako aktualizację później.
To podejście działa częściowo dlatego, że przeglądarki mają silne zabezpieczenia przed umieszczaniem skryptów service worker w pamięci podręcznej HTTP oraz przeprowadzają kontrole bajtów zawartości zawartości skryptu service worker pod kątem aktualizacji. Te ustawienia domyślne umożliwiają szybkie wdrożenie rozwiązania, które nie wymaga działania, aby rozwiązać problem z błędnym skryptem service worker.
Dodatkowe działania, które należy podjąć
Wdrożenie skryptu service worker no-op powinno wystarczyć do zneutralizowania błędu. W razie potrzeby możesz jednak podjąć dodatkowe działania.
A jeśli nie znasz adresu URL starego skryptu service worker?
Czasami adres URL wcześniej zainstalowanego skryptu service worker jest nieznany. Przyczyną może być jego obsługa wersji (np. nazwa pliku zawiera znak #). W tym przypadku może być wyzwaniem wdrożenie skryptu service worker no-op, który pasuje do adresu URL każdego starego skryptu service worker, który może być zarejestrowany. Jest to niezgodne ze sprawdzonymi metodami, ponieważ deweloperzy prawdopodobnie nie zapamiętają wszystkich haszów z każdej wdrożonej wersji skryptu service worker.
Na szczęście z żądaniem skryptu skryptu service worker wysyłany jest pomocny nagłówek żądania HTTP: Service-Worker
.
Na serwerze WWW sprawdź ten nagłówek i przechwyć żądanie, by zamiast tego udostępnić skrypt service worker no-op.
W zależności od użytego serwera WWW i stosu backendu zapoznaj się z dokumentacją danego języka.
Jeśli chodzi o przyszłe wdrożenia mechanizmów Service Worker, trzymaj się nazw zasobów, które nie mają wersji (np. sw.js
).
Dzięki temu później sprawa będzie znacznie łatwiejsza.
Ustaw nagłówek Clear-Site-Data
Niektóre przeglądarki wyrejestrują wszystkie mechanizmy Service Worker ze źródła, jeśli ustawiony jest nagłówek odpowiedzi Clear-Site-Data
o wartości 'storage'
.
Należy jednak pamiętać o kilku kwestiach:
- Pamiętaj, że spowoduje to wyczyszczenie całego miejsca na dane z powiązanego źródła. Obejmuje to
localStorage
, IndexedDB,sessionStorage
i inne rodzaje pamięci masowej (ale nie pamięć podręczną HTTP źródła). - Nie wszystkie przeglądarki obsługują ten nagłówek.
Ponieważ obsługa tego nagłówka nie jest całkowita, nie można polegać tylko na nim w rozwiązaniu problemu.
Dlatego najlepiej jest traktować Clear-Site-Data
jako środek oprócz wdrożenia skryptu service worker no-opera.
Uszkodzenie nie jest trwałe
Źle zakłócone działanie użytkownika przez podejrzany skrypt service worker (zwłaszcza w przypadku dużych i znanych witryn) może być niepokojące – ale szkody są tymczasowe i odwracalne.
Jeśli w celu rozwiązania sytuacji konieczne jest wdrożenie skryptu service worker no-opera, poświęć trochę czasu, aby dowiedzieć się, co poszło nie tak. W przyszłości upewnij się, że skrypt service worker będzie obsługiwać tylko te żądania, które powinien. Często testuj aktualizacje na etapie przejściowym i wdrażaj aktualizacje tylko po uzyskaniu pewności siebie.