Недавно я участвовал в многочисленных дискуссиях о веб-компонентах и ​​заметил, что есть вопросы, которые до сих пор вызывают путаницу у разработчиков интерфейса. Создавая этот пост, я пытаюсь обобщить свою точку зрения на эту очень важную тему современного Интернета.

Вопрос: действительно ли они мне нужны?

Давайте будем честными — если вы интересуетесь веб-компонентами только из-за только что прочитанной статьи или выступления, которое вы только что посмотрели, ответ, вероятно, — нет, не сразу. Нет необходимости отказываться от фреймворков, с которыми вы знакомы, только для того, чтобы ввести еще один API в то, что вы создаете. Если кодовая база, с которой вы работаете, довольно последовательна или если нет необходимости извлекать компоненты, не зависящие от фреймворка, и, возможно, создаваемые вами проекты имеют относительно короткий срок годности, я бы посоветовал придерживаться решений, с которыми у вас больше всего опыта. С другой стороны, если вы работаете в разной среде, где разные приложения основаны на разных платформах, где вы можете найти фрагменты устаревшего кода то здесь, то там, и когда есть реальная потребность в рефакторинге в сторону компонентной архитектуры — да, в таких случаях я бы рассмотрел веб-компоненты. В SmartRecruiters мы решили пойти по этому пути, чтобы унифицировать несколько реализаций одной и той же функции, что привело к инкапсулированному компоненту, который можно использовать как в Angular, так и в других приложениях одновременно (мы — компания, активно использующая Angular). Это помогло нам уменьшить технический долг и общую сложность компонентов, связанных с предметной областью, с которой мы работаем, не заставляя везде поддерживать среду выполнения Angular. И мы все еще в самом начале нашего приключения с веб-компонентами — впереди еще много уроков.

В: Я вижу преимущества перехода на веб-компоненты, но почему их API настолько сырой, что его трудно продавать моей команде?

Причина, по которой API веб-компонентов выглядит таким сырым, как вы можете подумать, заключается в том, что они играют очень низкоуровневую роль в вашем технологическом стеке. Если бы внутри спецификации веб-компонентов существовал самоуверенный способ обработки привязки данных, шаблонов, управления состоянием или чего-то подобного, это закрыло бы двери для любых сторонних решений, которые можно было бы построить поверх него. Путаница также может возникнуть, когда вы сравниваете их с фреймворками, с которыми вы работаете каждый день, но, на мой взгляд, фрейм, который вы должны использовать, думая о веб-компонентах, должен быть больше похож на «замену div и span», а не на «замену React». или угловой». Чтобы помочь вам понять эту перспективу, я предлагаю вам следующее упражнение — потратьте некоторое время на создание такого сырого «веб-компонента» и со временем вносите улучшения в различные его части. Для механизма рендеринга начните с привязки строк к свойству innerHTML, затем перейдите к тегу шаблона, а затем введите динамические шаблоны с помощью lit-html. Для привязки данных начните с наблюдения за атрибутами и свойствами, затем перерисуйте все вручную в установщиках свойств, а затем извлеките эту общую логику наблюдаемого свойства в декоратор. Делая все это, вы можете заметить, сколько у вас есть способов реализовать одно и то же (но лучше), заставляя вас чувствовать, что вы работаете с внутренними компонентами фреймворка, а не с самим фреймворком. Когда дело доходит до API, которые легче продать вашей команде, я бы посоветовал проверить такие решения, как stencil или lit-element.

В: В чем разница между необработанными веб-компонентами и такими инструментами, как Stencil или lit-element?

