Określanie buforowania za pomocą skrzynki roboczej

Zapisywanie w pamięci podręcznej to jedna z najczęstszych czynności wykonywanych w mechanizmach Service Workbox. Poza tym Workbox oferuje dużą elastyczność w zakresie realizacji tego ważnego zadania, niezależnie od tego, które z narzędzi do tworzenia w Workspace wybierzesz. Z tego przewodnika dowiesz się, jak wstępnie zapisywać zasoby w pamięci podręcznej za pomocą obu metod (generateSW i injectManifest) oraz które z tych metod mogą najlepiej sprawdzić się w Twoim projekcie.

Ćwiczenie z użyciem przycisku generateSW

generateSW to najprostszy sposób na wstępne buforowanie zasobów w Workbox. Najważniejsze w usłudze generateSW jest to, że nie tworzysz własnego skryptu service worker, tylko chcesz go wygenerować. Możesz jednak wpłynąć na jego działanie za pomocą różnych opcji konfiguracji.

Domyślnie generateSW wykonuje różne działania w zależności od używanego narzędzia do kompilacji. Jeśli używasz workbox-webpack-plugin, nie musisz określać żadnych opcji konfiguracji. Domyślnie wtyczka wstępnie buforuje wszystko, co zawiera pakiet internetowy na swoim wykresie zależności, i zapisze skrypt service worker o nazwie service-worker.js w katalogu określonym przez output.path

Z drugiej strony, jeśli używasz workbox-build lub workbox-cli, w pamięci podręcznej będą domyślnie zapisywane tylko zasoby HTML, CSS i JavaScript odczytywane z lokalnego systemu plików. Aby wstępne zapisywanie działało, musisz w konfiguracji generateSW określić opcję swDest i globDirectory. Być może zechcesz skonfigurować też dodatkowe opcje mające wpływ na zachowanie skryptu service worker, dlatego zapoznaj się z dokumentacją.

Ostrzeżenie: jeśli zbyt wiele zasobów w projekcie jest wstępnie zapisanych w pamięci podręcznej z ustawieniami domyślnymi, użyj jednej z opcji glob, aby wykluczyć zasoby w konfiguracji generateSW. Jeśli używasz dodatku workbox-webpack-plugin, sprawdź jego dokumentację GenerateSW, aby dowiedzieć się, jak zapobiec buforowaniu niechcianych zasobów, ponieważ jego konfiguracja różni się od konfiguracji generateSW.

Ćwiczenie z użyciem przycisku injectManifest

Korzystanie z usługi injectManifest nie jest tak łatwe jak używanie generateSW, ale rezygnujesz z łatwości obsługi na rzecz większej elastyczności. Gdy generateSW zajmuje się generowaniem całego skryptu service worker za Ciebie, injectManifest pobiera skrypt service worker jako źródło i wstawia listę adresów URL do pamięci podręcznej, pozostawiając resztę skryptu w niezmienionej postaci.

Gdy używasz injectManifest, odpowiadasz za podłączenie logiki wstępnego buforowania. Gdy injectManifest sprawdza mechanizm wprowadzania danych, szuka specjalnej zmiennej self.__WB_MANIFEST i zastępuje ją plikiem manifestu precache. W przeciwnym razie injectManifest zgłosi błąd.

Uwaga: jeśli chcesz zmienić ciąg znaków injectManifest na inny niż self.__WB_MANIFEST, możesz określić opcję injectionPoint w jej konfiguracji.

Listę wpisów w pliku manifestu precache można dostosować za pomocą dodatkowych opcji konfiguracji.

Uwaga: w przeciwieństwie do generateSW usługa injectManifest nie tworzy automatycznie pakietu środowiska wykonawczego Workbox. Poniżej znajdziesz porównanie pokazujące, jak zarządzać tą funkcją w przypadkach użycia opartych na injectManifest.

Porównanie

Kliknij każdą z kart poniżej, aby porównać wykorzystanie metod generateSW i injectManifest:

Ponieważ generateSW generuje mechanizm service worker, musisz tylko podać konfigurację. Poniżej znajduje się przykład użycia atrybutu workbox-build:

// build-sw.js
import {generateSW} from 'workbox-build';

generateSW({
  swDest: './dist/sw.js',
  globDirectory: './dist',
  globPatterns: [
    '**/*.js',
    '**/*.css',
    '**/*.svg'
  ]
});

Skrypt service worker można następnie utworzyć w wierszu poleceń za pomocą węzła:

node build-sw.js

injectManifest wymaga źródłowego skryptu service worker, więc najmniej odpowiedni przykład wymaga źródłowego pliku skryptu service worker. Jeśli potrzebne jest tylko wstępne zapisywanie, skrypt service worker może wyglądać mniej więcej tak:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(self.__WB_MANIFEST);

Zapisz ciąg znaków self.__WB_MANIFEST. Jest to obiekt zastępczy, który Workbox zastępuje plik manifestu precache. Poniżej znajduje się przykładowa konfiguracja dla tego przypadku użycia:

// build-sw.js
import {injectManifest} from 'workbox-build';

injectManifest({
  swSrc: './src/sw.js',
  swDest: './dist/sw.js',
  globDirectory: './dist',
  globPatterns: [
    '**/*.js',
    '**/*.css',
    '**/*.svg'
  ]
});

injectManifest jest preferowany w przypadku złożonych wymagań, takich jak zaawansowany routing, niestandardowe strategie buforowania lub inne elementy, których nie obejmują opcje generateSW.

Uwaga: w podanych wyżej przykładach założono, że pracujesz w środowisku węzła, które natywnie obsługuje moduły ES bez kroku kompilacji. W wersjach węzła starszych niż 16 może być konieczne ustawienie flagi w celu włączenia obsługi modułu ES lub korzystanie z semantyki CommonJS za pomocą module.exports.

Podsumowanie

Stosowanie zasad w obiekcie Workbox jest znacznie prostsze niż w przypadku samodzielnego zarządzania zapisywaniem w pamięci podręcznej. Dotyczy to zwłaszcza zasobów wersji skompilowanych przez moduły tworzenia pakietów. Wstępne buforowanie nie jest jednak jedyną rzeczą, którą często wykonuje się w przypadku skryptu service worker. W trakcie kursu poznasz inne techniki, takie jak zapisywanie danych w pamięci podręcznej w czasie działania.