Usuwanie debugowanych instancji roboczych usługi

Czasem wdrażany jest skrypt service workg i występują problemy. Skrypt service worker może być na przykład przeanalizowany w momencie rejestracji i ukończony instalację. Jednak błędny kod w zdarzeniu fetch może powodować, że nie będzie on odpowiadać na żądania, co skutkuje wyświetleniem pustej strony. Możliwe też, że znaczniki strony są aktywnie przechowywane w pamięci podręcznej, a skrypcja service worker zwraca w przypadku kolejnych wizyt tylko nieaktualne odpowiedzi znaczników z instancji Cache.

mechanizm Service Worker może skutkować nieskutecznym działaniem, i straszny problem w witrynie produkcyjnej. Nie wszystko jednak stracone. Istnieją sposoby, by rozwiązać tę sytuację i wrócić na właściwą drogę.

Wdrażanie skryptu service worker bez działania

Aby rozwiązać problem z błędnym skryptem service worker, wystarczy zwykle wdrożyć podstawową Skrypt service worker no-op, który instaluje i aktywuje się 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 natychmiast zainstaluje i aktywuje się przez wywołanie self.skipWaiting() w wydarzeniu install. Opcjonalnie w zdarzeniu activate możesz wdrożyć dodatkowy kod, który spowoduje wymuszenie ponownego ładowania innych otwartych kart za pomocą wywołania WindowClient, które kontroluje skrypt service worker.

To bardzo ważne, aby skrypt service worker bez działań nie zawierał modułu obsługi zdarzeń fetch. Gdy skrypt service worker nie obsługuje żądań, są one przesyłane do przeglądarki tak, jakby nie było żadnego skryptu service worker. Po wdrożeniu skryptu service workg bez działania można naprawić i wdrożyć później jako aktualizację.

Takie podejście działa m.in. dlatego, że przeglądarki stosują silne środki ochrony przed umieszczaniem mechanizmów Service Worker w pamięci podręcznej HTTP oraz dlatego, że przeprowadzają one sprawdzanie pod kątem aktualizacji zawartości mechanizmu Service Worker z użyciem bajtów. Te wartości domyślne umożliwiają wdrożenie bezobsługowego rozwiązania zastępującego błąd w skrypcie usługi, aby szybko rozwiązać problem.

Dodatkowe działania, które należy podjąć

Wdrożenie skryptu service worker bez działania powinno wystarczyć do zneutralizowania błędu. ale w razie potrzeby można podjąć dodatkowe działania.

Co zrobić, jeśli nie znasz adresu URL starego skryptu service worker?

Czasami URL zainstalowanego wcześniej mechanizmu Service Worker jest nieznany. Przyczyną może być to, że ma ona różne wersje (np. nazwa pliku zawiera hasz). W takim przypadku może być trudne wdrożenie skryptu service worker bez działania pasującego 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 będą pamiętać każdego hasza dla każdej wdrożonej wersji skryptu service worker.

Na szczęście wraz z żądaniem skryptu service worker wysyłany jest pomocny nagłówek żądania HTTP: Service-Worker Na serwerze WWW odszukaj ten nagłówek i przechwyć żądanie, aby udostępnić skrypt service worker bezobsługowy. Sposób wykonania tego zadania zależy od używanego serwera WWW i stosu backendu, dlatego zapoznaj się z dokumentacją języka.

Jeśli chodzi o przyszłe wdrożenia mechanizmów Service Worker, zachowaj nazwy zasobów bez wersji (np. sw.js). Dzięki temu wszystko później nie będzie się znacznie skomplikować.

Ustaw nagłówek Clear-Site-Data

Niektóre przeglądarki wyrejestrują wszystkie mechanizmy Service Worker dla punktu początkowego, jeśli Ustawiono nagłówek odpowiedzi Clear-Site-Data z wartością 'storage'. Przy takim podejściu należy jednak pamiętać o kilku kwestiach:

• Pamiętaj, że spowoduje to usunięcie całej pamięci powiązanej źródła. Obejmuje to localStorage, IndexedDB, sessionStorage i inne miejsce na dane (ale nie pamięć podręczną HTTP źródła).
• Ten nagłówek nie jest obsługiwany we wszystkich przeglądarkach.

Obsługa tego nagłówka nie jest całkowita, więc nie można polegać wyłącznie na nim do rozwiązania problemu. Dlatego najlepiej jest traktować Clear-Site-Data jako działanie, które należy wykonać oprócz wdrożenia skryptu service worker bez działania.

Uszkodzenia nie są trwałe

Działanie zakłócone przez skrypt usterki, zwłaszcza w przypadku dużych i znanych witryn, może być przerażające, ale takie szkody są tymczasowe i odwracalne.

Jeśli w celu rozwiązania problemu konieczne jest wdrożenie skryptu service worker bez działania, by znaleźć przyczynę problemu. W przyszłości upewnij się, że skrypt service worker obsługuje tylko te żądania, do których powinien. Często testuj testy na etapie przejściowym i wdrażaj aktualizacje tylko wtedy, gdy będą wiarygodne.