Как стать автором
Обновить

Комментарии 11

Отдельное спасибо за то, что сделали все в "блокноте".


Обычно такие статьи начинаются с "для начала нам надо сделать одну простую вещь… — npm install 1, 2, ..., 189, 190,… 100500" и сидишь такой и думаешь что это не статья была "как сделать" а подборка типа "используйте эти топ 10 npm пакетов если хотите..."

На мой взгляд PWA — это "нишевое" решение, для мобильных устройств.

Не совсем корректно называть PWA — "решением для мобильных устройств".
Оно отлично может работать и как десктопное приложение.

Может. Но зачем? Буква W в аббревиатуре PWA означает web-технологии (браузер и вот это вот всё), а не необходимость наличия самого web'а для работы приложения. Классические клиент-серверные приложения не будут работать без web'а, а PWA — вполне. Можно записать файлы примера на флешку и распространять на ней. При условии, что у вас на рабочих станциях крутится web-сервер с HTTPS для начальной загрузки приложения — я не уверен, что PWA будет работать с файловой системы напрямую, без web-сервера. По крайне мере, пример из статьи не работает, выдавая ошибку:


Uncaught (in promise) TypeError: Failed to register a ServiceWorker: The URL protocol of the current origin ('null') is not supported. at index.html:26

Просто для десктопов есть более удобные технологии создания приложений, которые не требуют наличия подключения к сети. Если же наше десктопное приложение имеет стабильное подключение к интернету, то какой смысл нагружать его функционал возможностью работать в режиме offline? Это усложняет приложение. Не просто усложняет, а значительно усложняет. В разы, если не на порядок.


PWA-фронты для Magento, например, не позволяют совершать покупки без интернета даже на мобильниках. Но это и понятно — представьте себе мобильное приложение, которое закачивает весь каталог магазина на смартфон (с описанием товаров, характеристиками, картинками), чтобы пользователь мог совершать покупки offline и синхронизироваться, как только появится такая возможность.


В виде PWA можно сделать знаменитого "сапёра" из мира Windows. Установил приложение и играй себе потихоньку, ставь рекорды. Появился интернет — слил свои рекорды на сервер, поднял с него рекорды других игроков и сохранил в локальной памяти. Но я думаю, что "сапёра" проще написать на той же Java в виде нативного приложения. Хотя тут всё зависит от разработчиков — кому-то проще на Java, кому-то — на JavaScript.


В общем, PWA — это возможность писать а-ля нативные приложения на HTML/CSS/JS для мобильных устройств тем, кто не может делать это нативно. Допустим, ваша команда разработала web-приложение для десктопов и хочет специализировать его для мобильных — вот здесь PWA и пригодится. Особенно, если ваше приложение позволяет сохранять свою полезность в моменты отсутствия соединения с интернетом. И да, эту фишку можно перетянуть на десктопы, усложнив разработку в разы или на порядок.

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

Никакого усложнения техники PWA не вносят, не нужно пугать людей. Для типичного SPA, внедрение возможностей PWA не вызывает никаких затруднений. Можно разместиться во всех магазинах приложений, с единой кодовой базой, единой точкой входа, одновременным релизом на всех платформах без вмешательств со стороны платфомодержателей.

Для windows это вообще практически полная замена electron, с интеграцией со стороны операционной системы. PWA это выбор для пользователя — использовать как веб-приложение, или «установить» как «нативное» приложение. Как минимум две крупнейшие ОС этот выбор поддерживают — android и windows.

"offline first" придумал не я, а разрабы Chrome'а. И да, достаточно будет заглушки, чтобы обойти это ограничение. Если вы под этим подразумеваете "условность обязательности offline", то я с вами согласен. Вот только без этой самой заглушки вы не сможете установить своё web-приложение, как "нативное". А через десктопный firefox вы не сможете установить своё приложение, как PWA, и с заглушкой тоже. Вообще не сможете.


Про сложность PWA я ничего не писал, это ваша придумка. Я писал, что усложнение вызывает необходимость совмещения online & offline режимов работы в одном приложении. И это так.


А всё остальное — верно. PWA очень даже себе неплохая замена electron.

Firefox рассматривать не вижу смысла, браузер планомерно погибает. Даже в мобильном Safari есть возможность «установки» PWA. Обязательность хотя бы заглушки это хорошее требование. Иначе, в случае недоступности сервера по любой причине, приложение будет показывать белый экран. Кстати заглушка будет работать и без установки — во вкладке браузера тоже. Если ваш веб-сервер ляжет совсем, постоянные пользователи смогут увидеть какой-то «offline» контент.

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

Да, так и есть.


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

У меня сложилось другое впечатление. Что основную работу придётся делать в основном коде. Возможности service worker'а урезаны. По-моему, он даже не способен самостоятельно определить, находится ли браузер в режиме online или offline.


По крайней мере, я добавил в service worker из поста (sw.js) такой код:


self.addEventListener('offline', function (e) {
    console.log('offline');
    debugger;
});
self.addEventListener('online', function (e) {
    console.log('online');
    debugger;
});

и никакой реакции при переводе Chrome в режим online/offline (DevTools / Application / Service Workers).


Этот же код в index.html реагирует на изменение режима:


    <script>
        if ("serviceWorker" in navigator) {
            ...
        }

        self.addEventListener('offline', function (e) {
            console.log('offline2');
            debugger;
        });
        self.addEventListener('online', function (e) {
            console.log('online2');
            debugger;
        });
    </script>

Плюс, логика взаимодействия приложения с пользователем скорее будет разная в разных режимах. Какие-то функции придётся disable'ить и это отразиться на UI.

Можно попробовать через navigator.onLine. Воркеру в принципе и нет смысла знать, доступен сейчас интернет или нет. Он работает на уровне запросов, и если запрос упал, то в зависимости от причины и нужно принимать решение — отдать что-то из базы, ответить заглушкой, вернуть ошибку и т.п.

С UI действительно придется поработать, но обычно это не переписывание всего. Можно сделать отдельный режим, чтобы существенно не переделывать обычный. Опять же тут все зависит от аппа, единого рецепта нет. Можно сделать промежуточный режим — если интернет упал во время работы, дать пользователю возможность сохранить например какие-то данные. Кейсов масса и все индивидуально.
реагирует на изменение режима:


.addEventListener('offline', () => {}) — этот код реагирует только на изменение галочки в дев-тулзах. Он не реагирует если выдернуть шнур из роутера, или на другие реальные кейсы.

if you really want to determine the online status of the browser, you should develop additional means for checking

Т.е. фактически нужно написать свой «пингатор» интернета.

При отключении wifi и mobile internet через конфигуратор в смартфоне событие генерируется. При потере связи в связи с потерей сигнала, возможно, и нет. Не проверял.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации