PWA

Service worker

Усе, що PWA вміє, а звичайний сайт — ні, походить з одного механізму. Service worker — це скрипт, який браузер виконує поза сторінкою, і щойно його зареєстровано, кожен мережевий запит сторінки спершу проходить крізь нього. Для кожного воркер вирішує: відповісти з кешу, піти в мережу чи зробити і те, і те й обрати. Сторінка про це не здогадується й обійти це не може.

Яку стратегію взяти — рішення на кожен запит, а не глобальне налаштування, і полягає воно в тому, наскільки застарілою може бути відповідь. Оболонку застосунку — HTML, CSS і JavaScript — віддавайте спершу з кешу, бо вони версіоновані, і копія в кеші коректна аж до вашого розгортання. Дані API віддавайте спершу з мережі з відкотом до кешу: користувач зі зв’язком побачить актуальне, а користувач у тунелі — те останнє, що мав. Беріть stale-while-revalidate там, де миттєво важить більше за свіжо: показати кеш одразу, сходити в мережу у фоні, оновити на наступний раз.

Пишіть воркер бібліотекою, а не руками. Workbox генерує маніфест передкешування з виходу вашої збірки, тож список файлів і хеші їхніх версій лишаються коректними, поки бандл змінюється, і реалізує стратегії вище кількома рядками кожну. Написаний руками воркер — правдоподібний проєкт на вихідні й нерозважлива річ у проді, бо збій тут — це віддача застарілого вмісту справжнім користувачам без можливості втрутитися.

Що робить його встановлюваним

Друга половина PWA — це вебманіфест: маленький JSON-файл, що називає застосунок, його іконки, колір теми, стартову URL і режим показу. Поставте display у standalone — і встановлений застосунок відкриється без обрамлення браузера: без адресного рядка й вкладок, — а це й є більша частина того, що робить його схожим на застосунок, а не на закладку. Віддавайте це через HTTPS, який для service worker потрібен так чи інакше.

Варто бути точним щодо того, що саме дає встановлення, бо це більше за ярлик і менше за картку в магазині. Застосунок отримує власну іконку й власне вікно, з’являється в перемикачі задач як окрема сутність і тримає власне сховище. Він не отримує картки, яку хтось знайде, гортаючи магазин, не отримує платіжної системи магазину, а на більшості платформ користувачеві треба сказати, що така опція існує: браузер не завжди запропонує її помітно.

Межі, названі чесно

Можливості PWA — не одна річ, а список API, кожен з яких підтримують одні браузери й не підтримують інші, і розрив розподілений нерівномірно. Браузери на Chromium під Android реалізують майже все. Safari на iOS реалізує ядро й лишає поза дужками кілька речей, які команди схильні вважати даністю, — а оскільки PWA на iOS працює в рушії Safari незалежно від того, який браузер його встановив, обійти це неможливо.

Рішення, до якого це веде, простіше, ніж підказує порівняння. Якщо продукт — це контент, комерція, бронювання, дашборди чи внутрішні інструменти, тобто по суті сайт, якому було б корисно працювати офлайн і жити на домашньому екрані, — PWA дешевша відповідь і доходить до всіх через посилання. Якщо продукт залежить від доступу до заліза, від поведінки у фоні, поки він закритий, від знаходжуваності в магазині чи від присутності на ринку, де застосунки шукають, гортаючи магазин, — це має бути застосунок. Усе між цими полюсами — судження про те, скільки коштує вам відсутня можливість.

Як це виявляється в реальній поставці

Перевага, що переживає будь-яке порівняння, — це дистрибуція. Немає черги рев’ю, акаунта в магазині, сертифіката, який треба поновлювати, і збірки, яку треба підписувати: виправлення — це розгортання, а посилання — це весь процес встановлення. Для продуктів, що живуть із того, що їх знаходять пошуком або передають посиланням, це не дрібна операційна зручність: це різниця між користувачем, який спробує продукт зараз, і користувачем, якого спершу просять щось встановити.

Дві речі треба проєктувати, а не припускати. Сховище не є постійним: браузер може витіснити дані сайту під тиском або після довгого простою, тож усе, що користувачеві було б прикро втратити, має дійти до сервера, а navigator.storage.persist() — це прохання, а не гарантія. І офлайн — це стан, який має бути в інтерфейсі, а не технічна деталь: показуйте, що є в кеші, позначайте застаріле, ставте в чергу те, що записали без зв’язку, і кажіть користувачеві, на що саме він дивиться. Застосунок, який мовчки показує тижневі дані як актуальні, гірший за той, що зізнається, що він офлайн.

Де це вироджується

• Оновлення не обробляється — випущене виправлення чекає за старим воркером, доки відкрита вкладка.
• Написаний руками service worker, чий список кешу розходиться з виходом збірки.
• Закешований сам файл service worker може лишити користувачів на версії, яку ви не заміните.
• Стратегія «спершу кеш» для даних API — застосунок упевнено показує інформацію кількаденної давнини.
• Офлайн як стан помилки, а не спроєктований стан, — і в результаті порожній екран.
• Дані, що живуть лише у сховищі браузера, яке той має право очистити.
• Фіча, спланована на API, якого iOS не реалізує, виявлена вже після затвердження дизайну.

Коли це застосовувати

Пов’язані сторінки

• РозробкаJavaScriptJavaScript — це мова, яку виконує кожен браузер, і та, яку більшість вчить із синтаксису й ніколи — із семантики. Майже все, що здається в ній довільним, випливає з одного факту: ваш код виконується в одному потоці з одним стеком викликів, а все асинхронне — це черга, що чекає, доки стек спорожніє. На цій сторінці — цикл подій, посилання, замикання, модулі й те, де обробка помилок в асинхронному коді тихо провалюється.
• РозробкаReact NativeReact Native — це React, який рендерить справжні в’ю платформи замість вузлів DOM. Це не вебв’ю і не компілятор у Swift чи Kotlin: ваш JavaScript виконується у власному рушії й каже платформі, що показати на екрані. Саме ця архітектура дозволяє вебкоманді випустити справжній мобільний застосунок — і саме вона породжує всі питання продуктивності до фреймворку. На цій сторінці — модель потоків, Expo, нативні модулі й те, де ілюзія ламається.
• РозробкаHTML та CSSHTML і CSS — це дві мови, з яких складається будь-який вебінтерфейс, і шар, який найчастіше вважають простим. HTML — це не розмітка заради вигляду: кожен елемент є обіцянкою, за якою діють браузер і допоміжні технології. CSS — не список стилів, а алгоритм розв’язання конфліктів із визначеним порядком, і знання цього порядку перетворює вгадування на міркування.