Стори тесты!

Идея такая: пишем отдельные тесты с адекватным неймингом и коментами и автоматически копируем их в доку.

Отличие от реплов / сендбоксов в том что такой тест проверятеся на каждый апдейт в используемых фичах и всегда будет актуален. Ну и ментейнеру немного меньше работы :)
Так же, такой текст позволяет показать какой-то сценарий работы (многоступенчатый?). В репле это не удобно расписывать, а просто текстом обычно занимает много места - скриншоты с повторным кодом и т.п.

Что думаете?

Примеры:

https://www.reatom.dev/packages/async#story-test

https://www.reatom.dev/packages/testing#story-test

Доклад с YaTalks можно глянуть по таймкоду https://youtu.be/G72O84_mIqI?t=8550

Надеюсь, что скоро нарежут на отдельные файлы.

Service Worker

Недавно подключал их к reatom.dev для офлайн доступа и быстрого повторного захода: https://github.com/artalar/reatom/pull/448, по коммитам можно увидеть как не просто мне это далось :)

В интернете очень много статей с нерабочим кодом, причем некоторые статьи из 2020 🤷‍♂. Мне больше всего помогла статья из заголовка и вот эта: https://habr.com/ru/company/2gis/blog/345552/, тут сразу есть несколько простых примеров под разные стратегии.

В планах еще подрубить htm для обновления контента после загрузки офлайн версии без необходимости перезагрузки страницы. Просто реплейснуть html будет плохо тк скролл и другие состояния собьются.

P.S. да я тыкал workbox, мне он простым не показался.

ufostation.tech

Завершил веху работы над сайтом — перенес основные посты из телеграмм канала. Все исходники в открытом виде на github, материалы свободно распостраняются по CC BY-SA 4.0 (копируй/модифицируй).

Буду рад любой обратной связи, которая поможет улучшить ресурс: комментарии под этим постом, сообщения в личку, любой issue или pull requests на github.

Нравится контент? Поддержи меня на boosty 🙃

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 - нам еще многое предстоит сделать в этом направлении и конкуренция здесь необходима. Я хочу видеть больше крутых идей и их реализаций. В дружественной среде.