Cykl życia mechanizmów Service Worker pozwala zapewnić przewidywalny proces instalacji i aktualizacji, może też nieco nadać lokalny cykl rozwoju.
W typowym lokalnym cyklu programowania deweloperzy zapisują zmiany w plikach w edytorze tekstu, sprawdź zmiany w przeglądarce – cały proces będzie się powtarzał. Kiedy wchodzi w skład skryptu service worker, cykl ten wygląda mniej więcej tak samo, ale mogą występować różnice między oczekiwaniami programisty i działaniem przeglądarki.
Wyjątki w przypadku programowania lokalnego
Interfejsy API mechanizmu Service Worker są dostępne tylko na stronach wyświetlanych przez HTTPS,
ale są wyjątki od tej reguły, w których mogą być one dostępne przez HTTP.
Wyjątek stanowią strony obsługiwane przez localhost
, co dobrze sprawdza się w przypadku rozwoju lokalnego.
Nierzadko jednak deweloperzy określają lokalne nazwy hostów (oprócz localhost
) w parametrach
plik hosts.
Jest to wymagane w lokalnych środowiskach programistycznych, gdy wiele projektów wymaga oddzielnych nazw hostów.
W takich przypadkach wystarczy udostępnić samodzielnie podpisany certyfikat.
Lepszym obejściem jest poinstruowanie przeglądarki, aby dodała wyjątki do testowania mechanizmów Service Worker.
W Chrome wejdź na chrome://flags/#unsafely-treat-insecure-origin-as-secure
i określać niezabezpieczone źródła, które mają być traktowane jako bezpieczne.
W przeglądarce Firefox można testować mechanizmy Service Worker w niezabezpieczonych źródłach za pomocą ustawienia devtools.serviceWorkers.testing.enabled
w about:config
.
Pomoce w tworzeniu mechanizmów Service Worker
Lokalny proces programowania wykorzystujący mechanizm Service Worker może prowadzić do pozornie nieoczekiwanych zachowań.
Załóżmy na przykład, że w przypadku zasobów statycznych bez wersji w pamięci podręcznej stosowana jest strategia tylko w przypadku zasobów statycznych lub wstępnie buforowana informacja „Jesteś offline”. która powinna zaktualizować się po ponownym załadowaniu po wprowadzeniu zmian.
Nieaktualna wersja tych zasobów jest zawsze wyświetlana z instancji Cache
,
wydają się nigdy nie aktualizować!
Jest to frustrujące, że mechanizm Service Worker robi tylko to, do czego jest skierowany,
ale są kilka sposobów na to,
aby testowanie było łatwiejsze.
Zdecydowanie najskuteczniejszym sposobem testowania skryptu service worker jest użycie okien przeglądania prywatnego, takich jak okna incognito w Chrome,
przeglądania prywatnego w Firefoksie.
Za każdym razem, gdy otwierasz okno przeglądania prywatnego, zaczynasz od nowa.
Nie ma aktywnych mechanizmów Service Worker ani otwartych instancji Cache
. Proces testowania tego typu wygląda tak:
- Otwórz okno przeglądania prywatnego.
- Otwórz stronę rejestrującą skrypt service worker.
- Sprawdź, czy skrypt service worker działa zgodnie z oczekiwaniami.
- Zamknij okno incognito.
- Powtórz.
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, ale mogą w pewny sposób modyfikować cykl życia mechanizmów Service Worker.
Panel aplikacji zawiera panel podrzędny o nazwie Skrypty service worker, z aktywnymi skryptami service worker na bieżącej stronie. Każdy aktywny skrypt service worker można zaktualizować ręcznie lub nawet całkowicie wyrejestrować. U góry znajdują się 3 przełączniki, które ułatwiają rozwój.
- Offline symuluje warunki offline. Jest to pomocne podczas testowania, czy aktywny skrypt service worker udostępnia treści offline.
- 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 odświeżana.
- Włączenie opcji Omijanie dla sieci powoduje obchodzenie dowolnego kodu w zdarzeniu
fetch
skryptu service worker i zawsze pobiera treści z sieci.
Są to przydatne przełączniki, szczególnie Pomiń w przypadku sieci, to świetne rozwiązanie, gdy przygotowujesz projekt z aktywnym mechanizmem Service Worker, ale chcesz też zadbać o to, aby wszystko działało zgodnie z oczekiwaniami bez użycia mechanizmu Service Worker.
Firefox ma podobny panel aplikacji w narzędziach dla programistów, ale ogranicza się ona do pokazywania, jakie mechanizmy Service Worker są zainstalowane, a także możliwość ręcznego wyrejestrowania wszystkich aktywnych skryptów service worker na bieżącej stronie. Jest to równie pomocne, ale wymaga dodatkowego nakładu pracy w lokalnym cyklu programowania.
Shift i załaduj ponownie
Podczas programowania lokalnego z użyciem aktywnego skryptu service worker bez konieczności korzystania z funkcji aktualizacji po odświeżeniu lub omijania w przypadku sieci warto przytrzymać klawisz Shift i nacisnąć przycisk odświeżania.
Jest to tzw. wymuszone odświeżenie, które pomija pamięć podręczną HTTP sieci. Gdy jest aktywny skrypt service worker, wymuszone odświeżanie również całkowicie go omija.
Ta funkcja jest przydatna, gdy nie masz pewności, czy dana strategia buforowania działa zgodnie z oczekiwaniami. Warto pobrać wszystko z sieci i porównać zachowania z skrypcją service worker i bez niego. Co więcej, jest to określony sposób działania, więc będą je obserwowane we wszystkich przeglądarkach, które obsługują mechanizmy Service Worker.
Sprawdzanie zawartości pamięci podręcznej
Gdy nie można przeprowadzić przeglądu pamięci podręcznej, trudno jest stwierdzić, czy strategia buforowania działa zgodnie z oczekiwaniami.
Oczywiście, pamięć podręczną można sprawdzić w kodzie,
ale jest to proces wykorzystujący debugery lub instrukcje console
, gdy narzędzie wizualne lepiej sprawdzi się w tym zadaniu.
Panel aplikacji w Narzędziach deweloperskich w Chrome zawiera podpanel, który umożliwia badanie zawartości instancji Cache
.
Ten panel podrzędny ułatwia programowanie mechanizmów Service Worker, zapewniając między innymi następujące funkcje:
- Wyświetl nazwy
Cache
instancji. - Możliwość sprawdzania treści odpowiedzi zasobów w pamięci podręcznej i powiązanych z nimi nagłówków odpowiedzi.
- Usuń co najmniej 1 element z pamięci podręcznej, a nawet usuń całe instancje
Cache
.
Ten graficzny interfejs użytkownika ułatwia sprawdzanie pamięci podręcznych instancji roboczych, aby sprawdzić, czy elementy zostały z niej dodane, zaktualizowane lub usunięte. Firefox ma własną przeglądarkę pamięci podręcznej o podobnej funkcjonalności, która jednak znajduje się w osobnym panelu Pamięć.
Symuluję limit miejsca na dane
W witrynach z dużą ilością dużych zasobów statycznych (takich jak obrazy w wysokiej rozdzielczości): może dojść do przekroczenia limitów miejsca na dane. W takim przypadku przeglądarka usuwa z pamięci podręcznej elementy, które uzna za nieaktualne lub zasługujące na poświęcenie miejsca na nowe zasoby.
Radzenie sobie z limitami miejsca na dane powinno być częścią tworzenia mechanizmów Service Worker, a Workbox ułatwia ten proces niż samodzielne zarządzanie nim. Dobrym pomysłem może być jednak symulowanie niestandardowego limitu miejsca na dane w celu przetestowania logiki zarządzania pamięcią podręczną z funkcją Workbox lub bez niej.
Panel aplikacji w Narzędziach deweloperskich w Chrome zawiera podpanel Miejsce na dane, który informuje o tym, jaka część bieżącego limitu miejsca na dane jest wykorzystywana przez stronę. Możesz też określić niestandardowy limit w megabajtach. W takiej sytuacji Chrome wymusi niestandardowy limit miejsca na dane, aby można było przetestować ten limit.
Przy okazji ten podpanel zawiera też przycisk Wyczyść dane witryny i całą tablicę powiązanych pól wyboru, które muszą zostać wyczyszczone po kliknięciu przycisku.
Wśród tych elementów są wszystkie otwarte instancje Cache
i możliwość wyrejestrowania wszystkich aktywnych mechanizmów Service Worker kontrolujących stronę.
Łatwiejsze tworzenie aplikacji i większa produktywność
Gdy deweloperzy nie wykonują zbyt wielu zadań, mogą pracować wydajniej i pracować wydajniej. Programowanie lokalne z użyciem mechanizmu Service Worker może być niuanse, ale nie musi być bolesne. Dzięki tym poradom i wskazówkom proces współpracy z aktywnym mechanizmem Service Worker powinien być dużo bardziej przejrzysty i przewidywalny. i usprawnia pracę programistów.