Позвольте пользователю выбрать обновление Service Worker

Question

Можно ли разрешить пользователю выбирать, когда обновлять Service Worker?

Почему? Я хочу добавить экономичный режим, который означает, что пользователь может выбрать сохранение большой пропускной способности. Это может быть полезно, когда пользовательский лимит почти заполнен или он использует дорогой интернет за границей.

Это потому, что если Service Worker обновляется и появляются версии новых активов, он будет загружать все из них, которые могут быть несколько MB. Если у вас 3 дня и 50 МБ от нового месяца, каждый подсчет МБ.

---

Допустим, что я могу получить настройки от LocalStorage:

const economy = localStorage.getItem(economy) || false 

Как дать Service Worker знать, что она должна только обновить себя, если экономика верно?

---

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

Answer 1

Если вы готовы обработать обновление/удаление (возможно, только подмножество) записей кэша вне событий install и activate, у вас будет больше гибкости в том, когда они должны быть запущены. Фактически, вам вообще не нужно выполнять обновления в сервисном работнике, если вам становится легче. Отдельные веб-страницы имеют доступ к тем же самым Cache Storage API экземплярам, ​​которые использует обслуживающий работник для данного источника. Вы можете изменить кэша непосредственно со страницы в ответ на любые действия, которые делают большинство смысла для вас, например:

// Ensure we have access to the Cache Storage API. 
if ('caches' in window) { 
    // Swap this out for whatever UI element will trigger the update. 
    const el = document.querySelector('#update-caches-button'); 
    el.addEventListener('click',() => { 
    window.caches.open('my-cache').then(cache => { 
     // Add or delete entries from cache. 
    }); 
    }); 
} 

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

Есть некоторые преимущества, связанные с событиями install/activate для управления кешем. В частности, вы можете полагаться на обслуживающего сотрудника, находящегося в "waiting" state, в то время как есть другие активные клиенты, которые полагаются на предыдущее состояние кеша, и не нужно беспокоиться о том, чтобы отбросить записи, которые понадобятся этим другим клиентам или обменять ожидаемая версия ресурса для новой версии, пока она все еще используется. Но как разработчик, в конечном счете, вы несете ответственность за понимание того, как используются ваши кешированные ресурсы, и если активы, которыми вы управляете в этих кэшах, вряд ли вызовут проблемы, если есть несоответствие версии или если что-то, что было удалено одна вкладка должна быть извлечена из сети позже другой вкладкой, тогда вы можете реализовать такой подход.

Для чего это стоит, мы подумали о подобных проблемах при реализации precaching/updates в sw-precache. Есть некоторый фон в https://github.com/GoogleChrome/sw-precache/issues/145 о попытке использовать стандартные сигналы, открытые браузерами, что указывает на то, что пользователь предпочитает сохранять данные, а не все, кто придумывает их собственную эвристику.