Предварительное кэширование с устаревшими при повторной проверке стратегии в Workbox

Вопрос

Можно ли предварительно кэшировать файл с помощью другой стратегии? т.е. Устаревший при повторной проверке?

Или мне просто загрузить скрипт в DOM, а затем добавить для него маршрут в worker с правильной стратегией?

Фон

Это довольно странный случай, поэтому я постараюсь объяснить его как можно лучше ...

  • У нас есть два репо; PWA и Игры
  • Оба статически размещены в одном CDN.
  • Из-за того, что репозиторий Games является отдельным, PWA не имеет доступа к управлению версиями пакетов js игры.
  • Поэтому решение, которое я придумал, - это создать неверсированный манифест (game-manifest.js) в сборке Games.
  • Затем PWA предварительно кэширует этот файл, просматривает его содержимое и добавляет каждую запись в существующий манифест предварительного кеширования.
  • Однако, учитывая, что game-manifest.js не имеет изменений и не хешируется, нам необходимо применить стратегию Сначала сеть или Устаревший при повторной проверке, чтобы файл обновлялся при становятся доступны новые версии

См. Следующий код как более ясный пример того, что я пытаюсь сделать:

import { precacheAndRoute } from 'workbox-precaching';

// Load the game manifest
// THIS FILE NEEDS TO BE PRECACHED, but under the strategy
// of stale while revalidate, or network first.
importScripts('example.cdn.com/games/js/game-manifest.js');

// Something like...
self.__gameManifest.forEach(entry => {
    self.__precacheManifest.push({
        url: entry
    });
});

// Load the assets to be precached
precacheAndRoute(self.__precacheManifest);

person Ben Carey    schedule 04.09.2019    source источник


Ответы (1)


Вообще говоря, при использовании workbox-precaching невозможно заменить альтернативную стратегию. Он всегда будет сначала кешировать, а информация о версиях в манифесте предварительного кеширования контролирует, как происходят обновления.

Более подробное обсуждение проблемы см. На странице https://github.com/GoogleChrome/workbox/issues/1767

Рекомендуемый способ действий - явно настроить маршруты кэширования времени выполнения используя стратегию, которую вы предпочитаете, и потенциально «заправить» кеш, предварительно добавив в него записи на шаге install.

person Jeff Posnick    schedule 10.09.2019
comment
Большое спасибо за это Джеффу! Я боялся, что это будет так, но, прочитав ссылку, которую вы разместили, теперь понимаю, почему. Учитывая описанный мною уникальный вариант использования, не могли бы вы дать немного дополнительных указаний относительно того, что вы будете делать? Например, вы бы использовали код, аналогичный тому, что я опубликовал, а потом просто определяли бы маршрут кэша времени выполнения? Это вообще сработает? т.е. сможет ли он распознать, что example.cdn.com/games/js/game-manifest.js уже загружен? Вы можете привести пример «заливки» кеша на шаге install? - person Ben Carey; 11.09.2019