Решил попробовать Vitest.

А подтолкнуло меня к этому вот это видео с Артемом Захарченко про Mock Service Worker - https://youtu.be/-g_jGlIbJys?t=2973&si=42y5PRXrxt8iKRCU

Ссылку вставил на конкретный момент про Vitest, но советую посмотреть все видео - там Артем очень подробно рассказывает про архитектуру MSW, его преимущества и вообще про юнит тестирование в целом.

MSW кстати потрясающая библиотека, и по сути должна являться стандартом для мокирования запросов. Первый фронтенд фреймворк, который приходит на ум - это Next, а вот первая библиотека для моков API - должен быть MSW, только так.

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

Поэтому буду писать тесты для трекера на Vitest.

Закрытие окна загрузки файлов закрывает родительскую модалку с ролью "dialog"

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

Вместо этого закрывается и модалка вместе с формой. И вашими данными.

Так вот, оказывается cancel ивент из нативного окна выбора файлов, которое открывается при клике на <input type="file" />, всплывает в родительский <dialog /> или элемент с этой ролью (role="dialog").

И если вы поставили обработчик onCancel на этот элемент - то он будет выполнен.

Судя по всему, изначально, когда этот баг только появился, событие cancel не просто триггерило обработчик, но и натурально закрывало диалог - https://stackoverflow.com/questions/76372090/cancel-input-file-close-dialog-element. Сейчас же это поведение пофиксили, но обработчик все равно вызывается - https://jsfiddle.net/artabr/b6k4r19o/.

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

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

А началось все с безобидного добавления role="dialog" - спасибо WCAG 😁

Вот это действительно стоит посмотреть.

Ни кто иной как Matt Pocock сделал курс по MCP.

Его вклад в JS экосистему сложно переоценить - XState, Total TypeScript и всегда очень качественные обучающие видео.

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

https://www.aihero.dev/model-context-protocol-tutorial

Что по трекеру?

Изначально идея была лишь в том, чтобы выложить в Google Play хоть какое-то приложение.

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

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

В общем планов много, да и как-то прикипел я к этому проекту. Прикольно наблюдать как он из простейшей поделки на Expo Go становится взрослым приложением, у которого есть своя страничка на Google Play. А дальше ведь еще больше всего.

А еще проект решил поддержать мой товарищ - UI/UX дизайнер. И теперь приложение будет еще и приятным на вид и удобным в использовании.

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

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

Вся разработка в опен сорсе. Кроме приложения ещё есть классические фронт задачи. Из приоритетного уже понятно, что нужно делать мультиязычный лэндинг и блог на Next.js.

Только NX нормально работает с Expo

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

Сейчас существует несколько вариантов для организации монорепо - нативный функционал бандлеров (NPM/Yarn/PNPM Workspaces), NX и хайповый Turborepo.

Мой стандартный выбор - это NX. Обожаю NX.

Но тут решил посмотреть, что же предлагает Turborepo. Turbo используют популярные темплейты типа t3-stack, вообщем-то все темплейты, которые я нашёл, использовали Turbo - думаю, наверное, должно работать хорошо. 

И оно работает. До тех пор пока не делаешь собственный дев билд с помощью prebuild. С Expo Go работает прекрасно, как только делаешь пребилд - все разваливается. А без пребилда по сути нельзя делать нормальные приложения.

В моем случае билд не собирается, потому что при сборке в Turbo откуда-то появляется старая версия Котлина. Есть ещё и другие приколы - типа в Турбо нужно прямо указывать в конфиге какие энв переменные нужно передавать в билд (например ANDROID_HOME) - зачем, я так и не понял - но это не баг конечно, скорее скилл ишью с моей стороны, они решили сделать именно так, и в доке это прописано. Просто странно.

В NX в случае с Expo не работает терминал Expo CLI - не работают шорткаты a, r, shift+m и т.д. Но если запускать напрямую, не через NX CLI - то все прекрасно работает.

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

