Workbox jest wystarczająco elastyczny, by zmieścić się w procesie kompilacji każdego projektu. Oznacza to, że istnieje więcej niż jeden sposób korzystania z Workbox, co pozwala wybrać odpowiednią integrację do swojego projektu. Niezależnie od sposobu integracji z Workbox różne narzędzia oferują podobny interfejs API.
generateSW
kontra injectManifest
Będziesz korzystać z jednej z dwóch podstawowych metod narzędzi do tworzenia w Workbox: generateSW
lub injectManifest
. Wybór odpowiedniego rozwiązania zależy od tego, ile potrzebujesz elastyczności. generateSW
skupia się na łatwości użytkowania i prostości, które wiążą się z elastycznością. Dzięki temu możesz zadeklarować zestaw opcji konfiguracyjnych, a w zamian zapewnić w pełni funkcjonalny skrypt service worker.
injectManifest
preferuje większą elastyczność kosztem pewnej prostoty, ponieważ na koniec będziesz samodzielnie pisać kod skryptu service worker, a injectManifest
udostępnia plik manifestu wstępnego buforowania, którego można używać w przypadku metod wstępnego buforowania w Workbox.
Kiedy używać generateSW
Należy użyć metody generateSW
, jeśli:
- Chcesz wstępnie buforować pliki powiązane z procesem kompilacji, w tym pliki, których adresy URL zawierają hasze, których możesz nie znać z wyprzedzeniem.
- Masz proste potrzeby buforowania w środowisku wykonawczym, które można skonfigurować za pomocą opcji
generateSW
.
Kiedy nie należy używać usługi generateSW
Z drugiej strony nie należy używać właściwości generateSW
, jeśli:
- Chcesz użyć innych funkcji skryptu service worker (takich jak Web Push).
- Potrzebujesz dodatkowej elastyczności, aby zaimportować dodatkowe skrypty lub użyć konkretnych modułów Workbox, aby dostosować skrypt service worker do potrzeb aplikacji.
Kiedy używać injectManifest
Należy użyć metody injectManifest
, jeśli:
- Chcesz zapisać pliki w pamięci podręcznej, ale chcesz utworzyć własny skrypt service worker.
- Masz złożone potrzeby dotyczące buforowania lub routingu, których nie można wyrazić za pomocą opcji konfiguracji
generateSW
- Chcesz użyć w skrypcie service worker innych interfejsów API (na przykład Web Push).
injectManifest
różni się od generateSW
tym, że wymaga określenia źródłowego pliku skryptu service worker. W tym przepływie pracy źródłowy plik skryptu service worker musi zawierać specjalny ciąg znaków self.__WB_MANIFEST
, aby system injectManifest
mógł zastąpić go plikiem manifestu precache.
Kiedy nie należy używać usługi injectManifest
Nie używaj parametru injectManifest
, jeśli:
- Nie chcesz używać wstępnego buforowania w skrypcie service worker.
- nasze wymagania dotyczące skryptu service worker są na tyle proste, że pozwalają spełnić wymagania
generateSW
i jego opcji konfiguracji. - Priorytetowe są łatwość obsługi, a nie elastyczność.
Korzystanie z narzędzi do kompilacji w Workbox
Jeśli szukasz sposobu korzystania z Workbox w procesie kompilacji niezależnie od platformy, masz 3 możliwości:
workbox-cli
workbox-build
. narzędzie wiersza poleceń.- użycie narzędzia do tworzenia pakietów (np.
workbox-webpack-plugin
);
Każde z tych narzędzi do tworzenia zawiera zarówno tryby generateSW
, jak i injectManifest
, z podobnym zestawem opcji. To dobry wybór, gdy nie chcesz wiązać skryptu service worker obsługiwanego przez Workbox z konkretną platformą. Aby stwierdzić, która opcja jest dla Ciebie najlepsza, przyjrzyjmy się pokrótce każdej z nich.
workbox-cli
Jeśli szukasz najniższej możliwej bariery wejścia do Workbox, interfejs wiersza poleceń jest dla Ciebie:
npm install workbox-cli --save-dev
Aby zacząć korzystać z interfejsu wiersza poleceń, uruchom kreatora z npx workbox wizard
. Kreator zada kilka pytań, a odpowiedzi na nie zostaną użyte do skonfigurowania projektu z plikiem workbox-config.js
, który możesz dostosować do swoich potrzeb. Będzie to wyglądać mniej więcej tak:
// A config for `generateSW`
export default {
globDirectory: 'dist/',
globPatterns: [
'**/*.{css,woff2,png,svg,jpg,js}'
],
swDest: 'dist/sw.js'
};
Po utworzeniu pliku konfiguracji interfejs wiersza poleceń może uruchomić za Ciebie metodę generateSW
lub injectManifest
. Tekst pomocy interfejsu wiersza poleceń zawiera więcej informacji i przykładów użycia.
workbox-build
Język workbox-cli
to kod otaczający moduł workbox-build
. Zamiast tego możesz użyć kodu workbox-build
bezpośrednio. Gdy używasz workbox-build
, zamiast określania opcji w pliku workbox-config.js
będziesz używać metod generateSW
lub injectManifest
bezpośrednio w skrypcie węzła, przekazując podobny zestaw opcji:
// build-sw.mjs
import {generateSW} from 'workbox-build';
generateSW({
globDirectory: 'dist/',
globPatterns: [
'**/*.{css,woff2,png,svg,jpg,js}'
],
swDest: 'dist/sw.js'
});
W powyższym przykładzie workbox-build
zapisze wygenerowany skrypt service worker w katalogu dist
podczas wykonywania polecenia node build-sw.mjs
.
Korzystanie z pakietu
Różne pakiety mają swoje własne wtyczki Workbox, ale jedyny pakiet oficjalnie obsługiwany przez zespół Workbox to webpack przy użyciu workbox-webpack-plugin
. Podobnie jak workbox-cli
i workbox-build
, workbox-webpack-plugin
uruchomi metody generateSW
i injectManifest
, ale wtyczka zapisze te metody wielkimi literami, np. GenerateSW
lub InjectManifest
. Poza tym użycie jest podobne jak w przypadku workbox-build
:
// webpack.config.js
import {GenerateSW} from 'workbox-webpack-plugin';
export default {
// Other webpack config options omitted for brevity...
plugins: [
new GenerateSW({
swDest: './dist/sw.js'
})
]
};
Opcje przekazywane do: GenerateSW
lub InjectManifest
różnią się od opcji generateSW
lub injectManifest
, ale ich zakres znacznie się pokrywa. W szczególności nie musisz ani nie możesz określać opcji globDirectory
na potrzeby GenerateSW
, bo pakiet internetowy już wie, gdzie są łączone zasoby produkcyjne.
Użyj platformy
Wszystko omówione w tym punkcie dotyczy korzystania z Workbox bez względu na preferencje platformy. Możesz jednak użyć Workbox w ramach określonej platformy, jeśli ułatwia to programowanie. Na przykład create-react-app
domyślnie jest dostarczany z Workbox. Różne integracje platform z Workbox omówiliśmy w dalszej części artykułu.
Pamiętaj, że te specyficzne dla platformy integracje z Workbox mogą ograniczać możliwość konfigurowania Workbox w dowolny sposób. W takich przypadkach zawsze możesz skorzystać z metod omówionych tutaj.
Co zrobić, jeśli nie mam procesu kompilacji?
Zakładamy w nim, że Twój projekt ma proces kompilacji, ale w rzeczywistości nie. Jeśli mimo to pasuje do Twojej sytuacji, nadal możesz używać Workbox z modułem workbox-sw
. Dzięki workbox-sw
możesz wczytać środowisko wykonawcze Workbox z sieci CDN lub lokalnej i utworzyć własny skrypt service worker.
Podsumowanie
Dzięki jej elastyczności możesz używać go w prawie każdym projekcie, niezależnie od jego ustawień platformy czy łańcucha narzędzi. Wszystkie te sposoby pozwolą na zapisywanie w pamięci podręcznej i zapisywanie w pamięci podręcznej środowiska wykonawczego za pomocą kilku metod, jednocześnie zapewniając większą elastyczność tworzenia mechanizmów Service Worker z bardziej zaawansowanymi funkcjami w razie potrzeby.