Как работает URL для ServiceWorker cache.addAll ()?

Question

Как работает URL для ServiceWorker cache.addAll ()?

1

Я вижу много примеров кода вроде этого: (Немного сокращенная версия этого Mozilla Doc)

this.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open('v1').then(function(cache) {
      return cache.addAll([
        '/sw-test/',
        '/sw-test/index.html',
        '/sw-test/style.css',
        '/sw-test/gallery/',
        '/sw-test/gallery/bountyHunters.jpg',
      ]);
    })
  );
});

Я не понимаю, почему вы добавляете оба параметра /sw-test/ и /sw-test/index.html. Похоже, что либо первый URL-адрес папки должен автоматически загружать все под ним, либо, если это не так, почему это так? То же самое для /sw-test/gallery/ и /sw-test/gallery/bountyHunters.jpg.

Документы говорят: "Метод addAll() интерфейса Cache принимает массив URL-адресов, извлекает их и добавляет результирующие объекты ответа в данный кеш". Это не очень полезно.

То, что я действительно хочу сделать, - это кешировать все *.html файлы из нескольких папок и всех файлов изображений (в разных форматах) из другой папки. Листинг их по одному является хрупким (быстро выйдет из синхронизации), склонным к опечаткам, и просто глупо.

Добавлено позже

После дальнейшего чтения не похоже, что существуют маски, так глупо. :-) Но зачем добавлять такую папку, как /sw-test/?

user949300 14 сен. 2017, в 02:20

Источник

Теги:

javascript

caching

service-worker

2 ответа

0

Основываясь на ответе pate выше: sw-precache и sw-toolbox - это две библиотеки, которые обычно рекомендуются при внедрении Service Workers, поскольку они позволяют использовать эту функцию.

Richard Connon 18 сен. 2017, в 08:49

0

sw-toolbox и sw-precache устарели в пользу Workbox (по этой ссылке: github.com/GoogleChromeLabs/… )
Yury Kozlov 01 сен. 2019, в 23:53

Ещё вопросы

sw-toolbox и sw-precache устарели в пользу Workbox (по этой ссылке: github.com/GoogleChromeLabs/… )

pate · Accepted Answer · 2017-09-14T04-35-00.000Z

Да, подстановочный знак не существует, и это на самом деле совершенно разумно, когда вы думаете об этом: веб-сервер не обнаруживает файлы, найденные в пути (например,/gallery/), так как могут файлы кэша браузера, которые он не знает названия? Разумеется, веб-сервер может быть настроен для отображения списков каталогов пути, но сами браузеры не имеют возможности "взять все с этого пути x". Список каталогов/индексов - это всего лишь куча HTML, а не сопоставление файлов.

Кэширование как /, так и /index.html немного запутанно, но с точки зрения Service Worker они представляют собой разные URL-адреса. Обычно веб-сервер настроен на обслуживание одного и того же файла (index.html) в зависимости от того, какой URL вы посещаете, но если вы спросите SW, они являются отдельными и должны иметь отдельные записи в кеше. Это можно легко протестировать: развернуть что-то, что кэширует /not not/index.html (хотя веб-сервер обслуживает index.html из /) и пытается посетить /index.html в автономном режиме. Неудачно.

Я не думаю, что есть какие-либо причины для кэширования /index.html, если вы полностью уверены, что ваше веб-приложение никогда не делает никаких запросов на него. Если ваше веб-приложение знает только о том, что /then leave/index.html out должно быть полностью в порядке. Я сам это испытал, и он отлично работает. Если у кого-то больше информации по этому вопросу, пожалуйста, исправьте меня!

Следует отметить, что это может быть полезно: SW может быть настроен так, чтобы обрабатывать/и /index.html. Таким образом, кэширование и обслуживание при каждом запросе возможно. Я предполагаю, что некоторые из библиотек имеют встроенную функциональность.