Ulepszanie programowania mechanizmów Service Worker

Cykl życia mechanizmów Service Worker zapewnia przewidywalny proces instalacji i aktualizacji, ale może wprowadzić nieco bardziej precyzyjne zmiany w lokalnym cyklu programowania.

W typowym lokalnym cyklu programowania programiści zapisują zmiany w plikach w edytorze tekstu, a potem przechodzą do przeglądarki, aby je sprawdzić, a proces ten jest powtarzany. Gdy mechanizm service worker jest używany w różnych sytuacjach, jest on w większości taki sam, ale jego działanie może różnić się między oczekiwaniami dewelopera a działaniami przeglądarki.

Wyjątki w przypadku programowania lokalnego

Ogólnie interfejsy API service worker są dostępne tylko na stronach udostępnianych przez HTTPS, ale od tej reguły istnieją wyjątki – przez HTTP. Wyjątkiem są strony wyświetlane w okresie localhost, które sprawdzają się w przypadku programowania lokalnego.

Deweloperzy często podają w pliku hostów lokalne nazwy hostów inne niż localhost. Jest to wymagane w lokalnych środowiskach programistycznych, gdy wiele projektów wymaga oddzielnych nazw hosta. W takich przypadkach wystarczy udostępnić certyfikat podpisany samodzielnie.

Wygodniejszym rozwiązaniem jest ustawienie w przeglądarce wyjątków na potrzeby testowania mechanizmów Service Worker. W przypadku Chrome otwórz chrome://flags/#unsafely-treat-insecure-origin-as-secure i określ niezabezpieczone źródła, które mają być traktowane jako bezpieczne. Firefox umożliwia testowanie skryptów service worker z niezabezpieczonych źródeł za pomocą ustawienia devtools.serviceWorkers.testing.enabled w about:config.

Pomoce dla programistów mechanizmów Service Worker

Programowanie lokalne z użyciem skryptu service worker może prowadzić do pozornie nieoczekiwanych zachowań. Załóżmy na przykład, że stosowana jest strategia polegająca na korzystaniu tylko z pamięci podręcznej w przypadku zasobów statycznych bez wersji lub strony z informacjami zapisanymi w pamięci podręcznej, która powinna być aktualizowana przy ponownym ładowaniu po wprowadzeniu zmian. Nieaktualne wersje tych zasobów zawsze są wyświetlane z instancji Cache, więc prawdopodobnie nigdy nie są aktualizowane. Było to frustrujące, ponieważ skrypt service worker wykonywał tylko te zadania, do których został stworzony, ale istnieją pewne sposoby, aby ułatwić testowanie.

Najskuteczniejszym sposobem testowania mechanizmów Service Worker jest korzystanie z okna przeglądania prywatnego, takiego jak okna incognito w Chrome lub funkcja przeglądania prywatnego w Firefoksie. Za każdym razem, gdy otwierasz okno przeglądania prywatnego, zaczynasz od nowa. Nie ma aktywnych skryptów service worker ani otwartych instancji Cache. Procedura takiego testowania to:

  1. Otwórz okno przeglądania prywatnego.
  2. Otwórz stronę, która rejestruje skrypt service worker.
  3. Sprawdź, czy skrypt service worker działa zgodnie z oczekiwaniami.
  4. Zamknij okno incognito.
  5. Powtarzaj.

Dzięki temu procesowi wiernie naśladujesz cykl życia mechanizmów Service Worker.

Inne narzędzia testowe dostępne w panelu aplikacji Narzędzi deweloperskich w Chrome mogą pomóc, choć mogą one na pewne sposoby modyfikować cykl życia mechanizmów Service Worker.

Panel aplikacji Chrome DevTools.

Panel aplikacji zawiera panel podrzędny o nazwie Skrypty Service Workers, na którym są widoczne aktywne mechanizmy Service Worker dla bieżącej strony. Każdy aktywny skrypt service worker można aktualizować ręcznie lub nawet całkowicie go wyrejestrować. U góry znajdują się również 3 przełączniki, które ułatwiają tworzenie stron.

  1. Offline symuluje warunki offline. Jest to przydatne podczas sprawdzania, czy aktywny skrypt service worker udostępnia treści offline.
  2. Aktualizuj przy ponownym załadowaniu: po włączeniu tej opcji ponownie pobiera i zastępuje bieżący skrypt service worker za każdym razem, gdy strona jest wczytywana.
  3. Pomijaj dla sieci – gdy ta opcja jest włączona, powoduje obejście całego kodu w zdarzeniu fetch skryptu service worker i zawsze pobiera treści z sieci.

Są to przydatne przełączniki, szczególnie Pominięcie dla sieci, które przydają się podczas tworzenia projektu z aktywnym mechanizmem service worker, który nie tylko działa zgodnie z oczekiwaniami, ale również bez niego.

