Service Worker для блога.

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

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

Заметки.

Типы нужно подключать явно так:

/// <reference lib="webworker" />

При этом addEventListener(“fetch”, (event) => …) все равно не выводит event, проставляем явно ExtendableEvent.

caches.match(request) не делаем! Используем только определенную версию caches.open(CACHE).then((cache) => cache.match(request)) что бы можно было ее поменять в случае какой-то ошибки или большой миграции.

Положить в кеш данные браузерного экстеншена нельзя, поэтому их нужно явно скипать !request.url.startsWith('http'), что бы не сыпались ошибки.

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

Тк получение нового контента sw может произойти И до старта скрипта апдейта на странице И позже, нужна простая версия хендшейка - отправляем апдейт сразу и на 'client-ready’, все это в промисе на waitUntil, при этом не забываем фолбек таймаут на клинап что бы промис не завис, на случай быстрого закрытия страницы (до окончания загрузки) и тп.

На клиенте получить новый контент и сравнить с текущим можно как-то так:

new DOMParser()
.parseFromString(data.text, 'text/html')
.querySelector('main')
.innerHTML
===
document.querySelector('main').innerHTML

Скрипт подключения воркера и апдейта контента нужно вынести отдельно и не кешировать.

Дейли ремайндер: https://getmentor.dev/mentor/artem-arutyunyan-162

Помогу:
- разработать архитектуру фронт приложения под требования
- оптимизировать рантайм производительность существующего кода
- спланировать рефакторинг или миграцию на новые технологии
- написать хорошо компонент \ модуль со сложной логикой
- провести ревью ПРа \ архитектуры и репозитория react приложения

В чате спрашивают про бесплатную замену хероку. Кмк из бесплатного vercel - топ.

Он же на каждый ПР создает новую среду - максимально удобно. Помогло безопасно тестировать внедрение сервис воркеров 🙂

Еще из удобного, можно подключить скрипт в 1кб и получать аналитику (реальный пример на скрине).


UPD
- fly.io
- render.com (есть бесплатный план с БД)
- netlify.com
- pages.cloudflare.com
- glitch.com
- railway.app триал дает 500 часов работы, есть базы данных

IoC & DI

Не знаю где взять хорошую статью на эту тему (поделитесь в комментариях), напишу от себя.

Инверсия зависимостей (IoC) предполагает какое-то промежуточное ключ-значение (KV) хранилище через которое происходят ~все связи между модулями и библиотеками приложения. DI - конкретная реализация этого паттерна. Нужно это что бы контролировать эти связи, например:

- подменять реализацию в дев / прод сред или возвращать какой-то мок в тестах.
- разруливать DAG, циклические, асинхронные зависимости так что бы “оно просто работало”.
- упорядочивать (разделять) объявление и использование зависимостей для лучшего кодстайла и AOT анализа и оптимизаций.

> Иногда, сову натягивают на глобус и прикручивают к DI логер или начинают заниматься декорированием зависимостей, это точно плохая практика равносильная мидлварам, т.к. по коду зависимости или ее использования совсем не понятно откуда там взялась или поменялась какая-то логика.

Раньше у нас был cjs стандарт описания зависимостей - рекваеры можно было писать где угодно и с этим была куча проблем с точки зрения архитектурны, сборки, производительности. Радость была только в том что стандарт этот был мнимый и самопальный, поэтому мы могли спокойно его модифицировать - манкипатчить require и реализовывать какие-то фичи из первого пункта (привет, jest.mock). Стандарт импортов привнес более строгое и предсказуемое апи: топ левел == статические импорты и где-угодно асинхронные импорты. Для меня крайне интересно и не понятно почему у нас есть система импортов, но в ней не интегрированы фичи IoC - какие-то юзерспейс хуки. Хотя звоночки все равно доходят - import-maps.

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

- Мокать зависимости для тестов Jest уже умеет и для ESM, но он привносит доп сложность с точки зрения сетапа, да и работает не очень быстро. Если вы хотите запускать тесты быстро и с меньшими напрягами по сборке - используйте свой DI и какой-нибудь uvu.
- Если вы не хотите городить проверки на isLoading, а просто и прозрачно использовать лениво-подгружаемые зависимости, как данные с бекенда с React Suspense - берите DI-либу которая умеет в асинхроные резолвы.
- Если вы хотите лучше структурировать ваш код для лучшей читаемости или лучшего статического анализа - берите DI-либу которая не позволяет использовать Service locator, который считается антипаттерном (если не знакомы - гуглите сами, я не нашел хороших статей 😅).

Это было общее описание. А теперь про личный опыт и немного рекламы.

