Comments 12
а как вы решаете вопрос со страницой которая зарегистрировала впервые sw и сама еще не попала в кэш т.к. запрос к ней не проходил через sw потому что он не был зарегистрирован в браузере?
С этой страницей ничего не делаем. Если пользователь вернется на нее позже, закэшируем. В противном случае она так и останется за рамками.
Теоретически ее можно попробовать поймать через self.clients при событии install и загрузить повторно, но я не пробовал, есть подозрение, что и там не будет доступна. Не думаю, что игра стоит свеч.
На Авто мы параллельно кэшируем некоторые «важные» страницы отдельным механизмом. Если есть подозрение, что страница, ставшая стартовой для сервис вокера, важна, то можно поступать так же — составить свой список «важных» и подгружать их.
Теоретически ее можно попробовать поймать через self.clients при событии install и загрузить повторно, но я не пробовал, есть подозрение, что и там не будет доступна. Не думаю, что игра стоит свеч.
На Авто мы параллельно кэшируем некоторые «важные» страницы отдельным механизмом. Если есть подозрение, что страница, ставшая стартовой для сервис вокера, важна, то можно поступать так же — составить свой список «важных» и подгружать их.
Как и всегда — работает, но через огромное количество костылей, и я не про ваш код — он крут.
Хотелось бы какой-то более лучшей поддержки со стороны браузеров. Видимо, нужно ждать свою «jQuery» для этого.
Хотелось бы какой-то более лучшей поддержки со стороны браузеров. Видимо, нужно ждать свою «jQuery» для этого.
Это отличные тулзы. На мой взгляд, Workbox является правильным выбором в 95-99% случаев, когда принимается решение о поддержке сайтом офлайна: удобные настройки, стратегии кэширования и инвалидация кэша из коробки. Писать что-то свое сегодня нужно только, если хочется странного или есть интерес к экспериментам и время на них.
Если передо мной встанет задача прикрутить офлайн, скорей всего я возьму Workbox.
Если передо мной встанет задача прикрутить офлайн, скорей всего я возьму Workbox.
Мы используем sw-precache-webpack-plugin в нескольких проектах, работает отлично, но минус большой — почти не реально разобраться и поправить, много не читаемого фарш-кода. Насколько я понял разработчиков: Workbox это переосмысление опыта sw-toolbox, больше модульности, вроде как фреймворк для сервисворкеров оффлайн. Однако заставить работать Workbox не удалость — тогда он был в бэте.
Вот тут есть две пошаговые лабы от Гугл, если сделать фильтрацию по Workbox в верхнем поле поиска. Одна из них как раз про переезд со «старых» инструментов. Возможно, пригодится codelabs.developers.google.com
О! Спасибо за ссылку. Статья очень свежая — Updated Apr 9, 2018 :-)
А какое преимущество у этого подхода перед manifest-файлом и хранением серверных данных, например, в local storage?
Нашёл ответ на SO: stackoverflow.com/questions/36038371/comparison-between-service-worker-and-appcache (AppCache/Manifest теперь deprecated).
Сам по себе манифест не реализует кэширование. Он лишь для того, чтобы создать иконку? настроить экран на время загрузки + еще разные мелочи. Дальше браузер будет действовать, как обычно — покажет «динозаврика» при отсутствии сети. Сервис-вокер здесь для страницы является тем самым недостающим сервером на время офлайна. Ей не важно, кто вернет данные, сервис-вокер или настоящий сервер.
Почему для хранения информации в сервис-вокере не используется local storage:
1) Он, в отличии от IndexedDB, синхронный. Запись/чтение требует времени, а значит, время загрузки страницы значительно возрастет (хотя конкретно в этом учебном примере это не существенно, тут мы не пишем инфу во время работы с запросами, в «боевом» приложении это может потребоваться)
2) Он работает с текстом, IndexedDB с объектами — удобней.
3) Дисковое пространство для local storage значительно меньше, чем для Cache.
Почему для хранения информации в сервис-вокере не используется local storage:
1) Он, в отличии от IndexedDB, синхронный. Запись/чтение требует времени, а значит, время загрузки страницы значительно возрастет (хотя конкретно в этом учебном примере это не существенно, тут мы не пишем инфу во время работы с запросами, в «боевом» приложении это может потребоваться)
2) Он работает с текстом, IndexedDB с объектами — удобней.
3) Дисковое пространство для local storage значительно меньше, чем для Cache.
Если вы будете отдавать файл сервис-воркера из директории/js/, например/js/service-worker.js, то он сможет обрабатывать только те сетевые запросы, которые начинаются с/js/…
Если под обработкой сетевых запросов имелось ввиду проброс запросов в событие fetch, то это не так. Когда пользователь будет находиться в локейшн, начинающийся с
/js/, то браузер активирует сервис воркер, зареганый для scope /js/, и начнет пробрасывать в его событие fetch все запросы без ограничений.Проверить можно здесь: https://sw-fetch-is-not-limited-by-scope.github.io/. Перейти на странице по ссылке на
/banana и открыть консоль.Sign up to leave a comment.
Генерация страниц сайта средствами сервис-воркеров