Как заставить сервисного работника обновить?

Я использую sw-precache для создания моей службы работы с процессом сборки CLI Polymer, поэтому он предназначен для обновления хэша обновленных файлов, чтобы сигнализировать о необходимости обновления кеша. Но мой обновленный контент не заменяется в кеше, поэтому он получает старую версию, если я обновляю ctrl + r, но новую версию, если я обновляю ctrl + shift + r. Причиной этого может быть то, что мой сервисный работник не обновляется.Как заставить сервисного работника обновить?

This doc утверждает, что

Если есть даже разница БАЙТА в рабоче файле службы по сравнению с тем, что она в настоящее время, он считает, что новым.

, но что, если мой новый сервисный работник не изменил байта? (как это происходит, если изменился только один хеш). Как настроить sw-precache для обновления работы службы при каждом новом запросе?

источник

2017-01-27 Jp_

Вы посмотрели на это? https: //developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/skipWaiting И, пожалуйста, подтвердите, что хеши работают правильно: это означает, что после изменения файла кэшированных активов он отражает его для обслуживания рабочего содержимого. Другими словами, изменение значения хэш-функции у обслуживающего. Опасайтесь, что ** SW не заботится и не может проверять содержимое или версию файлов активов **. Единственное, что может вызвать его обновление - это собственный контент. Таким образом, изменения в файлах активов должны отражать их ссылки в SW. например '/style.css? {hash-of-the-file}' –

Я уверен, что хэш меняется. «SkipWaiting» я не тестировал, я прочитал документацию и понял, что это предназначено для принудительного обновления без перезагрузки страницы. Мое дело, похоже, отличается от того, как жизненный цикл сервисного работника заканчивается, когда есть еще один, ожидающий, и страница перезагружается без необходимости «skipWaiting». –

Это просто неправда. [см. Документацию] (https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Updating_your_service_worker) _... новая версия установлена в фоновом режиме, но еще не установлена активируется. Он активируется только тогда, когда больше не загружаются страницы, которые все еще используют старый рабочий службы. Как только таких страниц еще не загружены, активируется новый сервисный работник. –

Если хэш-файл одного файла изменен, этого достаточно, чтобы убедиться, что файл JavaScript службы поддержки, сгенерированный sw-precache, изменяется. Этого, в свою очередь, достаточно, чтобы инициировать поток обновления сервисного сотрудника.

Если вы не видите поток обновлений, инициированный при тестировании, то это может быть связано с тем, что файл JavaScript службы поддержки обслуживается с заголовками кеширования HTTP, которые вызывают его из кэша браузера, а не из сеть.

См. https://stackoverflow.com/a/38854905/385997 для обсуждения того, как заголовки кеширования HTTP вступают в игру, и лучшие практики в отношении этого.

источник

2017-01-31 16:40:55

Как указывалось в предыдущих ответах, существует 1-дневный (24-часовой) встроенный лимит для браузера, чтобы искать обновления для сервисного работника, но то, что вам нужно помнить, вам все равно нужно позвонить .update() на ваш объект ServiceWorkerRegistration, в противном случае будет использоваться исходная версия файла.

При тестировании изменений в Chrome я всегда щелкаю правой кнопкой мыши по кнопке обновления и выбираю «Пустой кэш и жесткий сброс» (параметры доступны, когда инструменты разработчика открыты) при работе со сценарием рабочего стола.

источник

2017-08-29 19:35:06 jcaruso

Хороший хром, я бы никогда не заметил. –

«SW-предварительное кэширование» было заменено Workbox, который генерирует хэш для файлов, которые вы хотите для кэширования и добавляет те, к исходному коду вашего рабочему сервиса (я не знаю, если sw-precache работает точно так же, ответ Джефф предполагает, что это делает). Если какой-либо из файлов, которые вы хотите изменить, - и вы повторно запустите свою сборку - обновлены хэши в вашем сервисном работнике, которые в значительной степени гарантируют, что работник службы будет «по меньшей мере один байт».

Когда вы перезагружаете (ctrl-r) или повторно посещаете приложение, браузер снова загрузит зарегистрированного для него сервисного работника. И если этот сервисный работник изменился, он будет «поставлен в очередь» для управления приложением. Но он не начнет управлять приложением, пока вы не закроете все вкладки при открытии приложения, а затем откройте новый.

Когда вы постоянно обновляете (shift-ctrl-r) it’ll always load without a controller, который не совпадает с вашим новым работником службы.

Для тестирования во время разработки я использую skip waiting в devtools, чтобы новый сервисный рабочий заменил старый, не дожидаясь закрытия всех вкладок.

источник

2017-10-19 10:24:35 Bitterjug

Как заставить сервисного работника обновить?

ответ

Смежные вопросы