Маршруты кэшируются работником сервиса в ответ

Question

Мы находимся в процессе создания нового веб-сайта для компании, в которой я работаю, и написанной на React с использованием CRA. Push-уведомления в браузере и PWA необходимы, так что сервисный работник необходим, однако я считаю, что сервисный работник несет ответственность за некоторые довольно серьезные проблемы с кэшированием.

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

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

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

У меня вопрос, каковы шаги дляaviod эта проблема, и я на правильных линиях, думая, что управление версиями уменьшит?

Answer 1

Семантическое управление версиями в этом контексте не имеет никакого смысла, вы, скорее всего, читали о пакетах (библиотеках, инфраструктурах), которые публикуются в NPM для использования в мире. В проектах CRA, а также в большинстве других веб-проектов управление версиями вашего приложения происходит с помощью инструментов сборки, которые называют файлы на основе их содержимого. Имена файлов включают в себя хэш содержимого и автоматически обновляются при изменении содержимого, например. app.iue9234980s.js становится app.92384oujiuoisdf.js и т. д.

-

Если вы используете настройку default Service Worker, предоставленную CRA, то вам следуетпосмотрите на src / serviceWorker.js. В комментариях к этому файлу написано

// This lets the app load faster on subsequent visits in production, and gives
// it offline capabilities. However, it also means that developers (and users)
// will only see deployed updates on subsequent visits to a page, after all the
// existing tabs open on the page have been closed, since previously cached
// resources are updated in the background.

. Здесь происходит то, что SW и процесс сборки используют библиотеку Workbox SW, настроенную для использования политики предварительного кэширования. В этой политике пользователи получают последнюю версию, которая ранее была кэширована, из кэша браузера, даже если доступна новая версия, затем в фоновом режиме ПО обновляет кэши, и при повторном посещении пользователи получают более новую версию. Это, конечно, означает, что пользователи всегда могут быть на одну версию «поздней».

Если это поведение не то, что вам нужно, вам нужно изменить src / serviceWorker.js и, возможно, некоторую конфигурацию где-нибудь в файлах CRA. Для примера вы должны использовать что-то вроде «работники таможенной службы с cra».

Чтобы лучше понять, что происходит, и особенно то, что является правильным и предполагаемым поведением в разных случаях, я настоятельно рекомендую (всем) прочитать GoogleНачнем с самих SW, здесь: https://developers.google.com/web/fundamentals/primers/service-workers С пониманием основных принципов SW, возможно, будет полезно проверить библиотеку Workbox https://developers.google.com/web/tools/workbox, чтобы увидеть, что она может предложить для вашего приложения.

Ключевым моментом здесь является чтение и понимание различных аспектов SW - очень легко выстрелить себе в ногу с помощью SW:)