Мультиверсионный UI-кит с RWC: один JS-API для разных веб-компонентов

Значимый прорыв формирует отрасль ИИ: tamazyanarsen 45 минут назад Мультиверсионный UI-кит с RWC: один JS-API для разных веб-компонентов Средний 10 мин 1. 8K JavaScript * TypeScript * HTML * Обзор Ссылка на githubReactive Web Components: реактивность без фреймворкаЗачем держать несколько версий UI-кита на одной страницеПредставьте платформу из нескольких десятков микрофронтендов: они катятся независимо разными командами и используют общий UI-кит. В какой-то момент кит нужно развивать — новый дизайн-токен, переработанная кнопка, ломающее изменение в API компонента.

И тут возникает проблема, которая по своей природе организационная, а не техническая: обновить все модули одновременно невозможно. Обычно остаётся выбор из двух плохих вариантов. Либо big-bang-миграция: все команды бросают фичи и синхронно переезжают на новую версию — это дорого, рискованно и почти никогда не укладывается в один релиз.

Технические детали

Либо заморозка: UI-кит перестаёт развиваться, потому что любое ломающее изменение блокирует слишком многих. В первом случае страдает скорость команд, во втором — продукт. На самом деле хочется третьего: чтобы новый модуль/виджет уже сегодня использовал UI-кит v2, соседний оставался на v1, и оба спокойно жили на одной странице.

Тогда миграция превращается в фоновый процесс «модуль за модулем» — без общего дедлайна и без риска уронить весь продукт разом. Насколько это вообще сложно — зависит от стека. В React и Angular такая мультиверсия достижима, но живёт она в конфигурации сборки и изоляции рантайма: какой версией компонента пользоваться, по сути решается в webpack.

js и в том, как нарезаны микрофронтенды (ниже описано более подробно). На веб-платформе есть более прямой рычаг — сам реестр Custom Elements. Именно с него и начинается разница.

Отраслевые последствия

Проблема: глобальный реестр Custom ElementsГлобальный реестр Custom Elements (window. customElements) допускает имя тега только один раз: повторный define с тем же именем (uwc-button) выбрасывает ошибку, и страница ломается. Для приложений с микрофронтенд-архитектурой или для поэтапной миграции UI-кита это жёсткое ограничение — разные модули не могут зарегистрировать разные версии одного компонента под одним тегом в глобальном реестре.

На уровне платформы это ограничение уже начали снимать через Scoped Custom Element Registries: можно создать отдельный реестр и привязать его к shadow root, и тогда один и тот же тег существует в разных скоупах независимо. Сейчас это отгружено в Safari и Chromium-браузерах (Chrome, Edge), но пока не поддерживается в Firefox и скоупит строго по shadow root — удобно, когда приложение целиком на веб-компонентах, и неудобно, когда хост не веб-компонентный (например, React), потому что под каждый скоуп нужна отдельная shadow-граница. RWC решает ту же задачу иначе и без этих ограничений: библиотека разделяет JS-фабрику компонента (объект TypeScript с API) и регистрацию Custom Element (тег в браузерном реестре).

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.