Skip to content

Latest commit

 

History

History
73 lines (53 loc) · 7.04 KB

README.md

File metadata and controls

73 lines (53 loc) · 7.04 KB
Raw

Задание 3

Мобилизация.Гифки – сервис для поиска гифок в перерывах между занятиями.

Сервис написан с использованием bem-components.

Работа избранного в оффлайне реализована с помощью технологии Service Worker.

Для поиска изображений используется API сервиса Giphy.

В браузерах, не поддерживающих сервис-воркеры, приложение так же должно корректно работать, за исключением возможности работы в оффлайне.

Структура проекта

  • gifs.html – точка входа
  • assets – статические файлы проекта
  • vendor – статические файлы внешних библиотек
  • service-worker.js – скрипт сервис-воркера

Открывать gifs.html нужно с помощью локального веб-сервера – не как файл. Это можно сделать с помощью встроенного в WebStorm/Idea веб-сервера, с помощью простого сервера из состава PHP или Python. Можно воспользоваться и любым другим способом.

Поиск бага и ход мыслей:

При переносе приложения на сервер, в консоли светилась ошибка: blocks.js:474 [ServiceWorkerContainer] DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV). Сначала подумал, что дело в неправильном относительном пути, т.е. root_dir/assets/assets, но при чтении доки выяснилось - работает либо по HTTPS, либо на локальной машине, да и ошибка говорила об этом же. Однако это натолкнуло на мысль по поводу .register('./assets/service-worker.js'). Посмотрел документацию и выяснил, что у register() есть второй параметр options, который имеет на данный момент одну опцию:

  • scope: USVString представляет собой URL который определяет доступную область видимости сервис-воркера; определяет какой диапазон URL может контролировать сервис-воркер. Это обычно относительный URL. Значение по умолчанию это URL, котрые соответствует корню т.е. './' используя директорию расположения js скрипта сервис-воркера как основу.

Затем вспомнил о 3-м шаге «Разложить файлы красиво» ну и далее по тексту :)

Использовать http-заголовок Service-Worker-Allowed не вариант, т.к. мы работаем локально, но если бы был HTTPS, то для файла service-worker.js серверу нужно отдавать доп.заголовок, а в вызов исправить на .register('/assets/service-worker.js', {scope: '/'})

Решение: переместим service-worker.js в корень сайта и изменим путь вызова в blocks.js.

После этого, вроде бы кэш избранного в оффлайне заработал, по крайней мере в режиме "Инкогнито" всё ОК.

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

Будем искать баги дальше...

Идём далее и проверяем откуда берётся gifs.html - как и описано в задании, она берётся из кэша. Соответственно, выстраивается следующая цепочка:

  • gifs.html и service-worker.js лежали в корне
  • fetch работал нормально и кэшировал всё, включая gifs.html на этапе загрузки
  • фикс бага подразумевает исключение gifs.html из кэширования в функции needStoreForOffline()
  • после 3-го шага точкой входа стала папка assets, а не корень.

Примечание: вообще, стартовое приложение работает корректно в оффлайне только при выключенном интернете, а не при выключенном локальном сервере. Если в консоле включить режим offline, то gifs.html не загружается из кэша браузера, а остальные файлы берутся не из ServiceWorker, а либо из кэша память, либо из дискового кэша. В область сервис-воркера попадают только он сам и kv-keeper.js, подключенный через importScripts(). Уж не знаю баг это или фишка, но писать "всё наладилось" не стоило. А может и я где недопонял...

Но вернёмся к нашим баранам - исправление кэширования gifs.html :)

После выкладывания на HTTPS хостинг, внёс некотые исправления, которые упустил при переносе в корень, а именно путь вызова importScripts(), что исправил коммитом 90c198a.

Т.к. сроки вышли, а до конца всё исправить я не успел, опишу, как я вижу исправления:

  • на этапе install кэшируем jQuery и прочее, чтобы всё работало, после первого запроса.
  • в fetch делается проверка наличия сети и если всё ок - отдаётся gifs.html (видимо через Blob и createObjectURL()), иначе gifs.html берётся из кэша, который был создан ещё на этапе install.
  • в конце, на сервере настраиваются заголовки Last-Modified или ETag, а "более эффективное кэширование" переписывается под проверку заголовков.