Firefox ma podobny panel aplikacji w narzędziach dla programistów, jednak działanie funkcji ogranicza się do pokazywania, jakie mechanizmy Service Worker są zainstalowane, oraz w przypadku bieżącej strony, w której można ręcznie wyrejestrować wszystkie aktywne mechanizmy Service Worker. Jest to równie przydatne, ale w lokalnym cyklu programowania wymaga więcej wysiłku.

Przesuń i załaduj ponownie

Jeśli programujesz lokalnie przy użyciu aktywnego skryptu service worker bez korzystania z funkcji aktualizacji podczas odświeżania lub pomijania w przypadku sieci, warto przytrzymać klawisz Shift i nacisnąć przycisk odświeżania.

Jest to tzw. wymuszone odświeżanie, które omija pamięć podręczną HTTP w sieci. Gdy skrypt service worker jest aktywny, wymuszone odświeżenie powoduje też jego całkowite pominięcie.

Ta funkcja jest przydatna, gdy nie masz pewności, czy konkretna strategia buforowania działa zgodnie z oczekiwaniami. Możesz też pobrać wszystkie dane z sieci, aby porównać ich działania z skryptem service worker i bez niego. Co więcej, jest to określone zachowanie, które będzie widoczne we wszystkich przeglądarkach obsługujących mechanizmy Service Worker.

Sprawdzanie zawartości pamięci podręcznej

Jeśli nie można sprawdzić pamięci podręcznej, trudno stwierdzić, czy strategia buforowania działa zgodnie z oczekiwaniami. Oczywiście można zbadać pamięć podręczną w kodzie, ale jest to proces wymagający użycia debugerów lub instrukcji console, w których lepiej sprawdzi się do tego narzędzie wizualne. Panel Application (Aplikacje) w Narzędziach deweloperskich w Chrome zawiera panel podrzędny do sprawdzania zawartości instancji Cache.

Badanie pamięci podręcznej w Narzędziach deweloperskich

Ułatwia on tworzenie mechanizmów Service Worker przez następujące funkcje:

  • Wyświetl nazwy Cache instancji.
  • Możliwość sprawdzania treści odpowiedzi zasobów z pamięci podręcznej oraz powiązanych z nimi nagłówków odpowiedzi.
  • Usuń z pamięci podręcznej jeden lub więcej elementów, a nawet całe instancje Cache.

Ten graficzny interfejs użytkownika ułatwia badanie pamięci podręcznych skryptów service worker, aby zobaczyć, czy elementy zostały do nich dodane, zaktualizowane czy usunięte. Firefox oferuje własną przeglądarkę pamięci podręcznej o podobnej funkcjonalności, która jednak znajduje się w osobnym panelu Pamięć.

Symulowanie limitu miejsca na dane

W witrynach z dużą liczbą dużych zasobów statycznych (takich jak obrazy o wysokiej rozdzielczości) może się zdarzyć przekroczenie limitów miejsca. W takim przypadku przeglądarka usuwa z pamięci podręcznej elementy, które uzna za nieaktualne lub z innego powodu warto poświęcić, by zrobić miejsce na nowe zasoby.

radzenie sobie z limitami miejsca na dane powinno być częścią opracowywania mechanizmów Service Workbox, a dzięki Workbox ten proces jest prostszy niż samodzielne zarządzanie nimi. Dobrym pomysłem może być jednak symulowanie niestandardowego limitu miejsca na dane w celu przetestowania logiki zarządzania pamięcią podręczną niezależnie od tego, czy korzystasz z Workbox.

Przeglądarka wykorzystania miejsca na dane.
Przeglądarka wykorzystania miejsca na dane w panelu Aplikacje w Narzędziach deweloperskich w Chrome. Tutaj ustawiany jest niestandardowy limit miejsca na dane.

W panelu Application (Aplikacje) w Narzędziach deweloperskich w Chrome znajduje się podpanel Miejsce na dane, który informuje o tym, jaka część bieżącego limitu miejsca na dane jest wykorzystywana przez stronę. Umożliwia też określenie niestandardowego limitu w megabajtach. Gdy będzie obowiązywać, Chrome będzie wymuszać niestandardowy limit miejsca na dane, aby można było go przetestować.

Ten panel podrzędny zawiera też przycisk Wyczyść dane witryny i wiele powiązanych z nim pól wyboru, które mają zostać usunięte po kliknięciu tego przycisku. Wśród nich znajdują się wszystkie otwarte instancje Cache oraz możliwość wyrejestrowania wszystkich aktywnych mechanizmów Service Worker mających kontrolę nad stroną.

Łatwiejsze tworzenie aplikacji, większa produktywność

Gdy programiści nie muszą się martwić, mogą pracować bardziej pewnie i wydajnie. Programowanie lokalne z użyciem skryptu service worker może wymagać niuansów, ale nie musi być uciążliwe. Dzięki tym poradom i poradom programowanie z wykorzystaniem aktywnego skryptu service worker powinno być dużo bardziej przejrzyste i przewidywalne, co zwiększy komfort programistów.