Заставить Service Service Worker возвращать кэшированные ответы только при открытой конкретной странице

Question

Я построил портал, который предоставляет доступ к нескольким функциям, включая функцию уведомления о неисправностях.

Клиент попросил меня сделать функцию уведомления о неисправностях доступной в автономном режиме.Они хотят иметь возможность «проверять» определенные существующие билеты в режиме онлайн, которые затем становятся доступны (просмотр / редактирование), когда устройство пользователя находится вне зоны действия любого интернет-соединения.Кроме того, они хотят иметь возможность создавать новые билеты в автономном режиме.Затем, когда соединение будет доступно, они проверит измененные / вновь созданные заявки.

Я возился с работниками сервиса и просматривал некоторую хорошую документацию по ним, и я чувствую, что у меня есть общее представление о том, каккешировать данные.

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

Как настроить работника службы так, чтобы он отвечал только кэшированными данными, когдастраница билетов открыта?

Нужно ли вручную проверять значение window.location при возникновении событий выборки?Например,

if (window.location == 'https://www.myurl.com/tickets')
{
    // try to get the request from network. If successful, cache the result.
    // If not successful, try returning the request from the cache.
}
else
{
    // only try the network, and don't cache the result.
}

Существует множество вспомогательных файлов, которые необходимо загрузить для страницы (например, CSS-файлы, JS-файлы и т. Д.), Поэтому недостаточно просто проверить request.url для страницы.название.Будет ли 'window.location' доступен в событии работника службы, и является ли это разумным способом для достижения этой цели?

Answer 1

Использование работника сферы обслуживания

Я знаю, что вы упомянули, что в настоящее время все страницы обслуживаются из одного каталога ... но если у вас есть какая-либо гибкость в отношении структуры URL вашего веб-приложения, тогда самый чистыйподход будет заключаться в том, чтобы обслуживать функциональность вашего тикета по URL-адресам, которые начинаются с уникального префикса пути (например, /tickets/), а затем размещают работника службы с /tickets/service-worker.js.Усилия по реорганизации ваших URL-адресов могут быть полезны, если это означает, что они могут воспользоваться преимуществами определения объема работника службы по умолчанию и просто не беспокоиться о том, что страницы за пределами /tickets/ контролируются работником службы.

InferРеферер

В этом ответе содержится информация о том, какой URL-адрес window клиента ссылается из обработчика fetch вашего работника сервиса.Вы можете объединить это с начальной проверкой в ​​обработчике fetch, чтобы увидеть, является ли это запросом навигации, и использовать его для раннего выхода.

const TICKETS = '/tickets';
self.addEventListener('fetch', event => {
  const requestUrl = new URL(event.request.url);
  if (event.request.mode === 'navigate' && requestUrl.pathname !== TICKETS) {
    return;
  }

  const referrerUrl = ...; // See https://stackoverflow.com/questions/50045641
  if (referrerUrl.pathname !== TICKETS) {
    return;
  }

  // At this point, you know that it's either a navigation for /tickets,
  // or a request for a subresource from /tickets.
});