Jeśli zasoby są buforowane w czasie działania, nie ma uniwersalnej reguły, która decydowałaby, czy dana odpowiedź to „prawidłowy” oraz możliwość ich zapisania i ponownego wykorzystania.
Moduł workbox-cacheable-response
zapewnia standardowy sposób określania, czy odpowiedź powinna zostać zapisana w pamięci podręcznej na podstawie kodu stanu numerycznego, obecności nagłówka z określoną wartością lub kombinacji tych dwóch elementów.
Buforowanie na podstawie kodów stanu
Możesz skonfigurować strategię obszaru roboczego, którą warto rozważyć:
zestawu kodów stanu jako kwalifikujących się do buforowania, dodając
CacheableResponsePlugin
wystąpienie do parametru plugins
strategii:
import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';
registerRoute(
({url}) =>
url.origin === 'https://third-party.example.com' &&
url.pathname.startsWith('/images/'),
new CacheFirst({
cacheName: 'image-cache',
plugins: [
new CacheableResponsePlugin({
statuses: [0, 200],
}),
],
})
);
Ta konfiguracja informuje Workbox, że podczas przetwarzania odpowiedzi na żądania dotyczące https://third-party.example.com/images/
należy przechowywać w pamięci podręcznej wszystkie żądania z kodem stanu 0
lub 200
.
Buforowanie na podstawie nagłówków
Możesz skonfigurować strategię obszaru roboczego, aby sprawdzić,
obecności określonych wartości nagłówka jako kryteriów dodawania
do pamięci podręcznej przez ustawienie obiektu headers
podczas tworzenia wtyczki:
import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';
registerRoute(
({url}) => url.pathname.startsWith('/path/to/api/'),
new StaleWhileRevalidate({
cacheName: 'api-cache',
plugins: [
new CacheableResponsePlugin({
headers: {
'X-Is-Cacheable': 'true',
},
}),
],
})
);
Podczas przetwarzania odpowiedzi na żądania z adresami URL zawierającymi /path/to/api/
sprawdź nagłówek o nazwie X-Is-Cacheable
(zostanie on dodany do odpowiedzi przez serwer). czy ten nagłówek występuje i czy występuje w niej;
ma wartość „true” (prawda), odpowiedź może być zapisywana w pamięci podręcznej.
Jeśli podano kilka nagłówków, tylko jeden z nich musi być zgodny z powiązanymi wartościami.
Buforowanie na podstawie nagłówków i kodów stanu
Możesz stosować dowolne kombinacje stanów i konfiguracji nagłówka. Aby odpowiedź mogła zostać uznana za nadającą się do zapisania w pamięci podręcznej, muszą być spełnione oba te warunki. Innymi słowy, odpowiedź musi zawierać jeden z skonfigurowanych kodów stanu oraz co najmniej 1 z podanych nagłówków.
import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';
registerRoute(
({url}) => url.pathname.startsWith('/path/to/api/'),
new StaleWhileRevalidate({
cacheName: 'api-cache',
plugins: [
new CacheableResponsePlugin({
statuses: [200, 404],
headers: {
'X-Is-Cacheable': 'true',
},
}),
],
})
);
Jakie są domyślne wartości?
Jeśli używasz jednej z wbudowanych strategii Workbox bez
podczas konfigurowania cacheableResponse.CacheableResponsePlugin
zostaną zastosowane następujące kryteria domyślne
używany do określenia, czy odpowiedź otrzymana z sieci powinna
zapisać w pamięci podręcznej:
- staleWhileRevalidate i networkFirst: odpowiedzi o stanie
0
(czyli nieprzejrzystych odpowiedzi) lub200
są uważane za nadające się do zapisania w pamięci podręcznej. - cacheFirst: odpowiedzi o stanie
200
są uważane za możliwe do buforowania.
Domyślnie nagłówki odpowiedzi nie są używane do określania możliwości buforowania.
Dlaczego występują różne wartości domyślne?
Domyślne wartości zależą od tego, czy odpowiedzi o stanie 0
(czyli nieprzejrzystych odpowiedzi) zostaną zapisane w pamięci podręcznej. Z powodu „czarnego skrzynki” nieprzejrzyste odpowiedzi
nie jest możliwe, aby skrypt service worker wiedział, czy odpowiedź
jest prawidłowy lub czy odzwierciedla odpowiedź błędu zwróconą przez
między domenami.
W przypadku strategii, które obejmują pewne sposoby aktualizowania odpowiedzi z pamięci podręcznej, np. staleWhileRevalidate i networkFirst, ryzyko załadowania do pamięci podręcznej tymczasowej odpowiedzi z błędem jest ograniczone przez fakt, że przy następnej aktualizacji pamięci podręcznej zostanie użyta prawidłowa, pomyślna odpowiedź.
W przypadku strategii, które polegają na przechowywaniu w pamięci podręcznej pierwszej otrzymanej odpowiedzi i jej wielokrotnym wykorzystywaniu, konsekwencje tymczasowego błędu w pamięci podręcznej i jego ponowne wykorzystanie są poważniejsze. Aby popełniać błędy
dla bezpiecznego przechowywania danych, domyślnie cacheFirst odrzuca zapisanie odpowiedzi, chyba że
ma kod stanu 200
.
Zaawansowane użycie
Jeśli chcesz używać tej samej logiki buforowania poza strategią Workbox, możesz bezpośrednio użyć klasy CacheableResponse
.
import {CacheableResponse} from 'workbox-cacheable-response';
const cacheable = new CacheableResponse({
statuses: [0, 200],
headers: {
'X-Is-Cacheable': 'true',
},
});
const response = await fetch('/path/to/api');
if (cacheable.isResponseCacheable(response)) {
const cache = await caches.open('api-cache');
cache.put(response.url, response);
} else {
// Do something when the response can't be cached.
}
Typy
CacheableResponse
Ta klasa umożliwia konfigurowanie reguł określających, jakie kody stanu lub nagłówki muszą być obecne, aby Response
mogła zostać umieszczona w pamięci podręcznej.
Właściwości
-
konstruktor
nieważne
Aby utworzyć nową instancję klasy CacheableResponse, musisz podać co najmniej jedną z właściwości
config
.Jeśli podano zarówno parametr
statuses
, jak iheaders
, muszą być spełnione oba warunki, aby parametrResponse
mógł być przechowywany w pamięci podręcznej.Funkcja
constructor
ma postać:(config?: CacheableResponseOptions) => {...}
-
konfiguracja
CacheableResponseOptions opcjonalne
-
returns
-
-
isResponseCacheable
nieważne
Sprawdza, czy można umieścić odpowiedź w pamięci podręcznej, na podstawie konfiguracji obiektu.
Funkcja
isResponseCacheable
ma postać:(response: Response) => {...}
-
odpowiedź
Odpowiedź
Odpowiedź, której dotyczy sprawdzanie możliwości umieszczenia w pamięci podręcznej.
-
returns
wartość logiczna
true
, jeśliResponse
może być buforowana, afalse
w przeciwnym razie.
-
CacheableResponseOptions
Właściwości
-
nagłówki
obiekt opcjonalny
-
statusy
liczba[] opcjonalnie
CacheableResponsePlugin
Klasa implementująca wywołanie zwrotne cyklu życia cacheWillUpdate
. Dzięki temu
łatwiejsze dodawanie kontroli buforowalności do żądań wysyłanych za pomocą wbudowanych narzędzi Workbox
strategii ustalania stawek.
Właściwości
-
konstruktor
nieważne
Aby utworzyć nową instancję klasy CacheableResponsePlugin, musisz podać co najmniej jedną z właściwości
config
.Jeśli podano zarówno parametr
statuses
, jak iheaders
, muszą być spełnione oba warunki, aby parametrResponse
mógł być przechowywany w pamięci podręcznej.Funkcja
constructor
ma postać:(config: CacheableResponseOptions) => {...}
-
konfiguracja
-
returns
-