Rozwiązywanie problemów i rejestrowanie

Debugowanie skryptu service worker nie jest łatwe. Masz do dyspozycji cykl życia, aktualizacje, pamięć podręczną i interakcje między tymi wszystkimi elementami. Na szczęście, tak jak zespół Workbox ułatwia tworzenie mechanizmów Service Worker, ułatwia też debugowanie za pomocą informacyjnego logowania. Na tej stronie omówimy niektóre z dostępnych narzędzi do debugowania oraz dowiesz się, jak działa rejestrowanie w Workbox i jak można je skonfigurować.

Dostępne narzędzia do rozwiązywania problemów

W przeglądarce dostępnych jest wiele narzędzi do debugowania i rozwiązywania problemów podczas programowania skryptu service worker. Oto kilka zasobów, które pomogą Ci rozpocząć pracę z wybraną przeglądarką.

Chrome i Edge

Chrome (i ostatnie wersje Edge oparte na silniku Blink) mają rozbudowany zestaw narzędzi dla programistów. Niektóre z tych narzędzi – zwłaszcza w Narzędziach deweloperskich w Chrome – zostały wspomniane wcześniej w tej dokumentacji, ale warto dowiedzieć się więcej:

Firefox

Użytkownicy przeglądarki Firefox mogą skorzystać z tych zasobów:

Safari

W Safari dostępny jest obecnie bardziej ograniczony zestaw narzędzi dla programistów do debugowania mechanizmów Service Worker. Więcej informacji na ten temat znajdziesz w tych zasobach:

Logowanie skrzynki roboczej

Najważniejszym usprawnieniem dla programistów w Workbox jest rejestrowanie informacyjne. Gdy logowanie jest włączone, Workbox rejestruje prawie całą swoją aktywność w charakterystyczny i funkcjonalny sposób.

Zrzut ekranu z komunikatami logowania Workbox w konsoli Narzędzi deweloperskich w Chrome. Komunikaty logowania różnią się od zwykłych logów konsoli plakietką Workbox. Każdą wiadomość możesz rozwinąć, aby uzyskać dodatkowe informacje na potrzeby debugowania.

Kompilacje deweloperskie Workbox domyślnie włączają logowanie, a kompilacje produkcyjne je wyłączają. Etapy przełączania się między kompilacjami deweloperskimi a produkcyjnymi są różne w zależności od tego, czy tworzysz niestandardowy pakiet Workbox czy używasz kopii wstępnie połączonej w workbox-sw.

Z usługą pakietową lub bez niej

Pakiety to narzędzia, które pobierają kod z poszczególnych modułów i tworzą dane wyjściowe JavaScript gotowe do uruchomienia w przeglądarce. Jeśli korzystasz z usługi pakowania, możesz też użyć przeznaczonej do tego pakietu wtyczki Workbox, która ułatwia zapisywanie w pamięci podręcznej, np. workbox-webpack-plugin. Możesz też połączyć logikę buforowania środowiska wykonawczego Workbox. W obu przypadkach na logowanie w Workbox ma wpływ ustawienie trybu produkcyjnego w konfiguracji usługi pakującej:

  • W pakiecie internetowym opcję konfiguracji mode można ustawić na 'production' lub 'development'. Na podstawie tej wartości workbox-webpack-plugin będzie korzystać z logowania w środowisku produkcyjnym lub programistycznym w Workbox.
  • W przypadku podsumowania usługa rollup-plugin-workbox akceptuje opcję konfiguracji mode, która ma też wpływ na to, czy Workbox będzie rejestrować cokolwiek w konsoli. Jeśli korzystasz z usługi Rollup bez wtyczki specyficznej dla Workbox, musisz skonfigurować @rollup/plugin-replace tak, aby zastępowała wartość process.env.NODE_ENV wartością 'development' lub 'production'.

Załóżmy, że w fazie programowania należy zastąpić domyślne zachowanie logowania. W takim przypadku odpowiednia wtyczka Workbox do usługi pakietu SDK umożliwia zakodowanie na stałe preferencji debugowania dzienników w jej konfiguracji. Możesz na przykład wyłączyć logowanie w Workbox przy użyciu opcji mode w workbox-webpack-plugin dla metody GenerateSW.

Bez usługi tworzącej pakiet

Narzędzia do tworzenia pakietów są świetne, ale nie każdy projekt ich wymaga. Jeśli chcesz dodać Workbox do projektu, który nie korzysta z usługi tworzenia pakietów, dobrym rozwiązaniem będzie workbox-sw.

Moduł workbox-sw upraszcza wczytywanie innych modułów Workbox (np. workbox-routing, workbox-precaching itp.) z sieci CDN. To, czy uda się załadować pakiet deweloperski czy produkcyjny, zależy od adresu URL używanego do uzyskania dostępu do aplikacji internetowej. Domyślnie workbox-sw wczytuje wersję deweloperską Workbox, jeśli Twoja aplikacja internetowa działa w http://localhost, i wersję produkcyjną w pozostałych przypadkach.

Możesz zastąpić działanie domyślne, wywołując metodę setConfig w Workbox, aby ustawić opcję debug na true:

// Load workbox-sw from a CDN
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

// This must come before any other workbox.* methods.
workbox.setConfig({
  debug: true
});

// Now use workbox.routing.*, workbox.precaching.*, etc.

Wyłącz logowanie w kompilacjach programistycznych w dowolnym przepływie pracy

Niezależnie od tego, czy korzystasz z narzędzia do tworzenia pakietów, możesz wyłączyć wszystkie kompilacje logowania w programowaniu, przypisując wartość true do specjalnej zmiennej self.__WB_DISABLE_DEV_LOGS w skrypcie service worker:

//
self.__WB_DISABLE_DEV_LOGS = true;

// The rest of your Workbox service worker code goes here

Jedną z zalet tego podejścia jest to, że jest ono całkowicie niezależne od konfiguracji usługi tworzącej pakiety i będzie działać niezależnie od tego, czy używasz usługi workbox-sw bezpośrednio, czy zależy Ci na tym, aby utworzyć pakiet skryptu service worker obsługiwany przez usługę Workbox.

Więcej informacji

Jeśli wciąż masz problem z zrozumieniem, co się dzieje w skrypcie service worker z błędami, a logowanie to za mało, opublikuj pytanie na Stack Overflow (używając tagu workbox w Stack Overflow). Jeśli nie znajdziesz tam odpowiedzi, zgłoś problem na GitHubie (przeczytaj wytyczne dotyczące publikowania). Dzięki temu Twoje pytania będzie czytało nie tylko szerokie grono programistów, ale też odpowiedź na Twoje pytanie może pomóc komuś w przyszłości w takiej sytuacji.