За последние пару лет вокруг веб-компонентов возникло много шума. Было сказано, что они изменят то, как мы создаем для Интернета - почему это делает веб-компоненты такими важными?

Веб-компонент - это стандартизированный способ создания инкапсулированных многоразовых элементов пользовательского интерфейса для Интернета.

Не новая концепция

Компоненты для Интернета существуют уже давно, в идее возможности писать многоразовый и переносимый код нет ничего нового.

Плагины jQuery

Плагины jQuery, вероятно, были первой популярной попыткой написания повторно используемых сегментов кода. У них была некоторая структура того, как они были написаны, и вы могли легко их распространять, но с ними не было проблем.

Вы часто сталкиваетесь с конфликтами между различными плагинами, и у вас также будет много проблем со стилем, когда вы пытаетесь выяснить, какие стили вам нужно было добавить по отдельности.

Директивы AngularJS

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

Компоненты платформы

Самой последней версией этой концепции будут современные компоненты фреймворка, которые можно найти в Angular 2 и React. Они построены на современных функциях JavaScript, таких как классы, обеспечивающие гораздо более удобный API. Компоненты Angular 2 позволяют разработчикам украшать свои компоненты метаданными, чтобы помочь инструментам понять, как другой разработчик должен взаимодействовать с этими компонентами. Вы также можете использовать Shadow DOM, который, наконец, обеспечивает полную инкапсуляцию для ваших компонентов.

Зачем вообще компоненты?

Прежде чем мы сможем понять, почему веб-компоненты так важны, мы сначала должны полностью понять, какова цель любого типа компонента.

Инкапсуляция

Компонент должен быть полностью отделен от основного приложения. Это увеличивает возможность повторного использования, тестируемость и надежность, поскольку компонент отвечает только за свои внутренние компоненты и не должен заботиться о состоянии приложения, а только о своем собственном.

И автор компонента, и пользователь могут обновить компонент, не опасаясь, что это повлияет на остальную часть приложения.

Расширяемость

Компоненты должны иметь возможность расширять друг друга, а в случае веб-компонентов - другие элементы DOM. Это означает, что автору компонента не нужно изобретать велосипед, и он может легко повторно использовать функциональные возможности.

Возможность комбинирования

Должна быть возможность создавать более сложные компоненты или даже целые приложения из набора компонентов. Это снижает потребность в «глобальной» логике, обеспечивая более определенную архитектуру и меньшую вероятность ошибок, поскольку каждая отдельная часть приложения (или составной компонент) лучше определена.

Возможность повторного использования

Большая. Со всем вышеперечисленным компонент должен легко использоваться повторно с минимальными зависимостями и четко определенным API.

Глядя на три типа компонентов, которые мы только что упомянули, единственный тип, который дает нам все вышеперечисленное, - это компоненты фреймворка. И это только в том случае, если вы используете Shadow DOM для полной инкапсуляции.

Shadow DOM, наконец, дает нам полную инкапсуляцию через дерево sub-DOM, на которое не влияют внешние стили. Это означает, что как автор компонента вы имеете полный контроль над тем, как выглядит ваш компонент, а также над тем, как пользователь может управлять вашим компонентом.

К счастью, вы можете использовать Shadow DOM с компонентами Angular и React.

Почему веб-компоненты?

Если компоненты фреймворка дают нам все вышеперечисленное, зачем нам веб-компоненты? Одна важная причина: Совместимость.

Компоненты фреймворка хороши, но они хороши только в пределах своей собственной экосистемы. Вы не можете (легко) использовать компонент Angular в React или наоборот.

Почему это важно?

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

Как разработчики, мы должны изменить способ создания наших приложений, чтобы быть в курсе последних событий и внедрять новейшие технологии, когда они соответствуют требованиям нашего бизнеса / пользователей. В прошлом вы, вероятно, были привязаны к определенному набору технологий с очень сложным путем обновления, что могло даже означать переписывание приложения.

Поскольку веб-компоненты созданы на основе не более чем веб-стандартов, они будут работать во всех этих экосистемах, это дает огромные преимущества:

  • Взаимодействие - ваши компоненты могут выходить за рамки фреймворков и использоваться в нескольких проектах с разными технологическими стеками.
  • Срок службы - поскольку ваши компоненты совместимы, они будут иметь более длительный срок службы, и будет меньше необходимости их переписывать, чтобы они соответствовали новым технологиям.
  • Переносимость - ваши компоненты могут работать где угодно с минимальными зависимостями или без них, барьер для использования значительно ниже, чем если бы ваш компонент полагался на библиотеку или фреймворк.

Наряду со всеми преимуществами, к которым должен стремиться компонент, веб-компоненты имеют пониженную перекрестную совместимость, что будет иметь жизненно важное значение для продвижения вперед в постоянно меняющемся веб-ландшафте.

Библиотеки веб-компонентов

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

Из-за этого было создано несколько библиотек веб-компонентов, чтобы упростить использование веб-компонентов, самыми популярными из которых являются Polymer, X-Tag и Bosonic. Все они предоставляют набор компонентов, которые можно использовать и расширять. Как и в случае любого популярного проекта, за ним стоит множество документации, примеров и сплоченное сообщество.

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

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

Заключение

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

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

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

Найдите меня @RevillWeb, если хотите связаться.