Самое главное отличие сырых веб-компонентов от всевозможных фабрик веб-компонентов заключается в причудливом названии Опыт разработчика — общая сумма ощущений, с которыми вы сталкиваетесь при работе с веб-компонентами и их распространении ;) Например, в Stencil вы можете писать свои компоненты с помощью TypeScript. Вы готовы распространять компоненты в виде пакетов npm через так называемые коллекции. Вы готовы разместить свои компоненты перед IE11, потому что Stencil предоставляет вам управление полифилами. Вы можете лениво загружать свои компоненты и разбивать окончательный пакет на куски, а также можете использовать JSX для создания шаблонов ваших компонентов. Кроме того, вы можете сэкономить некоторое время, используя декораторы Stencil, такие как @Component, @Prop или @State, чтобы избавиться от дублированной логики, не совсем связанной с бизнес-кейсом, который вы пытаетесь решить (под логикой я подразумеваю такие вещи, как регистрация ваших пользовательских элементов в реестре, реакция на изменения свойств и атрибутов и повторный рендеринг всего при обновлении состояния). Тем не менее, самая важная часть Stencil (или решений, подобных Stencil) — это возможность создавать собственные пользовательские элементы, которые могут взаимодействовать с большинством фреймворков, о которых вы только можете подумать.

В: Я знаю, что такие инструменты, как Stencil или lit-element, улучшают DX веб-компонентов, но разве это не то же самое, что использование еще одного фреймворка? Есть ли разница между этими двумя подходами?

Давайте подумаем о случае, когда поставщик (Stencil, React, Angular и т. д.), стоящий за компонентом, который вы создали некоторое время назад, начинает выглядеть как устаревший. Люди перешли на другой инструмент или его поддержка была приостановлена. Рассмотрим два возможных сценария. Во-первых, когда есть компонент, который работает только в определенной среде выполнения (а у большинства фреймворков есть свои очень специфические среды выполнения), это в основном все, что касается совместимости. Очень мало шансов, что «следующая большая вещь» захочет поговорить с компонентом, созданным с использованием Angular, React или Vue. Они, вероятно, представят свои собственные среды выполнения, которые могут быть несовместимы с вашим компонентом, поэтому передача данных в них станет невозможной. Теперь подумайте о сценарии, когда вместо создания специфичных для фреймворка компонентов ваша кодовая база полна пользовательских элементов, которые отвечают этим двум требованиям — вы можете привязывать данные к их свойствам так же, как вы делаете это с обычными элементами DOM, и они *реагируют* к изменениям связанных данных, и вы также можете подписаться на события, которые они генерируют, с помощью собственного метода «addEventListener».

Первый сценарий — это когда вы используете фреймворки, которые очень часто несовместимы друг с другом. Второй сценарий — когда вы переходите на веб-компоненты, что гарантирует, что компоненты, которые вы производите, имеют гораздо более длительный срок годности. Отвечая на исходный вопрос — да, с точки зрения API это действительно зависит от ваших предпочтений, однако с точки зрения результата вашей работы разница действительно значительна.

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

Если присмотреться, оказывается, что внутри таких библиотек, как redux или mobX, нет ни React, ни Angular. Вы должны думать о них как об обычных модулях JavaScript, которые можно комбинировать с различными компонентами, содержащимися в вашем приложении (да, также с веб-компонентами), а не как об инструментах, адаптированных для какой-либо конкретной платформы. Пока ваш компонент может подписываться на изменения внутри данного хранилища или контейнера состояния, все должно работать нормально. Чтобы лучше понять это, вы можете создать свой собственный магазин или любой pub/sub контейнер в виде ванильного JS-модуля, выставить его глобально и вызвать его методы изнутри пользовательского элемента, который вы создаете. Тогда вы всего в одном шаге от замены ее вашей любимой библиотекой управления состоянием, и ничего не изменится. В более широком контексте это все еще правильный ответ на другие вопросы, такие как «Как я могу … с веб-компонентами» — если отношения между различными частями вашей кодовой базы на стороне клиента настроены правильно и нет требований к какой-либо конкретной среде выполнения. предоставленный фреймворком, все будет работать.

—

Чтобы увидеть слайды из моего недавнего доклада о веб-компонентах, нажмите здесь — ваши отзывы более чем приветствуются!