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.

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

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

web VS native

Состояние на клиенте

Множество старыхопытных разработчиков постоянно выступают за максимально тонкие клиенты и одностраничные вебсайты (MPA), вместо SPA. SPA тяжелее, разделяют ответственность в кодовой базе и вносят лишнюю сложность.

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

У меня есть очень простой пример, которым я хотел бы поделиться, того что может происходить с простым текстом на самой обычной странице любого блога. Конечно речь даже не идет о редактировании, только об отображении.

Итак, какие фичи на странице с текстом простого блога могут улучшать UX пользователя, храня состояние локально.

1) Поиск. Браузеры до сих пор не умеют в нормальный поиск по странице, нет банальных настроек case sensetive и частичного / полного совпадения, нет регекспов, нет поиска по части документа и нет краткого превью результатов поиска с разбивкой по главам. Нет поиска по нескольким страницам в рамках всей или части карты сайта. Все это нужно.
2) Выделение. Хочется подсвечивать текст и складывать его в заметки. Иногда, нужно выделить и скопировать несколько кусков текста разом. Выделением практически нельзя управлять с клавиатуры. Все это нужно.
3) Ссылки. До сих пор в вебе нет нативной возможности скопировать ссылку на заголовок. Так же, пользователь должен мочь сам выбирать якоря для подсветки по ссылки.
4) Закладки. Как на больших статьях помечать где пользователь остановился читать?
5) Предварительный просмотр. Картинки нужно мочь зумить, формулы вычислять, код запускать, диаграммы передвигать и тп.
6) Специфичные типы данных. Даты должны мочь добавляться в календарь, цвета копироваться с выбором формата, элементы списков отмечаться как выполненные, а денежные суммы переводиться в другую валюту.

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

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

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

SWC

У нас на проекте несколько сотен тысяч строк кода в монорепе, разбросанных по десяткам пакетов. Крупнейший сервис (админка) собирается на M1 с бабелем секунд 80 (после установки нод модулей). Мой коллега @Astartsky решил поправить перф сборки и попробовать SWC.

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

Скольки вы думаете?)

10 секунд, ускорение в ~8 раз. Для нас это значительная разница и результат очень обрадовал.

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

Через минут 5 войс про перф оптимизацию, которую я долго искал и когда нашел ужаснулся

Качество звука не очень, я завтра ещё текстом подробно опишу.

Всем хороших выходных

Профилирование производительности

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

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

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

По факту все было дольше и вот почему:

1) Из стандартного отсортированного списка вызовов функций я ничего понять не смог. Пошел изучал флеймграф. Там тоже мало что понятно, пока не не схлопнешь одинаковые вызовы вместе (Toggle left-heavy view).
2) В бенче происходило много лишней работы, кроме самого теста реатома, которая мусорила в результаты. Для удобства чтения я закомментировал не важный для анализа код.
3) Когда я нашел прожорливое место перейти в исходники мне не удалось, видимо сурсмапы не подтягивались. Понимать минифицированный код было очень сложно, а преттиер не хотел его форматировать из-за какой-то ошибки парсинга. К счастью, у меня был установлен Rome и он смог отформатировать код к более понятному состоянию.
4) Я перезапустил профайлер и переоткрыл флеймграф, но ссылка на функцию потребляющую много ресурсов все еще вела на первую строчку, как будто код все еще минифицирован. Помогло только rm /Users/artalar/.quokka/test.cpuprofile
5) Дальше меня ждал большой сюрприз, функция которая потребляля треть перфа в большом пайплайне операций была очень тривиальной и я все никак не мог понять в чем там проблема. Тк. профилировщик дает ссылку не на конкрутную проблемную операцию, а на содержащую ее функцию, я решил разбить внутрении операции на отдельные функции, а для удобочитаемости минифицированного кода я переписал функцию на методы тестового объекта - минификатор не меняет имена свойств, только переменные.
6) Повторяем п. 4 и вуаля! Проблема найдена. В минифицированной версии спред заменялся на свою реализацию с Object.assign (или полифилом).

Осталось лишь переписать копирование объекта на ручной перебор всех свойств и флеймграф стал более равномерным, ура-ура!)

P.S. Я попробовал запустить бенч с импортом из исходников, а не билда, для нормальной работы сурсмапов, но сами результаты тестов в этом случае едут (терсер и другие минификаторы делают некоторые AOT улучшения кода), да и ссылки все равно были на транспилированную версию без типов, которую делает квока под каптом.
P.P.S. После смены таргета билда на современные браузеры спред не транспилируется и работает быстрее, но версия с ручным перебором свойств все равно заметно быстрее.