Фон
Я новичок в обслуживании, но работаю над библиотекой, которая должна стать "оффлайн-первой" (фактически, почти "автономной") (FWIW, цель состоит в том, чтобы позволить пользователям библиотеки предоставлять конфигурацию JSON, представляющую табличные многолинейные тексты и получить взамен приложение, которое позволяет своим пользователям просматривать эти тексты с высокой степенью настраиваемости по диапазонам абзацев/стихов).
Другими проектами являются установка библиотеки в качестве зависимости, а затем предоставление информации через наш JavaScript API, такой как путь к файлу конфигурации JSON, указывающий файлы, которые наше приложение будет использовать для создания (офлайн-приложения) для них.
Хотя я знаю, что мы могли бы сделать одно из следующего:
- требуют, чтобы пользователи предоставили жестко закодированный путь, из которого наш
install
скрипт нашего рабочего может использоватьwaitUntil
со своим собственным запросом JSON для извлечения необходимых файлов пользователя - пропустите шаг
install
рабочего сотрудника сервисного работника для файла JSON и полагайтесь на событияfetch
чтобы обновить кеш, предоставив резервный дисплей, если пользователь завершил установку и отключился до того, как могут произойти выборки. - Отправьте некоторую информацию о состоянии из нашего основного сценария на сервер, на который работник службы, после регистрации, запросит запрос перед завершением своего события
install
.
... но все варианты кажутся менее идеальными, потому что, соответственно:
- Наши пользователи библиотеки могут предпочесть, чтобы они могли определять свое местоположение для своей конфигурации JSON.
- Учитывая, что конфигурация JSON определяет файлы, критически важные для того, чтобы показать своим пользователям что-нибудь полезное, я бы предпочел не допускать установку только для того, чтобы сказать, что пользователь должен вернуться в онлайн, чтобы получить остальную часть файлов, если они не смогли остаться онлайн после события
install
чтобы увидеть все необходимые выборки. - Кроме того, чтобы избежать большего количества поездок на сервер и дополнительного кода, я бы предпочел, чтобы наш код был настолько автономным, чтобы полностью работать на простых статических файловых серверах.
Вопрос:
Есть ли способ передать сообщение или информацию о состоянии в сервис-работник до того, как произойдет событие install
, будь то в строке запроса URL-адреса рабочего агента или через событие обмена сообщениями? Событие обмена сообщениями может даже технически прибыть после того, как событие install
начнется до тех пор, пока оно может произойти до того, как waitUntil
завершена install
waitUntil
.
Я знаю, что я мог бы проверить это сам, но я хотел бы знать, какие могут быть лучшие методы, когда критические файлы приложений должны быть динамически получены, как в таких библиотеках, как наши.
Я предполагаю, что indexedDB
может быть единственной альтернативой здесь (т. indexedDB
конфигурационную информацию или путь конфигурации JSON к индексированномуDB, зарегистрировать сервисного работника и получить данные индексированных данных из события install
)? Даже это не было бы идеальным, так как я позволяю пользователям определять пространство имен для их хранения, но мне нужен способ, чтобы он тоже мог быть передан работнику, иначе может возникнуть столкновение нескольких таких приложений в происхождении.