Так, пояснение. Я не верю в единственный правильный форматтер и только ради условно красившего форматирования уходить с преттиера, который стандарт индустрии, не стал бы.

У рома главная фича в экосистеме, которой сейчас нет 🙃.

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

Асинхронная очередь.

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

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

Мне показалась моя же реализация сложной и не очевидной / не надежной и я решил еще подумать. После пары экспериментов в голову стукнуло максимально простое и понятное решение:

let chain = Promise.resolve()
export const add = cb => chain = chain.then(cb)

Тут здорово что then не хранит ссылку на предыдущий промис и нам не нужно заботиться об очистке памяти, под капотом список выглядит как односвязный linked list, голову которого подчищает GC, а мы храним только хвост.

Вот еще одна простая, но очень полезная утилита для очередей.

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

Заводить под это дело очередь и кидать в нее колбеки не удобно, код перестает выглядить синхронно и могут появляться конфликты имен переменных в скоупах колбека и кода после него.

Сделал утилиту с состоянием последнего времени запроса, для использования нужно авейтнуть ее вызов перед отправкой сообщения, просто и удобно.

…

Посмотрел на предыдущий пост, можно было бы сделать еще проще:

freeMsgLimit = () => add(sleep(TLG_MESSAGE_LIMIT))

😀

Дождаться завершения всех промисов.
Продолжаем про асинхронные очереди 🙂

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

Придумали?

Т.к. в редаксе есть единая централизованная точка входа на все IO сделать там это очень просто: накинуть мидлвару, которая создаётся из функции которая принимает колбек и создаёт в замыкании каунтер эффектов. Если из диспатча возвращается instanceOf Promise - инкрементим каунтер и вешаем finally с колбеком на декремент каунтера, где еще проверяем, если каунтер стал нулем - вызываем колбек окончания всех эффектов.


store.dispatch = (…a) => {
i++
originalDispatch(…a).finaly(() => {
if (--i === 0) resolve()
})
}

Для реатома я делал что-то похожее.

И эффектор за кажущейся простой так же требует централизованную точку входа (scope, fork) и под капотом ведёт такой же каунтер.

react-admin

Я искренне считаю что будущее программирования за low-code решениями.

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

Но такие библиотеки есть, react-admin позволяет одним JSX описанием одновременно запросить, отобразить и дать изменить данные с API. Количество кода и его поддержка сокращается в разы. Квинтесенция компонентной архитектуры!

Конечно, есть миллион краевых случаев, где оно что-то не может, а где-то не интуитивно. Но со многими задачами справляется на ура. Я пробовал эту либу год назад, столкнулся с кучкой проблем, но в общем понравилось. Недавно вышла 4 версия в которой провели серьезный технический рефакторинг (redux -> react-query и mui5).

Рекомендую попробовать, хотя бы что бы посмотреть как вообще бывает.

#lowcode

hasura.io

Ещё одно прекрасное #lowcode решение - на стыке фреймворка и графического интерфейса.

Хасура - это платформа для быстрого построения оптимального бекенда. Основной сценарий такой: запускаем ее с кредами к одной из поддерживаемых БД, открываем сайт админки, создаем новую таблицу / колонку / связь / запись или что-то еще делаем в визуальном редакторе и мгновенно получаем обновленный GraphQL апи с типовыми CRUD операциями и базовыми констрейтами. Система пермишенов и гайды как ее настраивать есть из коробки. Для валидации и сложной / асинхронной логики есть экшены - что-то вроде встроенного serverless.

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

Вообще, фич у Хасуры очень много: миграции, REST апи, кеширование, оптимизации SQL и куча всего. И мне хочется похвалить их документацию, за пол года пользования у меня почти не появлялись неотвеченные вопросы.

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

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

Пол часа поговорим про хасуру. Расскажу про свой опыт. Будет запись

airtable

Вы все еще не прониклись идеей #lowcode? Тогда ознакомьтесь с этой статьей Вастрика, в которой он положительно отзывается об Airtable - альтернативе Google Sheets.

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

