Конечный автомат для получения данных

#react #stateManagement

CommonJS vs ESM

#esm #commonjs

Генерация нескольких модульных форматов с помощью tsc

#tools #build #esm #commonjs

One more thing!

В пайплайне сборки проекта помимо запуска tsc могут быть и другие утилиты (например, api-extractor), в таком случае просто запустить все скрипты параллельно не получится, так как необходимо соблюдать порядок их запуска (api-extractor должен быть запущен только после генерации .d.ts файлов).

Для решения этой задачи я написал утилиту @lndsld/orc, которая сама запустит скрипты в нужной последовательности и распараллелит их, если это возможно. Для этого достаточно просто указать зависимости между скриптами прямо в package.json.

На текущий момент утилита имеет только самую базовую функциональность по оркестрации скриптов, но в будущем может стать более "умной", так что буду ждать вашего фидбэка :)

#tools #build

Мифология БЭМ

По моим наблюдениям, среди разработчиков распространён миф, что БЭМ — это просто довольно некрасивый и чрезмерно длинный способ нейминга CSS-классов, который не очень-то актуален в современной разработке ввиду наличия во фронтенд-экосистеме огромного количества более удобных инструментов, полностью заменяющих его. На самом деле, это в корне неверное суждение, поскольку БЭМ — это нечто большее, чем просто нейминг, и, на мой взгляд, он может быть полезен любому веб-разработчику независимо от технического стека...

#css #bestPractices

Хранимые и вычисляемые данные

Состоянием приложения являются данные, сохраняемые в памяти на определённом этапе его работы. Очень важно понимать, что не любые данные и не в любой ситуации имеет смысл куда-либо сохранять...

#react #stateManagement #computerScience #bestPractices

Инверсия зависимостей в React

Старые добрые принципы SOLID могут быть полезны в любой области разработки. Особенно важным я считаю принцип инверсии зависимостей. В React существуют механизмы, позволяющие реализовать этот принцип, и в этом очень помогает Typescript...

#react #bestPractices

Менеджмент зависимостей в Javascript

Для многих разработчиков процесс установки зависимостей представляет собой магию, которая происходит при выполнении npm install. Разработчикам, имеющим у себя в проекте большое количество зависимостей и тем, кто разрабатывает эти самые зависимости, публикуя в виде NPM-пакетов, будет полезно разобраться в принципах работы этой магии, чтобы сделать установку более эффективной и не создавать проблемы коллегам....

(Кнопка "посмотреть", видимо, только у ссылок на Telegraph появляется...)

#npm #tools

Релиз Rspack

Вчера вышла первая версия Rspack — бандлера, написанного на Rust, но с API, полностью совместимым с Webpack (ну пока что не полностью).

На бумаге это должно работать так: мы просто выкидываем Webpack из проекта, заменяем его на Rspack и получаем х10 скорость сборки.

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

Помимо заявленной совместимости с Webpack Rspack предлагает также некоторое количество инструментов из коробки: например, самого быстрого результата удалось достичь без использования каких-либо лоадеров для Typescript-файлов, так как в Rspack уже встроен SWC.

Этот релиз — ещё один большой шаг к глобальной "растификации" Javascript-экосистемы. Предыдущим похожим проектом был Turbopack, но, несмотря на схожесть названия, он не предлагал такого простого способа для миграции с Webpack.

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

#tools #build

Запуск сайта Hacknote.js

Переезд с Telegraph на Github Pages вдохновил меня на полноценное внедрение дизайн-системы, сделанной мной для этого блога на основе темы для VSCode, которой я пользуюсь, — Monokai.pro.

Блог — это контентно-ориентированный сайт, для которого самым важным фактором является скорость доставки контента до конечного пользователя, а самый быстрый способ — прислать готовый HTML. Для этого существуют различные фреймворки, поддерживающие SSR (Server Side Rendering), например, Next.js, а так же SSG (Static Site Generation), например, Gatsby.

SSR предполагает наличие сервера, что мне не подходит, поскольку я не могу запустить сервер на Github Pages, а вот SSG — именно то, что нужно, поскольку страницы создаются не в рантайме, а прямо во время сборки сайта.

Next.js и Gatsby мне совсем не понравились поскольку по какой-то причине без прикручивания к ним костылей прямо на старте они работать не захотели. Когда я уже почти начал реализовывать свой фреймворк, мне встретился Astro, и, как оказалось, он прямо из коробки делает абсолютно всё, что мне нужно, и невероятно прост в использовании. А ещё одной его крутой фишкой является то, что он может работать с любым UI фреймворком.

Заценивайте новый сайт, на который я уже перенёс несколько статей, включая ремастер статьи про менеджмент зависимостей с перерисованными картинками (кстати, весят они в 3 раза меньше, чем старые некрасивые).

#tools

Генерация превью для ссылок: получаем данные

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

#bestPractices #esm #ssg

Расширение VSCode для Rush

Некоторые из вас могут знать, что мне очень нравится Rush — утилита для управления Javascript-монорепозиторием от Microsoft. Я рассказывал про неё на прошлогоднем Holy.js.

К сожалению, официальное VSCode-расширение для неё всё ещё находится в разработке, и все действия приходится производить в CLI, поэтому я решил сделать своё.

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

#tools

Коробка от вендора

У меня тут накопились некоторые мысли и я решил немного побубнить на околоэкономическую тематику.

Как вы относитесь к использованию компаниями вендорских "коробочных решений"? Мне довелось неоднократно наблюдать кейсы, в которых компания за немыслимые деньги приобретает техническое решение, которое должно решить их проблему. После интеграции проходит некоторое время и вдруг выясняется, что эта коробка не очень-то соответствует требованиям бизнеса. Разработчики судорожно пытаются что-то наколхозить сверху, но коробка оказывается весьма неповоротливой, а вендор всячески избегает доработок и улучшения API — их основной целью всё-таки было продать продукт, а не поддерживать его. В моём наивном представлении о мире такая бизнес-модель не имеет права на существование.

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

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

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

17 июня буду рассказывать на Я ❤️ фронтенд о своих исследованиях на тему сборки библиотек. Планирую сделать этот доклад сиквелом к своей статье про пакетные менеджеры. Приходите послушать)

Как и обещал, публикую список ссылок к своему докладу на Я ❤️ фронтенд:
- You may not need a bundler
- Pure ESM package
- Named imports in CommonJS
- ESM in NodeJS Typescript
- Types for submodules
- Module resolution: bundler
- Vite library mode
- Пример исправления для поддержки SSR
- Не нужно бандлить библиотеку
- Rollup preserveModules
- ComonJS vs ESM
- Dual Package Hazard
- Валидация package.json
Список не исчерпывающий, так что по любым вопросам добро пожаловать в комментарии)

Наткнулся недавно на такой твит. Очень понравилась формулировка, поэтому делюсь в исходном виде.

Состояние гонки

Постарался разбавить статью интерактивными демками, чтобы было нагляднее. Надеюсь, вам понравится. 😊