Превратите свое веб-приложение Vue в PWA!

Как преобразовать ваше веб-приложение Vue в прогрессивное веб-приложение. Учебник с примерами.

В этом посте мы увидим, как взять существующее приложение Vue, которое я создал в предыдущем посте, и преобразовать его в PWA!

Прогрессивные веб-приложения (PWA) - это веб-приложения, которые могут без проблем работать на мобильных устройствах. Но это еще не все! PWA не ограничиваются никакими ограничениями и правилами, установленными в Play Store или App Store.

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

Еще одна замечательная особенность PWA - это то, что они могут загружаться в неопределенных сетевых условиях, даже в автономном режиме, и это здорово. Давайте начнем.

Совет: используйте инструменты с открытым исходным кодом, такие как Bit, чтобы легко изолировать, совместно использовать и повторно использовать компоненты в ваших проектах и приложениях. Это экономит время и упрощает вашей команде совместную работу, совместное использование компонентов и ускорение создания. Попробуйте.

Обнаружение компонентов и совместная работа · Bit
Bit - это место, где разработчики обмениваются компонентами и совместно создают потрясающее программное обеспечение. Откройте для себя общие компоненты… bit.dev

Базовое приложение

Базовое приложение, над которым мы будем работать, - это простое приложение Vue, которое использует Firebase для аутентификации и базы данных. Ранее я писал сообщение о том, как создать это приложение. Вы можете прочитать это здесь:

Создание приложения Vue с аутентификацией Firebase и базой данных
Краткое, но подробное руководство по созданию простого приложения Vue с Firebase для аутентификации и Firestore для базы данных. блог. bitsrc.io

Но вы также можете получить исходный код приложения здесь:

rajatk16 / dc-cabin
Участвуйте в разработке rajatk16 / dc-cabin, создав учетную запись на GitHub. github.com

Используйте команду git clone, чтобы загрузить код в вашу систему:

$ git clone https://github.com/rajatk16/dc-covers

Или, если вы по какой-то причине никогда не использовали GitHub, просто нажмите кнопку «Загрузить как zip».

Затем откройте командный терминал и команду install с помощью NPM или Yarn.

npm install // or yarn install

После завершения установки пакетов вы заметите, что в папке приложения создается новая папка с именем .node_modules. Чтобы проверить, работает ли приложение, запустите npm run dev или yarn dev, чтобы запустить приложение в браузере:

С этим мы можем начать превращать это базовое веб-приложение в прогрессивное!

Манифест

Чтобы создать прогрессивное веб-приложение, браузер должен сначала знать, что это PWA. Это снижено созданием Web App Manifest. Манифест веб-приложения - это файл JSON, который определяет некоторую информацию о приложении. Он очень похож на то, как выглядит файл манифеста Android, и содержит такую информацию, как имя, автор и т. Д.

Внутри корневого каталога проекта создайте новый файл с именем manifest.json.

Еще раз, этот файл используется для описания приложения с помощью некоторых метаданных, как показано ниже:

{
  "name": "DC-Covers",
  "short_name": "Covers",
  "start_url": "index.html",
  "display": "standalone",
  "theme_color": "#0476F2",
  "background_color": "#fff",
  "icons": [
    {
      "src": "", // usually kept in the static/icons folder
      "sizes": "", // enter the size of the image 
      "type": "" // enter the type of the image eg: image/png,
    },
  ]
}

Здесь мы написали name как обложки DC и short_name как обложки. Если название вашего приложения уже короткое, вы можете пропустить добавление этого свойства. Вы не можете дать более короткое имя приложению с названием вроде Whatsapp! 😆

Затем у нас есть свойство с именем start_url, это относится к основному html-файлу нашего приложения, которым в данном случае является файл index.html. Затем мы воспользуемся свойством display, чтобы сообщить нашему браузеру, как открыть приложение. Значение standalone откроет приложение как обычное. Вы можете установить для этого свойства что-нибудь вроде полноэкранный или минимальный-ui.

