Moduł workbox-sw to bardzo łatwy sposób na rozpoczęcie pracy z modułami Workbox, upraszcza ich wczytywanie i udostępnia kilka prostych metod pomocniczych.
Usługi workbox-sw możesz używać w naszej sieci CDN lub używać jej na własnym serwerze w połączeniu z zestawem plików skrzynki roboczej.
Korzystanie z Workbox SW przez CDN
Najłatwiejszym sposobem rozpoczęcia korzystania z tego modułu jest skorzystanie z sieci CDN. Wystarczy, że dodasz do skryptu service worker:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
Dzięki temu w skrypcie service worker znajdzie się przestrzeń nazw workbox, która zapewni dostęp do wszystkich modułów Workbox.
workbox.precaching.*
workbox.routing.*
etc
Gdy zaczniesz korzystać z dodatkowych modułów, stanie się coś magicznego.
Gdy po raz pierwszy odwołasz się do modułu, workbox-sw wykryje go i wczyta go przed jego udostępnieniem. Widać to na karcie sieci w Narzędziach deweloperskich.
Pliki te będą przechowywane w pamięci podręcznej przeglądarki, dzięki czemu będą dostępne do użytku w trybie offline w przyszłości.
Używanie lokalnych plików skrzynki roboczej zamiast CDN
Jeśli nie chcesz korzystać z sieci CDN, możesz z łatwością przejść na pliki Workbox przechowywane w Twojej domenie.
Najprostszym sposobem jest pobranie plików za pomocą polecenia copyLibraries w usłudze workbox-cli, a następnie informację o tym, gdzie je znaleźć, za pomocą opcji konfiguracji modulePathPrefix.workbox-sw
Jeśli umieścisz pliki pod adresem /third_party/workbox-vX.Y.Z/, możesz ich użyć w ten sposób:
importScripts('/third_party/workbox-vX.Y.Z/workbox-sw.js');
workbox.setConfig({
modulePathPrefix: '/third_party/workbox-vX.Y.Z/',
});
Unikaj importowania asynchronicznego
Wczytywanie nowych modułów po raz pierwszy obejmuje wywołanie metody importScripts() ze ścieżką do odpowiedniego pliku JavaScript (hostowanego w sieci CDN lub lokalnego adresu URL).
W obu przypadkach obowiązuje ważne ograniczenie: niejawne wywołania importScripts() mogą mieć miejsce tylko w obrębie modułu obsługi install skryptu service worker lub podczas synchronicznego, wstępnego wykonania skryptu skryptu service worker.
Aby uniknąć naruszenia tego ograniczenia, sprawdzoną metodą jest odwoływanie się do różnych przestrzeni nazw workbox.* poza modułami obsługi zdarzeń i funkcjami asynchronicznymi.
Na przykład ten kod skryptu service worker najwyższego poziomu jest odpowiedni:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
// This will work!
workbox.routing.registerRoute(
({request}) => request.destination === 'image',
new workbox.strategies.CacheFirst()
);
Jeśli jednak w innym miejscu w skrypcie service worker nie występuje odwołanie do elementu workbox.strategies, może to stanowić problem:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('.png')) {
// Oops! This causes workbox-strategies.js to be imported inside a fetch handler,
// outside of the initial, synchronous service worker execution.
const cacheFirst = new workbox.strategies.CacheFirst();
event.respondWith(cacheFirst.handle({request: event.request}));
}
});
Jeśli musisz napisać kod, który w przeciwnym razie naruszałby to ograniczenie, możesz bezpośrednio aktywować wywołanie importScripts() poza modułem obsługi zdarzeń, korzystając z metody workbox.loadModule():
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
// This will trigger the importScripts() for workbox.strategies and its dependencies:
workbox.loadModule('workbox-strategies');
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('.png')) {
// Referencing workbox.strategies will now work as expected.
const cacheFirst = new workbox.strategies.CacheFirst();
event.respondWith(cacheFirst.handle({request: event.request}));
}
});
Możesz też utworzyć odwołanie do odpowiednich przestrzeni nazw poza modułami obsługi zdarzeń, a później użyć tego odwołania:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
// This will trigger the importScripts() for workbox.strategies and its dependencies:
const {strategies} = workbox;
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('.png')) {
// Using the previously-initialized strategies will work as expected.
const cacheFirst = new strategies.CacheFirst();
event.respondWith(cacheFirst.handle({request: event.request}));
}
});
Wymuszaj korzystanie z kompilacji do debugowania lub kompilacji produkcyjnych
Wszystkie moduły Workbox zawierają 2 kompilacje: kompilację do debugowania zawierającą logowanie i dodatkową kontrolę typu oraz kompilację produkcyjną, która usuwa logowanie i sprawdzanie typu.
Domyślnie workbox-sw będzie używać kompilacji do debugowania w przypadku witryn na lokalnym hoście, ale w przypadku każdego innego źródła będzie korzystać z kompilacji produkcyjnej.
Jeśli chcesz wymuszać debugowanie lub kompilacje produkcyjne, możesz ustawić opcję konfiguracji debug:
workbox.setConfig({
debug: true,
});
Przekonwertuj kod za pomocą instrukcji importu na użycie workbox-sw
Podczas wczytywania Workbox za pomocą workbox-sw dostęp do wszystkich pakietów Workbox jest uzyskiwany przez globalną przestrzeń nazw workbox.*.
Jeśli masz przykładowy kod, który zawiera instrukcje import, które chcesz przekonwertować na użycie workbox-sw, wystarczy, że wczytasz instrukcję workbox-sw i zastąpisz wszystkie instrukcje import zmiennymi lokalnymi, które odwołują się do tych modułów w globalnej przestrzeni nazw.
Działa to, ponieważ każdy pakiet instancji roboczych Workbox opublikowany w npm jest też dostępny w globalnej przestrzeni nazw workbox za pomocą nazwy w wersji camelCase (np. wszystkie moduły wyeksportowane z pakietu npm workbox-precaching można znaleźć w workbox.precaching.*. Wszystkie moduły wyeksportowane z pakietu npm workbox-background-sync znajdziesz w workbox.backgroundSync.*.
Oto przykład kodu, który korzysta z instrukcji import odwołujących się do modułów Workspace:
import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponse} from 'workbox-cacheable-response';
registerRoute(
({request}) => request.destination === 'image',
new CacheFirst({
plugins: [new CacheableResponsePlugin({statuses: [0, 200]})],
})
);
Poniżej znajdziesz ten sam kod przepisany tak, aby używać w nim workbox-sw (zauważ, że zmieniły się tylko instrukcje importu, ponieważ logika nie została zmieniona):
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
const {registerRoute} = workbox.routing;
const {CacheFirst} = workbox.strategies;
const {CacheableResponse} = workbox.cacheableResponse;
registerRoute(
({request}) => request.destination === 'image',
new CacheFirst({
plugins: [new CacheableResponsePlugin({statuses: [0, 200]})],
})
);