По моей практике сервис локатора на зависимости которые обрабатывают IO достаточно. Если у вас axios, можно обойтись лишь https://www.npmjs.com/package/axios-mock-adapter. Но иногда есть другие IO (postMessage), иногда нужно замокать какие-то таймеры или у сетевого слоя есть своя большая обвязка, или нужно замокать какие-то сильно изолированные модули, библиотеки. Я проектировал Reatom в том числе с расчетом на то что бы можно было легко тестировать порождаемые им сущности. Апишка впринципе задизайнена так что каждый атом / экшен работает только в переданном контексте (это нужно для множества фич), так почему бы этот контекст не использовать для моков - для этого уже есть пакет https://www.reatom.dev/packages/testing, он дает общий mock или mockAction для перехвата и подмены вызова какого-то сайд-эффекта. Круто то что в реатоме это просто работает, не нужен вообще никакой доп. код 🤗. Выглядит в использовании это максимально просто - мы либо оборачиваем каждый наш эффект в отдельный экшен, либо создаем сервис атом - тупо оборачиваем сервис в атом и обращаемся к сервису через чтение атома (кода это требует минимум). Пример есть в https://www.reatom.dev/core: const api = ctx.get(apiAtom).
P.S. в реатоме и логгер красивый есть.

UPD
- https://bespoyasov.ru/blog/di-ts-in-practice/

Забыл еще рассказать про лайфсайкл хуки и возможность инстанцирования синглтона или фабрики… Вообще IoC - это сердце и архитектурный базис (на уровне апликейшена). Надо бы поподробнее потом расписать.

Решили использовать либу от одного очень большого интеграционного сервиса, а она поставляется только с их CDN, типов нет, а в исходниках лежит их package.json (WAT?) и в нем…

codeque.co

Крутой тул, давно искал что-то такое. Регексп ищет по символам, а эта штука учитывает контекст из AST. Еще и eslint плагин есть.

На скрине пример простого решения задачи, которую я не смог решить на регекспах: найти вызовы useRequest где apiMethod передается по условию (нужно было это зарефакторить).

Кстати, для автоматизированного рефакторинга по AST посмотрите на putout.

🔥@reatom/npm-svelte🔥

Доки.

Демка с датафетчингом: всего несколько килобайт за тонну фич (смотрите доки к пакету async).

Напомню фичи реатома: микроскопический бандл, максимальный перф, экосистема, продуманный под капотом, легкий для тестирования, заточен под автоматический вывод типов.

https://www.kinopoisk.ru/film/957887/

Рекомендую :)

Зацените снежок на WebGL. Выглядит очень реалистично!

Вот исходники френдли для подключения к себе на сайт (блог). Весят около 18кб, причем большая часть это бейс64 картинка, можно поменьше свое что-то подставить.

Эффектор.

Кто я такой? Тут про общий опыт. Я был примерно пятым человеком в мире который начал писать на эффекторе прод, когда он еще только появился. Было прикольно, сильно лучше редакса. Я много его тестировал и экспериментировал с ним, изучал исходники и даже записывал туториалы на ютубе. Это еще в 2019 было.

С самого начала эффектор заявлялся как быстрое решение, там использовался достаточно интересный алгоритм для топсорта и решения проблемы глитчей. Были бенчи, эффектор был на хорошем уровне. Заголовок про перф так и остался, но потом что-то пошло не так и об этом мы еще поговорим.

Сначала скажу по тех части.

- Используемая концепция вечногорячих обсерваблов наиболее предсказуемая и “просто работает” - это хорошо. Плохо то что это может негативно сказываться на перфе (вычисляется вообще все и всегда, для всех загруженных страниц, которые уже не показываются) и чинить это фабриками считается плохой практикой и чревато мемори ликами, нужно в этом случае очень хорошо понимать как и что делать.
- Атомарности нет вообще и лично для меня это катастрофический недостаток. Я не верю в то что непредвиденных ошибок в вычислениях в проде не может быть, как заявляют пользователи эффектора. Требование к идеальному тестированию для использования библиотеки мне кажется очень странным.
- Декларативное апи - птичий язык, позволяющий красиво описать простые кейсы и страдать (городить чрезмерные конструкции, с точки зрения процедурного программирования) при попытках описать что-то сложное. Это мое мнение. Кому-то такое апи кажется прекрасным балансом между выразительностью и количеством кода, я же вижу в этом избыточную сложность, которая накладывает ограничения не там где надо. Постоянные баги с типизацией это доказывают, нет? Мне говорят что такое апи близко к естественному языку бизнеса, но покажите мне заказчика не программиста, который поймет в этом коде хотя бы что-то. Говорил давно и скажу опять, хотите хорошее декларативное апи - делайте свой DSL с упрощенным синтаксисом.
- Производительность. Она в целом лучше чем у редакса и достаточная для множества случаев. Околомобыксовая, зависит от кода конечно. Хотя есть множество публичных и не публичных (тут мне на слово придется поверить) случаев, когда авторы заявляли про максимальный перф, а потом оказывалось все сильно иначе. Бенчей нет и текущий тейк от ментейнеров про “перф нормально невозможно замерить” для меня выглядит как очевидная отговорка что бы замять тему.