Гугловая апишка ужасно не удобная. Что бы сделать кросстабличные зависимые поля в аиртейбл нужно сильно поплясать и то не факт что получиться, а их визуальные билдеры представления / форм ну очень тривиальные.

Тоже самое я могу сказать и о trello, качество плагинов к которому оставляет желать лучшего. Notion притормаживает и все еще не имеет достаточно фич, что бы соперничать с гуглом.

Есть еще coda, но я не осилил 🙃

Невеселая нота - мотивация для ваших стартапов 🙂

Про лоукод, пока, все.

copilot

Мою жизнь заметно облегчает AI’шное автодополнение, главное понимать когда его нужно использовать.

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

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

Тоже используем patch-package, редко обходится без него, больше пакетов в зависимостях - больше вероятность что что-то сломается, а у нас проект на пол миллиона строк.

Я уже рассказывал про трудности обновления зависимостей, patch-package там тоже учавствовал.

Сейчас чекнул, у нас больше 300 строк дифов для него в проекте 🙃

patch-package

Предыстория. Решил я обновить зависимости в своем блоге, накопилось около 200х проблем в безопасности (npm audit), да и думал дел на полчаса максимум, это же просто блог. Почти базовая конфигурация вебпака, минималистичный движок для блога на javascript (11ty), да и собственно все. В очередной раз, как же я ошибался.

Брейкинг ченджи в новых версиях, их несовместимость друг с другом и прочее затянулось на несколько часов исправлений. Одна из проблем была в том, что основной пакет для генерации блога обновил версию шаблонизатора liquid на пару мажорных версий, и это сломало рендеринг всех страниц с маркдаун вставками. На гитхабе по теме даже есть ишьюс, в котором есть обсуждения и причина, почему теперь работает именно так, но нет решения. Переходить на другой шаблонизатор долго, откатывать версию 11ty на прошлую или делать форк не хочется. Что же делать?

На помощь приходит библиотека patch-package, которая позволяет сделать правки в node modules, сохранить их в виде diff-файла и накатить после установки зависимостей.

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

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

Попробовал переписать в реатоме использование временной хешмапы с патчами во время транзакции на опциональные инлайн кеши, которые чищу в конце транзакции.

С вычеслительной точки зрения разница большая.

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

На этой неделе у многих выходные, сложно выбрать тему, которую хотелось бы обсудить.

Покопался в старых заметках…

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

Доступность как архитектура UI.

Было дело год назад. Таска - по клику на экшен в строке списка нужно показать модалку с запросом доп. информации и сабмитом / отменой. Вроде, все просто, но мы сразу решили подумать о хорошем UX.

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

И сейчас я рекомендую делать это каждому разработчику интерфейсов!

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

WAI-ARIA - это гайдлайны о том как делать интерфейсы понятными и удобными для любого пользователя. Там есть учет всех (ну почти) краевых случаев, без обработки которых вы рискуете оставить вашего пользователя в очень не приятных чувствах, когда что-то пойдет не потому пути, который вы протестировали что бы сдать очередную таску.

К сожалению, далеко не все дизайн системы и компоненты в npm следуют этим практикам или реализуют их все, т.к. спека живая и многое из написанного достаточно свежо. Многие термины у нас в экосистеме и комьюнити понимаются и используются не правильно, такое наследие. Вот мои заметки по итогу иследования. Отдельное спасибо @maniyax.

В ру комьюнити есть прекрасный чат @a11ycommunity, в котором можно найти ответы на вопросы по самым не обычным случаям.

Вот понятный набор базовых компонентов. А вот большой набор примеров большинства интерактивных компонентов, с детальным описанием что и как нужно делать.

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

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

createDialogAtom

По результатам иследований родился код для реатома, который опирался на useDialogState реакита, но проще переиспользовался и шарился. Один атом - подписка на стейт и экшены для его управления, намного удобнее реактовских контекстов или props drilling. Ну и дебаг приятнее.

Это не реклама, просто пишу как получилось 🙂

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

Посмотрите код примера, я даже JSDoc там расскидал.