Сначала офлайн с прогрессивными веб-приложениями [Часть 1/3]

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

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

В этой первой части мы начнем с более подробного объяснения PWA и того, как мы можем поэтапно изменять наше приложение, чтобы оно все больше и больше становилось PWA. Второе и последнее, что мы сделаем в этой части, - это объяснение и использование сервисных воркеров, которые составляют основу PWA.

Что такое прогрессивные веб-приложения?

Прогрессивные веб-приложения - это веб-сайты, которые сочетают в себе преимущества нативного приложения с низким уровнем трения в Интернете. PWA запускается как обычный веб-сайт, но чем больше пользователь его использует. Он ведет себя все больше и больше как традиционное нативное приложение.

Какие преимущества мы получаем от PWA?

• Всегда доступен онлайн и офлайн (кэширование, фоновая синхронизация,…)
• Быстрое время загрузки (кеширование)
• Всплывающие уведомления
• Ярлык на главном экране (мобильный)
• Родной вид (мобильный)

Все эти преимущества станут более понятными в этой серии блогов, когда мы коснемся их всех.

У кого есть PWA?

• Код НАСА
• Статус Chrome
• Статус Firefox
• Twitter Lite
• Instagram
• …

Для большинства перечисленных выше преимуществ мы должны использовать сервис-воркера.

Чем занимается сервисный работник?

Сервисный работник - это слой между вкладками браузера вашего веб-сайта и сервером. Мы будем использовать сервис-воркер в основном для перехвата, изменения и кеширования запросов. Приятно отметить, что работник службы по-прежнему живет внутри вашего браузера, поэтому он может работать без подключения к Интернету и по-прежнему обслуживать файлы, кэшированные работником службы. Но, возможно, одна из лучших особенностей сервис-воркера заключается в том, что вы управляете им, написав JavaScript, поэтому нет необходимости изучать новый язык.

Веб-сайт мы превратим в прогрессивное веб-приложение

Я создал проект Github, в котором будет жить весь код для этой серии блогов. Чтобы получить приложение, которое мы начнем преобразовывать, вы можете проверить тег: PT1_0-the-app.

Если вы посмотрите на код, вы увидите имя двух каталогов: сервер и клиент. Мы будем делать все кодирование внутри клиентского каталога.

Сервер

Если вы посмотрите на каталог сервера, то увидите, что там действительно простой REST API Express.js. REST API хранит данные в виде массива, поэтому при перезапуске сервера вы теряете дату добавления или обновления.

Для запуска сервера вам достаточно выполнить следующие команды:

cd server
npm install
npm start

Клиент

Клиент представляет собой простое веб-приложение с экраном приветствия (index.html) с красивым фоновым изображением.

На второй странице находится настоящее приложение (voter.html). У нас есть страница с небольшой формой для добавления видео. Ниже у нас есть список видео, за которые вы можете проголосовать за или против. Все это контролируется файлом JavaScript с вызовами ajax (js / voter / voter.js).

Для запуска сервера вам достаточно выполнить следующие команды:

npm install http-server -g
cd client
http-server

Если вы все сделали правильно, вы должны увидеть сайт по адресу: http: // localhost: 8080

Давайте начнем переходить к прогрессивному веб-приложению

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

Вы можете смоделировать офлайн-соединение в Chrome, перейдя в инструменты разработчика → Сеть → Установите флажок офлайн.

Если вы это сделали и обновили страницу в хроме, вы должны увидеть динозавра. А если хотите, можете поиграть в веселую маленькую игру.

Создание нашего сервис-воркера

Теперь у нас нет подключения к Интернету, и мы хотим показать что-то более связанное с нашим сайтом, а не с этим динозавром. Они все равно вымерли. Для этого мы можем использовать возможности сервис-воркера. Первый шаг от курса - создать его. Давай сделаем это сейчас.

Создайте новый файл JavaScript в папке js с именем app.js (js / app.js). И добавьте ‹script src =” js / app.js ”› ‹/script› под другими тегами сценария из index.html и voter.html .

В app.js добавьте следующий код:

if ("serviceWorker" in navigator) {
    navigator.serviceWorker.register("/service-worker.js")
        .then(function (registration) {
            console.log("Service Worker registered with scope:", 
                         registration.scope);
        }).catch(function (err) {
        console.log("Service worker registration failed:", err);
    });
}

Этот код делает пару вещей. Все начинается с проверки, поддерживает ли наш браузер сервис-воркеров. После этого мы регистрируем сервис-воркера и даем ему имя файла JavaScript, в котором будет размещаться код этого сервис-воркера. Функция register возвращает Promise, и мы можем использовать функцию then, чтобы сказать, что мы успешно создали нашего сервис-воркера, или мы можем использовать catch для выполнения логики, когда сервис-воркер не смог создать.

Файл JavaScript сервисных работников должен пока находиться в корне вашего веб-сайта, а не в папке js. Это связано с сферой действия сервисных воркеров. Больше информации в этом видео на YouTube:

Создайте новый файл JavaScript в корневой папке с именем service-worker.js и добавьте в этот файл следующий код:

self.addEventListener("fetch", function(event) {
  console.log("Fetch request for:", event.request.url);
});

Это будет регистрировать каждый запрос на выборку, который ваше приложение отправляет на ваш сервер. Итак, вы можете видеть, что запросы сначала проходят через сервис-воркера. Вы также можете получить код с тегом: PT1_1-service-worker

Мы продолжим обновлять нашего сервис-воркера, но эти изменения не будут отражены в браузере, потому что старый сервис-воркер все еще активен. Это связано с жизненным циклом сервис-воркера. А пока перейдите в инструменты разработчика → Приложение → Сервисные работники → Установите флажок «Обновлять при перезагрузке».

Отображение настраиваемой офлайн-страницы

Замените код нашего service-worker.js следующим:

var responseContent =
    "<html>" +
    "<body>" +
    "<style>" +
    "body {text-align: center; background-color: #333; color: #eee;}" +
    "</style>" +
    "<h1>Video Voter</h1>" +
    "<p>There seems to be a problem with your connection.</p>" +
    "</body>" +
    "</html>";

self.addEventListener("fetch", function(event) {
    event.respondWith(
        fetch(event.request).catch(function() {
            return new Response(
                responseContent,
                {headers: {"Content-Type": "text/html"}}
            );
        })
    );
});

Этот фрагмент кода выполняет следующие действия: он прослушивает события fetch, и если он обнаруживает, что выборка не выполняется, мы создаем новый ответ в JavaScript с помощью Response объект. Мы передаем ему наш responseContent, который содержит html, и сообщаем ему, что ответ имеет тип содержимого text / html.

Если вы снова переведете браузер в автономный режим, вы увидите следующее:

Код можно найти в теге: PT1_3-offline-page

Заключение часть 1

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

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

Часть 2: https://medium.com/@schoovaertswout/offline-first-with-progressive-web-apps-part-2-3-670fa15d07c5