И тут мы приходим к ответу на вопрос “А какое тебе вообще дело?”. Агресивность, токсичность и необъективность фанатов эффектора постоянно переходят все границы. Я не могу это спокойно воспринимать, а приходится, тк сталкиваюсь с этим периодически. Это очень похоже на религию - есть только один верный путь, остальному - джихад. Ужасно.

Представители комьюнити эффектора часто не воспринимают мнение человека, унижая его идеи и даже факты от него, без попыток объективного анализа и доказательства, оперируя субъективными терминами “красиво” или “интуитивно” (и десятком других), без анализа всей картины.
Сотни случаев советовать эффектор не к месту бьют все рекорды, пользователи других библиотек так не делают.
Агресивные наезды на мнение о каких-либо недостатках эффектора - норма.
Агрессия к тем кто переиспользует код из репозитория эффектора без указания авторства (лицензия MIT). Речь о нескольких десятках строк, этот инцидент произошел со мной давно, но мне кажется он хорошо илюстрирует проблему.

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

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

transferables

Подписан на создателя https://bundlejs.com в тви (twitter.com/okikio_dev).

У него вышла новая либа для проверки возможности передачи объекта между потоками - почитайте доки и исходники, там интересно!

Закинул ему пару мелких ПРов по улучшению производительности, простые и наглядные: раз, два.

На внезапном стриме через 2 минуты с @artalar посмотрим недавно вышедшую вторую версию менеджера управления состоянием reatom

🐶 Напишем игру с цветами 

📺 Посмотреть: twitch.tv/kirjs | youtu.be/SdOPCKXhc0k 
🎫 Доки: reatom.dev

JPEG XL

Текст не мой, анрол этого треда, который мне показался очень полезным. Igor Strebz пишет:

Меня не волновала монополия Google Chrome, ведь браузеры итак поддерживают достаточно стандартов для комфортного сёрфинга.

Отношение изменилось, когда Google заблокировало развитие формата JPEG XL по надуманной причине. Смотрите, каким с ним станет веб: https://youtu.be/UphN1_7nP8U

1. Уже после 50 килобайт (8%) браузер уже смог бы что-то показать, не дожидаясь окончания загрузки
2. Оптимальный по весу, на 30% меньше чем JPEG
3. Можно пережать JPEG → JPEG XL без потери качества, сэкономив место
4. Мемы станут стабильнее, даже 2000 пересохранений спустя картинка не меняется, в отличии от других форматов: https://pbs.twimg.com/media/FljpjyUXEAEV-hp?format=jpg&name=large
5. Можно использовать для фотографий космоса с колоссальным разрешениями и весом файлов за 100 Мб
6. Без патентов, чистый open source

Как ни крути, формат отличный.

Google решили так продвигать свой AVIF ≃ стоп-кадр видео-кодека AV1. Из-за чего есть ограничения, сравните: https://pbs.twimg.com/media/FljqLokXoAUMH46?format=jpg&name=large

Для webdev'a безумно много фичей, снимающих головную боль:
- альфа канал
- жмёт loseless лучше чем PNG
- параллельный decoding
- 10x быстрее encoding по сравнению с AVIF
- XYB color space, больше тёмных цветов
- браузеры с progressive decoding автоматом могли бы получать @1x из @2x

Сообщество взбунтовалось, ответ Google убил:
> The new image format does not bring sufficient incremental benefits over existing formats
🤨⁉️
> There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
😕 тоже ложь
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c64

Там буквально пришёл principal engineer из Intel и указал им, что последнее утверждение не подтверждается на практике: Adobe, Serif, Krita и Intel — в своих продуктах внедрили поддержку JPEG XL из-за HDR и предлагают использовать по умолчанию 🤷🏻‍♂️

Act

Самая-самая библиотека для описания реактиных связей!

Сделал по приколу. Но я серьезно. Треть килобайта, Карл! По перфу в топе топов, причем не в простых кейсах, а с разруливанием всех пограничных случаев условных переподписок… На простых кейсах оно в космос улетает.

Апишка намеренно максимально простая. Это современное перерождение легендарного S.js.

А в чем секрет? Аллочка ты сума сойдешь! Вместо сложных проверок инвалидации кеша я просто пересоздаю весь граф на каждый апдейт, оказывается это быстрее, иммутабельный подход быстрее! А учитывая то что графы в рядовых приложениях редко бывают большими, скорее множество отдельных и мелких - проблем с этим не возникнет. Вообще в 2023 память работает очень хорошо, на мобилках (критичном сегменте) используется SoC и за счет этого там скорости побыстрее ваших i7 бывают.

Биндингов нет, сами пишите, мне не охото. У меня отпуск.

https://www.youtube.com/watch?v=yy8jQgmhbAU

По рекомендация из чата:

помню доклад, года 2017 на cppcon, где часть браузера с OOP на DOP переписали и код стал в 450 раз быстрее