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

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 там расскидал.

headless ui

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

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

К счастью, сейчас набирают популярность библиотеки логики компонентов, без отображения. В предыдущем посте я упоминал Reakit. Какое-то время это была прорывная библиотека и я за нее топил, но поддержка у нее достаточно слабая. Ее новая версия немного сменила брендинг и выглядит сейчас очень интересно: https://ariakit.org (несмотря на версию, можете ее уже считать стабильной).

Топовой альтернативой сейчас кажется Radix. Сам не пробовал, но выглядит хорошо и отзывы я слышал положительные.

Есть ещё большой и очень проработанный react-spectrum от Adobe, я точно могу рекомендовать к прочтению их доку по архитектуре и блог. Но апишка достаточно специфическая и работать с ней тяжело, особенно если вам нужно реализовать не большую обособленную дизайн систему, а просто накидать компоненты для бизнес приложения.

Reach UI маленький и старый, к тому же там все же есть завязка на view слой.

Есть ещё headlessui.dev от тайлвиндеров, я не пробовал, да и не очень много там компонентов.

Жаль что из всех перечисленных библиотек чистое отделение логики есть только у Реакита, и то с помощью хуков. Остальные все же завязываются на компоненты.

UPD: Ребята из Material-UI, наконец, тоже начали делать компоненты и хуки без стилей. Пока в альфе. Я очень жду, mui отличный кит.

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

Да этоже просто наибомбически!

codeclip.io

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

Простые вещи должны делаться проще!

Инспектинг лога не такой удобный как в vscode, мб допилят потом.

Ну например: https://codeclip.io/ZchxyOaD

Еще и скрины с логом позволяет делать. Жаль лог не форматируется.

Есть свободное время на выходных?)
Выложили записи последней Холи

https://youtube.com/playlist?list=PL8sJahqnzh8IlH_MOaG91bCt5DpG5TWLD

Архитектура веба

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

Я считаю, что это сильно устаревший взгляд на вещи.

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

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

2. Доступ к веб приложению легкий, надежный, понятный. Концепция URL великолепна.

3. Доступ к стейту приложения по URL вообще невероятная киллер-фича. Все этим пользуются даже не задумываясь.

4. Server-first распространение [кода] приложения намного улучшает опыт обновления приложения как для пользователя, так и для разработчика: первый даже не замечает это, а второму не нужно поддерживать устаревшие апи.

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

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

8. The last, but not least. Исходники веб страницы открыты и кто угодно может их инспектировать и модифицировать. Редкая фича в нативке. Профит для пользователя в этом огромный: режим для чтения, контрастная тема, блокировщик рекламы, да просто свои стили или скрипты. Конечно, с этим есть сложности, особенно в плане безопасности. Но в конечном итоге, открытые платформы более надежны: они открыты для непредвзятого аудита и хотфиксы к ним делать проще.

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

Добавьте к этому стандартизированную систему расширений, что абсолютно уникально.

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

По перформансу веб может делать невероятные вещи уже лет 7. Я бы оценил этот вопрос так: половина приложений может быть написана на абсолютно наивном коде, 40% нуждается в не сложных оптимизациях, 9% нуждается в сложных оптимизациях и 1% нуждается в переизобритениях велосипеда, когда необходимо использовать canvas / webgl. Думаю, ничто не совершенно и это хорошие показатели.

На последок, свежая вдохновляющая история: I Replaced My Native iOS App with a Cross-Platform Web App and No One Noticed.

Каким безумцем нужно быть, что бы презреть все эти фичи и писать на нативке? 🙃

Го обсудим это в войсе через несколько минут. Заходите, особенно, если вы против))