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.
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.
- Interfejs
workbox-broadcast-cache-update module
korzysta z interfejsu Broadcast Channel API (jeśli jest dostępny) i wraca do implementacji opartej napostMessage()
w przeglądarkach, które ich nie obsługują. - Moduł workbox-background-sync, jeśli to możliwe, korzysta z interfejsu Background Sync API. Jeśli nie jest, przełącza się na ponawianie zdarzeń znajdujących się w kolejce przy każdym uruchomieniu skryptu service worker.
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',
})
);