Задание 3

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

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

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

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

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

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

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

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

Решение

• Изучив код и разобравшись с SW, я столкнулась, с тем, что console.log'и при эвенте message не выводятся. Это из-за расположения файла SW. В SW попадают только те запросы, которые соответствуют его scope. Эта ошибка могла возникнуть из-за рефакторинга «Разложить файлы красиво», когда перенесли файл SW из корня проекта в папку assets. Для текущей реализации проекта необходимо расположить файл SW на одном уровне с gifs.html или выше (самый высокий уровень - корень сайта).

• Далее, появилась проблема в оффлайн режиме. Html файл не отдавался. Изучила цепочку функций кеширования и отдачи файлов. Оказалось, что функция needStoreForOffline никогда не считает нужным кешировать gifs.html. Ошибка возникла из-за фикса первого бага (у клиентов html страница всегда бралась из кеша), удалив строчку "cacheKey.endsWith('gifs.html') ||" из функции needStoreForOffline. Решить проблему можно, восстановив эту строчку.

• И тут мы возвращаемся к первому багу. Ресурсы всегда берутся из кеша. Раз проблема опять связана с отдачей кешированых файлов, изучила ее логику. Оказалось, что на этапе fetch ресурсы, которые должны быть закешированы, всегда брались из кеша. А если их не было, они скачивались. Это произошло после рефакторинга «Более надёжное кеширование на этапе fetch». Решается изменением условия.

• Заметила, что при удалении из избранного в программе заложен эвент message, но на это сообщение не настроен handle. Из-за этого кеш засоряется запросами. Написала handle, теперь кеш очищается, но это приводит к неприятной ситуации в оффлайн режиме (при удалении из избранного, картинка тут же пропадает из кеша, но на странице она все еще видна. Если мы ее снова добавим, то после обновления страницы картинка не появится). Этот метод можно доработать несколькими способами:

  • чтобы он не удалял в оффлайн режиме;
  • при загрузке страницы сверять гифки из IndexedDB с текущей версией кеша и удалять ненужное;
  • удаление при закрытии попапа.

=====

2. Делает SW активным для страниц, которые находятся в одной области.
3. Не подойдет для тех случаев, когда на получаемый контент влияют get-параметры. (Для корректной работы необходимо использовать url.href)
4. Для того, чтобы удалять кеш старой версии.
5. Клонируем ответ и помещаем клон в кеш, а оргинал передается браузеру.