theme_color будет использоваться для установки цвета любой панели инструментов на наших мобильных устройствах, а background_color будет использоваться для заставки PWA.

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

Осталось сделать последнее! Перейдите к файлу index.html и добавьте тег link, указывающий на этот файл manifest.json.

<html>
  <head>
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bulma/0.6.2/css/bulma.css" />
    <link rel="manifest" href="/manifest.json"/>
    <title>DC Comics Rebirth - Covers</title>
  </head>
  <body>
    <div id="app"></div>
    <script src="/build/build.js"></script>
  </body>
</html>

Но как мы узнаем, сработало ли это?

Если мы откроем DevTools в нашем браузере, вы увидите вкладку под названием Приложение. Там должно получиться что-то вроде этого

Мета-теги

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

Внутри файла index.html напишите следующие теги meta в разделе head.

<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="default">
<meta name="apple-mobile-web-app-title" content="DC-Covers">
<meta name="msapplication-TileImage" content="link to the image in static folder">
<meta name="msapplication-TileColor" content="#000">

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

Затем мы определяем теги meta для браузеров Microsoft Edge, сначала while направляет на более мелкие значки, хранящиеся в папке static/icons. Тег TileColor определяет tile цвет, который Windows использует для размещения icon на главном экране.

Нам также нужно добавить link к значку, который мы хотим отображать на главном экране главного экрана iOS, как показано ниже:

<link rel="apple-touch-icon" href="link to the smaller icon">

При этом наше приложение узнают все современные браузеры.

Кэширование с помощью сервис-воркеров

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

Создание сервис-воркеров - непростая задача. А поскольку для каждой функции требуется отдельный сервис-воркер, задача также может стать повторяющейся. Вместо этого мы будем использовать sw-precache для автоматизации процесса создания сервис-воркеров.

Начнем с глобальной установки sw-precache с помощью NPM:

$ npm install sw-precache -g

После установки создайте файл конфигурации с именем sw-config.js и напишите в нем следующий код:

module.exports = {
  staticFileGlobs: [
    'index.html',
    'manifest.json',
    'dist/**.js'
  ]
}

Этот файл в основном сообщает, что нам нужно кэшировать index.html, manifest.json и все файлы JavaScript, хранящиеся в папке dist.

Затем запустите команду sw-precache с флагом --config, связанным с файлом sw-config.js, как показано ниже:

$ sw-precache --config sw-config.js

Это создаст новый файл с именем service-worker.js, содержащий массу кода, определяющего сервис-воркера, который кэширует все файлы, упомянутые выше.

Автоматизация генерации серверных рабочих

В предыдущем разделе мы вручную сгенерировали серверного воркера. Но что нам действительно нужно сделать, так это автоматизировать это внутри процесса сборки. Это можно сделать, используя sw-precache-webpack-plugin как зависимость разработчика.

Сначала установите этот пакет как devDependency:

$ npm install -D sw-precache-webpack-plugin

Затем откройте webpack.config.js и импортируйте указанную выше devDependency, как показано ниже:

const SWPrecache = require('sw-precache-webpack-plugin')

Внизу вы увидите оператор if, который определяет все плагины, используемые в приложении. Напишите внутри него новый экземпляр SWPrecache, как показано ниже:

new SWPrecache({
  cacheId: 'dc-covers',
  filepath: 'service-worker.js',
  staticFileGlobs: [
    'index.html',
    'manifest.json',
    'dist/*.{js,css}
  ],
  stripPrefix: '/'
})

Запустите команду npm run build, и вы увидите, что создается новый файл с именем service-worker.js.

Следующим шагом является регистрация этого сервис-воркера в браузере.

Регистрация сервис-воркера

Как упоминалось ранее, после создания сервис-воркера нам нужно зарегистрировать его в браузере. Самый простой способ сделать это - написать регистрационный код внутри файла src/main.js.

