odpowiedź w pamięci podręcznej skrzynki roboczej

Podczas buforowania zasobów w czasie działania nie ma uniwersalnej reguły określającej, czy dana odpowiedź jest „prawidłowa” i kwalifikuje się do zapisania oraz ponownego użycia.

Moduł workbox-cacheable-response to standardowy sposób określania, czy odpowiedź powinna być przechowywana w pamięci podręcznej, na podstawie jej numerycznego kodu stanu, obecności nagłówka z określoną wartością lub kombinacji tych 2 elementów.

Buforowanie na podstawie kodów stanu

Możesz skonfigurować strategię Workbox tak, aby zestaw kodów stanu kwalifikował się do buforowania. Aby to zrobić, dodaj instancję CacheableResponsePlugin 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 wysyłane do https://third-party.example.com/images/ buforuje wszystkie żądania z kodem stanu 0 lub 200.

Buforowanie na podstawie nagłówków

Możesz skonfigurować strategię Workbox, aby sprawdzała obecność określonych wartości nagłówka jako kryteriów dodawania do pamięci podręcznej. Aby to zrobić, ustaw obiekt 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 adresy URL żądań zawierających ciąg /path/to/api/ zwróć uwagę na nagłówek o nazwie X-Is-Cacheable (który zostanie dodany do odpowiedzi przez serwer). Jeśli ten nagłówek jest obecny i ma wartość „true”, odpowiedź może być przechowywana w pamięci podręcznej.

Jeśli określisz wiele nagłówków, tylko jeden z nich będzie pasować do powiązanych wartości.

Buforowanie na podstawie nagłówków i kodów stanu

Możesz łączyć zarówno konfigurację stanu, jak i konfiguracji nagłówka. Aby odpowiedź została uznana za zapis w pamięci podręcznej, muszą być spełnione oba warunki. Inaczej mówiąc, odpowiedź musi mieć jeden ze skonfigurowanych kodów stanu oraz musi zawierać co najmniej jeden 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ą wartości domyślne?

Jeśli korzystasz z wbudowanych strategii Workbox bez jawnego konfigurowania cacheableResponse.CacheableResponsePlugin, do określenia, czy odpowiedź otrzymana z sieci powinna być przechowywana w pamięci podręcznej, używane są te kryteria domyślne:

• nieaktualne podczas ponownej weryfikacji i siećFirst: odpowiedzi ze stanem 0 (tj. nieprzejrzyste odpowiedzi) lub 200 są uznawane za dostępne w pamięci podręcznej.
• cacheFirst: odpowiedzi ze stanem 200 są uznawane za zapisywane w pamięci podręcznej.

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?

Wartości domyślne różnią się w zależności od tego, czy odpowiedzi ze stanem 0 (tj. nieprzejrzyste odpowiedzi) będą przechowywane w pamięci podręcznej. Ze względu na to, że odpowiedzi są nieprzejrzyste „czarne skrzynki”, nie jest w stanie ustalić, czy skrypt service worker jest prawidłową odpowiedzią lub czy odzwierciedla odpowiedź o błędzie zwróconą z serwera z innych domen.

W przypadku strategii obejmujących pewne sposoby aktualizowania odpowiedzi z pamięci podręcznej, takie jak staleWhenrevalidate i networkFirst, ryzyko zapisywania w pamięci podręcznej chwilowych odpowiedzi o błędzie jest ograniczone przez fakt, że przy następnej aktualizacji pamięci podręcznej prawdopodobnie zostanie użyta prawidłowa odpowiedź.

W przypadku strategii, które obejmują przechowywanie pierwszej otrzymanej odpowiedzi w pamięci podręcznej i wielokrotne ponowne wykorzystywanie tej odpowiedzi w pamięci podręcznej, skutki tymczasowego przechowywania i ponownego użycia błędu są bardziej poważne. Aby domyślnie podjąć tę decyzję, cacheFirst odmówi zapisania odpowiedzi, chyba że ma ona kod stanu 200.

Zaawansowane użycie

Jeśli chcesz używać tej samej logiki buforowania poza strategią Workbox, możesz użyć bezpośrednio 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.
}