Skrzynka robocza: zestaw narzędzi Service Worker wysokiego poziomu

Jeff Posnick

Kluczową rolę w tworzeniu niezawodnych aplikacji internetowych odgrywają 2 interfejsy API: Service Worker i Cache Storage. Efektywne korzystanie z nich – bez wprowadzania subtelnych błędów czy „nagłych problemów” może być wyzwaniem. Na przykład błędy w kodzie skryptu service worker mogą powodować problemy w pamięci podręcznej. Użytkownicy mogą zobaczyć nieaktualną treść lub uszkodzone linki.

Workbox to kompleksowy zestaw narzędzi service worker stworzony na bazie interfejsów Service Worker i Cache Storage API. udostępnia zestaw bibliotek gotowych do użycia w środowisku produkcyjnym, dzięki czemu można dodawać obsługę offline do aplikacji internetowych. Zestaw narzędzi składa się z 2 kolekcji: narzędzi ułatwiających zarządzanie kodem uruchamianym w mechanizmie Service Worker i narzędzi zintegrowanych z procesem kompilacji.

Kod środowiska wykonawczego

Jest to kod, który działa w skrypcie skryptu service worker i kontroluje sposób, w jaki przechwytuje on żądania wychodzące oraz wchodzi w interakcje z interfejsem Cache Storage API. Workbox zawiera łącznie 10 modułów biblioteki, z których każdy obsługuje różne specjalistyczne przypadki użycia. Najważniejsze moduły określają, czy skrypt service worker odpowie (kierowanie) i jak to zrobi (tzw. strategia buforowania).

Tworzenie integracji

Workbox udostępnia wiersz poleceń, moduł Node.js i wtyczki webpack, które dają alternatywne sposoby osiągania 2 rzeczy:

  • utworzyć skrypt skryptu service worker na podstawie zestawu opcji konfiguracyjnych; Wygenerowany skrypt service worker używa specjalnych bibliotek środowiska wykonawczego Workbox do realizowania skonfigurowanych przez Ciebie strategii buforowania.
  • Wygeneruj listę adresów URL, które powinny być „wstępnie zapisane w pamięci podręcznej”, na podstawie konfigurowalnych wzorców, aby uwzględniać lub wykluczać pliki wygenerowane podczas procesu kompilacji.

Dlaczego warto korzystać z Workbox?

Korzystanie z Workbox podczas tworzenia skryptu service worker jest opcjonalne – dostępnych jest wiele przewodników, które przedstawiają typowe strategie buforowania z punktu widzenia mechanizmów „vanilla”. Jeśli zdecydujesz się na używanie Workbox, oto kilka jego zalet.

Zarządzanie pamięcią podręczną

Workbox obsługuje aktualizacje pamięci podręcznej za Ciebie. Jest to powiązane z procesem kompilacji w przypadku wstępnego buforowania lub za pomocą konfigurowalnych zasad dotyczących rozmiaru i wieku w przypadku buforowania w środowisku wykonawczym. Podstawowy interfejs Cache Storage API jest wydajny, ale nie ma wbudowanej obsługi wygaśnięcia pamięci podręcznej. Narzędzia takie jak Workbox wypełniają tę lukę.

Rozbudowane logowanie i raportowanie błędów

Zaczynając pracę z mechanizmami service worker, trudno jest ustalić, dlaczego dany element jest przechowywany w pamięci podręcznej (lub co – co równie frustrujące – dlaczego nie jest przechowywany w pamięci podręcznej). Workbox automatycznie wykrywa, że w localhost masz uruchomioną deweloperską wersję witryny, i włącza logowanie debugowania w konsoli JavaScript przeglądarki.

Logowanie w polu roboczym w konsoli Narzędzi deweloperskich

Postępowanie zgodnie z komunikatami logu pozwala znacznie szybciej dotrzeć do źródła problemów związanych z konfiguracją lub unieważnieniem.

Przetestowana baza kodu dla wielu przeglądarek

Workbox powstał na bazie zestawu testów na różne przeglądarki. W miarę możliwości automatycznie wraca do alternatywnych implementacji funkcji, których nie ma w niektórych przeglądarkach.

Jak używać Workbox?

Integracja z platformą

Jeśli zaczynasz nowy projekt od zera, możesz skorzystać z integracji z Workbox, którą można znaleźć w wielu popularnych zestawach startowych i wtyczkach dodatkowych:

Dodawanie Workbox do istniejącego procesu kompilacji

Jeśli masz już wdrożony proces kompilacji witryny, aby zacząć korzystać z Workbox, wystarczy użyć odpowiedniego wiersza poleceń, modułu Node.js lub wtyczki pakietu webpack.

Interfejs wiersza poleceń Workbox ułatwia szybkie rozpoczęcie pracy i korzystanie z niego. Zawiera on tryb wizard, który sprawdza lokalne środowisko programistyczne i sugeruje rozsądną konfigurację domyślną, której możesz użyć na przyszłość:

workbox wizard
? What is the root of your web app (i.e. which directory do you deploy)? src/
? Which file types would you like to precache? css, js, html
? Where would you like your service worker file to be saved? build/sw.js
? Where would you like to save these configuration options? workbox-config.js

Aby utworzyć skrypt service worker, uruchom workbox generateSW workbox-config.js w ramach procesu kompilacji. Więcej informacji znajdziesz w dokumentacji generateSW. Możesz jeszcze bardziej dostosować skrypt service worker, wprowadzając zmiany w workbox-config.js. Więcej informacji znajdziesz w dokumentacji poszczególnych opcji.

Używaj skrzynki roboczej w czasie działania w istniejącym mechanizmie Service Worker

Jeśli masz już skrypt service workbox i chcesz wypróbować biblioteki jego środowiska wykonawczego, zaimportuj Workbox z oficjalnej sieci CDN i od razu zacznij używać go do buforowania w czasie działania. Ten przypadek użycia oznacza, że nie możesz korzystać z pamięci podręcznej (która wymaga integracji w czasie kompilacji), ale świetnie nadaje się do prototypowania i testowania na bieżąco różnych strategii buforowania.

// Replace 3.6.3 with the current version number of Workbox.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/3.6.3/workbox-sw.js');

workbox.routing.registerRoute(
  new RegExp('\.png$'),
  workbox.strategies.cacheFirst({
    cacheName: 'images-cache',
  })
);