В моем случае проект также работает на Bun, с Biome в качестве линтера, и забирает компонент с библиотеки, которая будет отдельным пайплайном публиковаться в NPM. Просто теперь этим стало чуть удобнее управлять.

К сожалению, релиз сегодня отменяется - Курсор удалил весь мой код

Одно из главных преимуществ Expo всегда было удобство разработки. 

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

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

Этот клиент тоже будет просить ссылку на дев сервер и сперва я думал, что придется крутить собственный сервер, к которому будут подключаться заинтересованные лица (в моем случае дизайнер). Сделал даже пайплайн в GitHub Actions, который собирает текущий коммит в докер образ, и деплоит это все на сервер.

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

А оказывается все было проще. В Expo есть сервис EAS Update, который позволяет упаковать текущее состояние приложения, и открыть его из дев клиента. И никакого сервера не нужно. Достаточно ссылку дизайнеру ссылку на apk дев клиента и QR апдейта. 

А вот уже сами апдейты можно собирать в GH Actions по коммиту.

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

На это раз Spotify https://x.com/tobi/status/1909251946235437514

Всё, теперь это база. Потому что работает.

Эксперимент с NativeWind закончился неудачно.

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

Проблема в том, как NativeWind сейчас работает - под капотом NativeWind преобразует ваши TW классы в React Native StyleSheet - и этот дополнительный шаг вызывает дополнительные проблемы. Во первых, это заметно во время разработки - ты добавляешь класс, и долю секунды бандлер думает, просчитывает, и добавляет нужный StyleSheet.

Во вторых, иногда он просто их не добавляет. Реально. Есть куча ишью на ГХ, где люди описывают свои пропавшие стили. В основном, такие ишью закрыты как stale, и складывается что люди просто не получают решения и уходят от NativeWind (как и я).

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

Выходит, что NativeWind добавляет ещё один слой в систему, в которой и так уже слишком много слоев.

Складывается впечатление, что если core команда React Native не добавит нативную стилизацию с помощью TW, комфортно работать с ним в React Native так и не получится.

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

Последнее время не слежу за новостной повесткой и кажется упустил действительно важную новость.

Next добавляет поддержку Rspack.

А это действительно может означать увеличение скорости без сломанного проекта (в отличие от злополучного Turbopack, с котором они так носятся - ну или делают вид, потому что прогресса там никакого).

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

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

https://rspack.dev/blog/rspack-next-partner

Сегодня вышел релиз OpenNext 3.6.6 с моими изменениями и я стал полноценным контрибьютором в open source.

OpenNext - это проект, который позволяет деплоить Next.js в инфраструктуру других провайдеров помимо Vercel, причем делать это похожим на Vercel способом - а именно, исполняя код необходимый для ревалидации страниц не в Node сервере, а в серверной функции облачного провайдера.

В результате отпадает необходимость держать Node сервер, а SSR и ISR остаются. Ну и кроме этого появляются другие плюшки, вплоть до того, что можно деплоить разные пути своего приложения в разные регионы - например локаль /de/ - приземлить во Франкфурт, а /en/ в Лондон. Ну и в целом OpenNext дает возможность более широкого контроля над ресурсами, которые составляют приложение.

Проблемы, которые потребовали изменений возникли при апгрейде на Next 15 - мы делали апгрейд сразу с 13 на 15 версию, и это потребовало апгрейда со 2 на 3 версию OpenNext.

А в 3 версии OpenNext перестал складывать CSS файлы в серверный бандл, и как бы они там вообще-то и не нужны, за одним исключением - если они не будут использоваться во время ревалидации.

А вот мы как раз используем - для того, чтобы собрать Critical CSS и положить его прямо в генерируемый HTML.

В итоге пришлось возвращать CSS в бандл.

Кстати нужно сказать большое спасибо команде OpenNext за быстрое ревью и комменты. Ребята открыты для общения в Discord и максимально быстро отвечают на PR.

https://github.com/opennextjs/opennextjs-aws/releases/tag/v3.6.6