Комментарии 12
Рад, что статья пришлась по душе.
Не часто выпадают такие задачи, поэтому, в целом, не было понимания на каком уровне находятся web components. Очень классный и мощный инструмент, но все же имеет свои плюсы и минусы. Так что все равно приходится подбирать инструмент под задачи. Тот же Youtube встраивает свои видео через iframe.
"нужно встроить форму регистрации" и для этого городить?
Неужели на нативном так трудно писать, что надо кучу д...ма к web-приложению тащить.
Соглашусь, можно написать нативно. Тогда будет банд маленького размера, ну или как минимум меньше, чем нам достанется от Angular.
Но стоит смотреть на ситуацию под разными углами. Например, форма может уже существовать в рамках другого Angular-приложения. Тогда создать вторую форму на нативных технологиях будет "дороже", как по написанию, так и по поддержке, придётся повторять одну и ту же логику дважды на разных технологиях.
Имея под рукой UI-кит, инструменты для работы с формами и т.д., можно ускориться в процессе разработки, что тоже важно. А также готовые и проверенные инструменты уберегут нас от мелких проблем, таких как, например, баги кроссбраузерной верстки.
Также стоит смотреть в сторону дальнейшего развития функционала. Сегодня у нас два поля и кнопка, а завтра это может быть форма со степпером или другой логикой. Придётся создавать "конструктор форм", что уже будет на порядок сложнее.
И вот вы почти пришли к Module federation. Так встроить форму будет ещё дешевле за счёт того, что в родительском приложении уже будет готов ангуляр.
Конечно это так. Но раз выше шла речь про UI-кит, инструменты и знакомую среду, то, возможно, дойдет дело и до оптимизации. Это с одной стороны кажется, что там сложно, а по факту всего-то конфиг подкинуть в основном приложнии, которое будет говорить а что же оно отдает, и в дочернем веб компоненте, которое также будет говорить, что отдает оно. И вот при совпадении зависимостей у основного приложения и компонента дважды не будут тянуться повторящиеся библиотеки. Сейчас, может, и не важно, а потом - как знать.
А как же классический вариант встройки виджета? Как нативные js-библиотеки работают, когда размещаешь контейнер, подключаешь скрипт, а он встраивает мини приложение в этот контейнер.
Я пишу на Vue, и у нас была задача встройки калькулятора на страницы, сделали виджет. На странице нужно создать просто div с id, виджет туда встраивает маленькое Vue приложение.
В формате виджета можно сделать даже 2 версии, одна с фреймворком, вторая без, и встраивай хоть в другое приложение, хоть на страницу отдельную, где не подключен ещё фреймворк.
Web Components тоже прикольная тема, просто удивилась, что самый классический способ решения не упомянут.
Каюсь, упустил этот вариант. Спасибо, что натолкнул на этот вариант. Потребовалось некоторое время, чтобы изучить этот вопрос.
Если приложение-компонент одно, не имеет необходимости в общении с внешним сайтом, то очень даже подходит. Я бы сказал, что практически web-component.
Из плюсов
Доступ к window и другим данным родительской страницы как в web component и так же работают css-переменные, можно добиться конфигурирования.
Встраивание аналогично Web-components
Практически закрывает все возможности, что было у web omponents.
Из минусов
Не получилось встроить второе приложение параллельно, Angular не рассчитан на 2 и более инстансов на одной странице.
Также не работает Router
Нельзя динамически создать несколько компонентов (1п)
Нет общения посредством Input-Output, если это необходимо, то придется повозиться.
В остальном, если этот вариант удобен, то почему бы и нет. Можно выбирать вариант под свои потребности любой рабочий вариант.
Сильно подробно не исследовал, скорее всего, что-нибудь еще упустил.
Web components как альтернатива iframe на примере Angular-компонентов