Внутри файла main.js мы будем использовать navigator API. В навигаторе есть свойство serviceWorker с методом register, который принимает URL-адрес файла service-worker.js.

Нам также необходимо убедиться, что браузер поддерживает сервис-воркеров. Если браузер не поддерживает сервис воркеров, запускать регистрационный код нет смысла.

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

const prod = process.env.NODE_ENV === 'production'
const shouldSW = 'serviceWorker' in navigator && prod
if (shouldSW) {
  navigator.serviceWorker.register('/service-worker.js').then(() => {
    console.log("Service Worker Registered!")
  })
}

Перестройте приложение с помощью npm run build, а затем запустите его с помощью http-server или расширения Live Server для VS Code. В разделе «Приложение» инструментов разработчика браузера вы заметите, что разделы «Сервис-воркеры» уже не так пусты.

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

Браузер обновляет сервис-воркер, выполняя побайтовое сравнение измененной версии и старой версии. Если они отличаются, измененная версия заменит старую версию.

Но если мы внесем какие-либо изменения, перестроим приложение и запустим приложение в браузере, вы заметите, что ничего не изменилось. Это связано с тем, что сервис-воркер имеет полный контроль над кешем в течение некоторого времени (обычно в течение 1 часа).

Автоматическая отмена регистрации сервис-воркера

Так же, как мы автоматизировали процесс регистрации обслуживающего работника, мы можем сделать то же самое и с процессом отмены регистрации. Это полезно, когда вы все еще разрабатываете приложение и не хотите, чтобы работник службы кэшировал что-либо.

Сначала нам нужно создать нового сервис-воркера для режима разработки. Я назову этот файл service-worker-dev.js. Весь смысл этого сервис-воркера состоит в том, чтобы перезаписать исходный сервис-воркер производственного режима.

Добавьте eventListener в событие install, которое будет вызывать функцию, вызывающую skipWaiting. Это принудительно активирует сервис-воркер.

self.addEventListener('install', () => {
  self.skipWaiting()
})

Я также добавлю еще EventListener для события activate. Это поможет нам получить доступ ко всем другим вкладкам и окнам браузера, которые будут использовать этого сервис-воркера.

self.addEventListener('activate', () => {
  self.clients.matchAll({
    type: 'window'
  }).then(clients => {
    for (let client of clients) {
      client.navigate(client.url)
    }
  })
})

Как и в предыдущем разделе, нам нужно использовать этого сервис-воркера, добавив его в файл main.js.

const shouldSWDev = 'serviceWorker' in navigator && !prod

Затем мы добавляем else if к оператору if из предыдущих разделов, который проверяет, не является ли режим производственным.

else if (shouldSWDev) {
  navigator.serviceWorker.register('/service-workder-dev.js').then(() => {
    console.log('Service Worker Registered!')
  })
}

Теперь запустите приложение, используя npm run dev. Тогда вы заметите в разделе приложения DevTool, что файл сервис-воркера изменился!

Заключение

В этом посте мы впервые вкратце увидели, что такое прогрессивные веб-приложения. Затем мы создали «манифест», чтобы помочь браузерам распознавать наши веб-страницы как веб-приложения. Мы также добавили несколько тегов meta, чтобы другие браузеры могли распознавать веб-страницу как приложение. Таким образом, приложение потенциально можно будет установить.

Затем мы вручную создаем нашего первого сервис-воркера. Затем мы увидели, как автоматизировать процесс внутри сервера webpack. Наконец, мы зарегистрировали сервис-воркера, увидели, почему изменения не обновляются в браузере, а затем создали нового сервис-воркера, который отменяет регистрацию нашего исходного сервис-воркера в режиме разработки.

Есть еще много вещей, которые мы можем сделать, чтобы сделать наше приложение прогрессивным. DevTools Chrome может «проверять» наше приложение и сообщать нам, насколько оно прогрессивно и что еще мы можем сделать для его улучшения.