Comments 7
То есть для компонентов со сложной логикой и серьезным внутренним состоянием веб-компоненты не очень удобны?
Вероятно, это логично, так как в фреймворках многое делается именно для управления сложностью в логике, и стандарт вебкомпонентов никак не помогает нам в этой области. Хотя сама идея красивая - сделать свой HTML с блэкджеком и озорницами. Но поскольку все равно нужен javascript, то...
А что делать, если все эти продукты написаны на разных фреймворках?
Я бы подумал, раз их написали на разных фреймворках, значит и связанности быть не должно? В противном случае лучше сменить архитектора.
Выход за рамки вью либы/фреймворка ограничивает использование его фичей. Так можно было и компоненты на чистом js+css написать и вставлять в контейнеры html.
А то что вы описали про встраивание виджетов других команд решается на уровне сборки микрофронтов, в т.ч. module federation.
Короче на мой взгляд пользы не видно, только проблемы с поддержкой + необходимость вкатываться для новых членов команды
Я как раз разрабатываю микро-библиотеку чтобы можно было удобно создавать и обновлять DOM деклакративно, примерно как в React. Ее можно использовать как с вэб компонентами так и без них. Кстати логика mount/unmount под капотом реализована с помощью вэб компонентов, но она опциональна.
Немного самопиара в тему
Я вот недавно узнал о веб компонентах, и загорелся желанием запилить что то похожее на vue только с веб компонентами
И реактивность вкорячил и хуки и темплейты. Сейчас вот думаю над language server-ом и подсказкой ошибок typescript-а. И cli и сторы есть
Короче те кто хочет зацените тута
Во-первых спасибо за статью, мало кто пишет про веб компоненты. Хотелось бы уточнить что всё местами несколько сложнее чем описано. Например, инкапсуляция стилей выглядит немного поломанной, для тех кто только начинает работать с веб компонентами, но по факту просто наследуемые стили протекают по дизайну и это можно пофиксить одной строкой, после чего стили полностью изолированы (внутрь пробрасываются CSS переменные и можно, но не удобно, стилизовать т.н. parts). Кажется что передавать можно только строки в атрибуты, но по факту это только важно для полностью декларативного рендеринга на сервере, сами компоненты имеют настоящие свойства доступные из других фреймворков и вообще js. Ну и для SEO вполне реально отрендерить контент и запихать в слот, а потом распарить или даже выкинуть на клиенте. В целом внутри веб компонента может жить как сложное приложение так и простые контролы.
Ох, а использование Web Components не усложняет обеспечение веб-доступности ?
Написать семантическую верстку на основе дефолтных html5 тегов и обернуть в React/Vue компонент не лучше ли будет в этом плане, если действительно нужна веб-доступность для интернет портала?
Вопрос может показаться глупым, но у меня есть аргумент - я бэкендер, сорян :)
Используем очень активно веб-компоненты уже года четыре. Оркестатор микрофронтендов, но т.к. много легаси, то завёрнуто всё в вебкомпоненты для совместимости.
Основные проблемы, которые мешают:
1) Е2Е автотесты. Е2Е фреймворки либо вообще не умеют работать нормально с shadowRoot, либо заявляют что умеют, а по факту нет. В итоге куча самопальных костылей, которые с обновлением фреймворка могут требовать подпила.
2) Всякие внешние аналитики/репортеры/трейсеры а ля гуглоаналитика или сентри. Они не видят компоненты. Для гуглоаналитики в хитмапах это просто белая секция на экране. И приходится опять же писать костыли, чтобы клики и т.п. нормально прокидывалось в родительский скоуп.
3) devtools, например, Vue devtools. Если у вас есть vue внутри веб-компонента и приложение вокруг компонента - до информации в веб-компоненте вы не долезете. Опять, костыли, обновления, вот это всё.
В общем, поэтому, примерно, решение и не популярно. Нет поддержки со стороны сообщества, все инструменты допиливать надо самостоятельно.
Как подружить веб-компоненты и JS-фреймворки