Как я могу обнаружить в сервисе работника выборки, что запрос для манифеста start_url? - PullRequest
Новая
       31

Как я могу обнаружить в сервисе работника выборки, что запрос для манифеста start_url?

0 голосов
/ 10 апреля 2019

У меня есть PWA, у которого есть manifest.json с start_url.

У меня есть работник службы с событием fetch, который кэширует только определенные запросы. Это делается в сервисе работника путем переопределения ответа на прокси из кэша (для ясности TypeScript): 

self.addEventListener('fetch', (event: FetchEvent) => {
    // This MUST be synchronous until respondWith is called

    const cache = isCachable(event.request);
    if (!isCachable)
        return; // Don't proxy, let the network request continue

    // Kick off a promise to check the cache, and clone/cache the response otherwise
    const proxy: Promise<Response> = cacheResponse(event);

    event.respondWith(proxy);
}

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

Я могу загрузить manifest.json в ПО, но это кажется неуклюжим. Я могу жестко запрограммировать значения в SW, но затем мне нужно обновить два места, если конфигурация изменится.

В обработчике fetch event.request.url является абсолютным, но start_url относительно manifest.json - так, например, я мог бы иметь:

  • manifest.json: { "start_url": "appshell" ... }
  • Веб-сайт развертывается на www.example.com/folder/ (но может быть развернут на sub.example.com или www.example.com/a/b или где-либо еще)
  • Онлайн пользователь посещает сайт, либо посещает все, либо устанавливает кеш скриптов напрямую.
  • Позже, тот же пользователь посещает в автономном режиме.
  • Вызов выше стреляет с event.request.url === 'www.example.com/folder/appshell'
  • Мне нужна функция isCachable, чтобы сказать, что ресурс должен кэшироваться синхронно. Необходимо определить, что www.example.com/folder/appshell равно appshell (разрешить относительную ссылку) и что appshell установлено как start_url (прочитайте манифест).

Очевидно, что все это может быть жестко закодировано. Тем не менее, каждый PWA должен отвечать из кэша на start_url, так что это не может быть новой проблемой. Прежде, чем я изобрету колесо, есть ли лучший способ или что-то, чего мне не хватает?

Итак ...

  • Учитывая, что работникам службы нужен манифест, есть ли хороший способ получить конфигурацию манифеста в работнике?
  • Есть ли способ разрешить относительную ссылку для сравнения с манифестом?

1 Ответ

0 голосов
/ 14 мая 2019

Я понял, как это сделать, но это противно, и я уверен, что есть лучший способ.

В частности, я жестко кодирую в манифесте inline (я мог бы fetchэто, но это тоже противно). 

const manifest = { start_url: 'appshell' };

Тогда я использую self.location, чтобы узнать путь работника службы.Это включает в себя имя файла, поэтому я обрежу его до конца: 

// if file is 'sw.js' that's 5 chars off the end
const applicationRoot = new URL(self.location.href.slice(0, -5) + manifest.start_url);

Затем я могу проверить это: 

self.addEventListener('fetch', (event: FetchEvent) => {
    // This MUST be synchronous until respondWith is called

    const url = new URL(event.request.url);
    if (url.pathname === applicationRoot.pathname) {
        // Request is for the start_url, always return something so the PWA starts offline
        event.respondWith(...):
    }

    // ... see question for rest
});

Это неуклюже, но, по крайней мере, оно всегда может служитькэшированный start_url без кэширования всего остального, так что пока это принятый ответ.Я хотел бы увидеть лучший способ сделать это, в идеале без жесткого кодирования / извлечения manifest.json, чтобы изменения конфигурации не требовали нового работника сервиса.

...