Принудительно обновлять установленный PWA при изменении index.html (предотвратить кэширование)

Question

Я создаю приложение реакции, которое состоит из одностраничного приложения, размещенного на Amazon S3.

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

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

Поскольку я использую Webpack для сборки приложения, оно генерирует пакеты с хешами в их именах, в то время как файл index.html, который определяет пакеты, которые следует использовать, загружается со следующим свойством cache-control: "no-cache, no-store, must-revalidate" , Рабочий файл службы имеет ту же политику кэширования.

Идея состоит в том, что браузер пользователя может кэшировать все, кроме первых необходимых им файлов. План был хорош, но я заменяю файл index.html на более новую версию, и мои пользователи не перезагружают этот файл при перезапуске приложения.

Существует ли полное руководство или способ обойти эту проблему?

Я также знаю, что PWA должен работать в автономном режиме, поэтому он должен иметь возможность кэширования для повторного использования, но эта идея также не помогает мне выполнять масштабное и мгновенное обновление, верно?

Какие у меня есть лучшие варианты?

Answer 1

Вы правильно поняли основную идею. Почему ваш index.html не обновляется - это сложный вопрос, так как вы не предоставляете никакого кода - пожалуйста, включите ваш код Service Worker. Имейте в виду, что в зависимости от логики, реализованной в Service Worker, он не обязательно учитывает заголовки кэширования HTTP и будет кэшировать все, включая файл index.html, как это сейчас происходит.

Чтобы приложение работало также в автономном режиме, вам, вероятно, следует использовать стратегию network-first SW. При использовании сначала сети браузер пытается загрузить файлы из Интернета, но если это не удается, он возвращается к последней кэшированной версии конкретного файла, который он пытался получить. Другой вариант - выбрать так называемую стратегию stale-while-revalidate . Это сначала дает пользователю старый файл (который очень быстрый), а затем обновляет файл в фоновом режиме. Есть и другие стратегии, я предлагаю вам ознакомиться с документацией наиболее широко используемой библиотеки ПО Workbox [https://developers.google.com/web/tools/workbox/modules/workbox-strategies].

Одна вещь, которую нужно иметь в виду: Во всех других стратегиях, кроме «пропустить SW и перейти в сеть», вы не можете гарантировать, что пользователь получит последнюю версию index.html. Это невозможно. Если ПО возвращает что-то из кэша, это может быть старая версия, и все. В таких ситуациях обычно делается уведомление пользователя о том, что новая версия приложения была загружена в фоновом режиме. Обычно пользователь загружает приложение, видит версию, которая была доступна в кеше, а ПО затем проверяет наличие обновлений. Если было найдено обновление (появился новый index.html и, следовательно, новый service-worker.js), пользователь увидит уведомление о том, что страница должна быть обновлена. Вы также можете запустить ПО для проверки наличия обновлений с сервера вручную из собственного кода JS, если хотите. В этой ситуации вы также будете показывать уведомление пользователю.

Вам это помогает?