Если не указаны состояния элементов или в макете не учитываются какие-то особенности процесса, не делайте это за дизайнера.
На мой взгляд, удовлетворительное решение, созданное верстальщиком, лучше, чем отсутствующее идеальное от дизайнера. Не нужно ждать его ответа, нужно сделать самому, а дизайнеру потом просто сообщить, что мол вот, не стал ждать, сделал так… Если не понравится, он поправит, но зачастую дизайнера вполне устроит ваше решение. Ведь оно основано не на фантазии, а на опыте в подобных кейсах.
Сам по себе манифест не реализует кэширование. Он лишь для того, чтобы создать иконку? настроить экран на время загрузки + еще разные мелочи. Дальше браузер будет действовать, как обычно — покажет «динозаврика» при отсутствии сети. Сервис-вокер здесь для страницы является тем самым недостающим сервером на время офлайна. Ей не важно, кто вернет данные, сервис-вокер или настоящий сервер.
Почему для хранения информации в сервис-вокере не используется local storage:
1) Он, в отличии от IndexedDB, синхронный. Запись/чтение требует времени, а значит, время загрузки страницы значительно возрастет (хотя конкретно в этом учебном примере это не существенно, тут мы не пишем инфу во время работы с запросами, в «боевом» приложении это может потребоваться)
2) Он работает с текстом, IndexedDB с объектами — удобней.
3) Дисковое пространство для local storage значительно меньше, чем для Cache.
Вот тут есть две пошаговые лабы от Гугл, если сделать фильтрацию по Workbox в верхнем поле поиска. Одна из них как раз про переезд со «старых» инструментов. Возможно, пригодится codelabs.developers.google.com
Это отличные тулзы. На мой взгляд, Workbox является правильным выбором в 95-99% случаев, когда принимается решение о поддержке сайтом офлайна: удобные настройки, стратегии кэширования и инвалидация кэша из коробки. Писать что-то свое сегодня нужно только, если хочется странного или есть интерес к экспериментам и время на них.
Если передо мной встанет задача прикрутить офлайн, скорей всего я возьму Workbox.
С этой страницей ничего не делаем. Если пользователь вернется на нее позже, закэшируем. В противном случае она так и останется за рамками.
Теоретически ее можно попробовать поймать через self.clients при событии install и загрузить повторно, но я не пробовал, есть подозрение, что и там не будет доступна. Не думаю, что игра стоит свеч.
На Авто мы параллельно кэшируем некоторые «важные» страницы отдельным механизмом. Если есть подозрение, что страница, ставшая стартовой для сервис вокера, важна, то можно поступать так же — составить свой список «важных» и подгружать их.
Нет, автоматом не заменятся. Необходимо вызвать метод chrome.i18n.getMessage, передав ему ключ желаемого текста. Полученную строку вставить в нужное место. Я для этих целей написал небольшую тулзу, которая при инициализации ищет и актуализирует все кейсы.
Если используете шаблонизаторы, то можно реализовать эту логику там.
Под «одновременно (почти)» я имел в виду не «параллельно», а «сразу, без ожидания». Я говорил не о том, когда функции начнут и завершат свою работу буквально. Я имел в виду полное завершение их внутренних задач, в асинхронной логике это получение результата.
Простите, что смутил вас и спасибо за ваше уточнение!
В примере 2 finalHandler не знает, что возвращает функция doSomethingElse. Мало того, она даже не знает, что doSomethingElse существует, потому что результат ее работы улетает «в пустоту». В примере 2 finalHandler сразу получает на вход undefined (значение, возвращаемое любой функцией по умолчанию).
Возникает вопрос, как можно пробросить результат работы doSomethingElse в finalHandler? Ответ простой — добавить перед ее вызовом return:
doSomething().then(function () {
doSomethingElse();
})
.then(finalHandler); // undefind
doSomething().then(function () {
return doSomethingElse(); // "возвращаем" результат работы вложенной функции
})
.then(finalHandler); // тут finalHandler получит на вход результат doSomethingElse
// и, если это промис, то дождется его "выполнения", а значит и результат его выполнения
Здесь скорей имеется в виду, что начнут они свое выполнение одновременно (почти). При этом внутри функции doSomethingElse может быть какой-нибудь долгий ajax-запрос, результат которого придет только через несколько секунд (предположим, что интернет барахлит), а значит закончит свою работу она значительно позже.
Если бы перед вызовом doSomethingElse стоял return, то finalHandler честно бы ждал результат ajax-запроса.
Если бы перед doSomethingElse стоял return, то да, finalHandler ждал бы выполнения промиса из doSomethingElse. В нашем же случае мы имеем дело со «сторонним эффектом», где doSomethingElse выполняется, возможно даже возвращает промис, вот только использовать в finalHandler мы его не сможем.
Моя лицензия заканчивается только в апреле. Подскажите, если сейчас купить по акции, то с какой даты вступит в силу новая, с даты покупки или с апреля?
Интересный материал, спасибо. Наверно очень непросто было уместить в одну статью 25 лет истории, даже в виде краткой выжимки :)
На мой взгляд, удовлетворительное решение, созданное верстальщиком, лучше, чем отсутствующее идеальное от дизайнера. Не нужно ждать его ответа, нужно сделать самому, а дизайнеру потом просто сообщить, что мол вот, не стал ждать, сделал так… Если не понравится, он поправит, но зачастую дизайнера вполне устроит ваше решение. Ведь оно основано не на фантазии, а на опыте в подобных кейсах.
Почему для хранения информации в сервис-вокере не используется local storage:
1) Он, в отличии от IndexedDB, синхронный. Запись/чтение требует времени, а значит, время загрузки страницы значительно возрастет (хотя конкретно в этом учебном примере это не существенно, тут мы не пишем инфу во время работы с запросами, в «боевом» приложении это может потребоваться)
2) Он работает с текстом, IndexedDB с объектами — удобней.
3) Дисковое пространство для local storage значительно меньше, чем для Cache.
Если передо мной встанет задача прикрутить офлайн, скорей всего я возьму Workbox.
Теоретически ее можно попробовать поймать через self.clients при событии install и загрузить повторно, но я не пробовал, есть подозрение, что и там не будет доступна. Не думаю, что игра стоит свеч.
На Авто мы параллельно кэшируем некоторые «важные» страницы отдельным механизмом. Если есть подозрение, что страница, ставшая стартовой для сервис вокера, важна, то можно поступать так же — составить свой список «важных» и подгружать их.
Если используете шаблонизаторы, то можно реализовать эту логику там.
Простите, что смутил вас и спасибо за ваше уточнение!
Возникает вопрос, как можно пробросить результат работы doSomethingElse в finalHandler? Ответ простой — добавить перед ее вызовом return:
Если бы перед вызовом doSomethingElse стоял return, то finalHandler честно бы ждал результат ajax-запроса.
Спасибо за скидку!