Еще раз о веб-компонентах…

Каждый раз, когда в какой-либо статье, либо в комментариях, упоминается группа стандартов Web Components, происходит практически одно и то-же: люди, которые, зачастую, весьма слабо представляют о чем идет речь, начинают делиться «экспертными» мнениями. Каждый раз обсуждения скатываются к одному и тому-же накатанному сценарию, название которого рифмуется со словом «грач». А мне очень хотелось бы позитива, конструктива и перехода к вопросам практического применения. В данной статье, я попытаюсь разом ответить на подавляющее большинство типичных вопросов и опровергнуть максимум общих заблуждений. Впоследствии, в тяжелой ситуации, можно будет отбиться одной ссылкой. Итак, поехали.

Основы

Веб-компоненты — это набор современных спецификаций, состоящий из следующих основных элементов:

Custom Elements ^[1] — нативная возможность создавать свои собственные HTML-теги, с заданным поведением, внешним видом и собственной внутренней разметкой.

Shadow DOM ^[2] — разделение внутренней структуры компонента с инкапсуляцией внутренних стилей и остального тела документа.

Template ^[3] — специальный тег, позволяющий хранить куски разметки, применять их и многократно использовать при необходимости.

HTML Imports ^[4] — возможность импорта блоков HTML, хранящихся в других HTML-файлах

Блюдо из всего вышеперечисленного можно приправить нативными CSS-переменными, нативными ES-модулями и серверным пушем HTTP/2. Еще есть слоты, кастомные атрибуты, кастомные события и прочие детали. О них немного позже, когда перейдем к практике.

Да эти ваши веб-компоненты почти нигде не поддерживаются

Сухие цифры — лучшие друзья инженера. Давайте с этого ракурса посмотрим на «почти нигде»:

Custom Elements ^[5] — 78.71%
Shadow DOM ^[6] — 79.12%
Template ^[7] — 89.61%
HTML Imports ^[8] — 69.16%

Как мы видим, вышеуказанные технологии работают в браузерах у подавляющего большинства пользователей. Картину немного портят HTML-импорты, но использовать полный набор мы не обязаны (я предпочитаю нативные ES-модули для разбития на удобные блоки всего и вся), даже по отдельности в этом списке можно найти для себя много «вкусного».

Очень рекомендую не доверять мне слепо, а сходить по приведенным ссылкам. Там вы, например, сможете увидеть текущий статус для данных спецификаций и то, что Custom Elements и Shadow DOM получили полную поддержку в Firefox, начиная с версии 63. Когда основная масса пользователей лисы обновится до этой версии, а этот момент не за горами, общие цифры станут еще немного привлекательнее. Также, вы могли обратить внимание на «неполную поддержку» Custom Elements и Shadow DOM в Safari. Яблочный браузер не даст вам унаследовать ваш компонент от встроенного нативного браузерного элемента, типа кнопки, селекта и тому подобного. Еще в Safari есть небольшие нюансы в CSS-селекторах при использовании Shadow DOM. На практике, с этим вполне можно жить и не тужить. Видимо, по традиции, аутсайдером среди современных браузеров является Microsoft Edge. Разработчики утверждают, что поддержка реализуется. Ждем.

Хорошо, а что делать с остальными ~20% пользователей?

Для поддержки этих ребят можно использовать полифилы ^[9]. Да, с полифилами работать будет немного медленнее, но невооруженным глазом это не заметно. Зато у всех остальных будет — быстрее.

Пытались лет пять назад делать проект на Polymer. Все ужасно тормозило.

В те «далекие» времена, бушевал черновик стандарта (v0), поддержка которого была реализована только в Chrome. С тех пор многое изменилось: была принята новая версия стандарта — v1, нативная поддержка была реализована в различных браузерах, полифилы были переписаны, хорошие практики прошли путь устаканивания. Сам Polymer из технологического превью превратился во вполне рабочее решение, с которым приятно иметь дело.

Полимеры какие-то… Что это вообще?

Polymer ^[10] — это библиотека для создания веб-компонентов. Она реализует поддержку всего того «сахара», к которому мы так привыкли при работе с популярными фронтенд-фреймворками: динамические привязки данных (bindings), репитеры для работы с массивами и т. д. На данный момент, вышла уже 3-я стабильная версия этой библиотеки. Разработка ведется при активном участии разработчиков Chrome. Экосистема поддерживается компанией Google. Совокупная длинна бород разработчиков составляет...

Когда стоит использовать веб-компоненты?

Если вам нужна универсальная общая библиотека UI-компонентов. Случай из жизни: проект, в котором основное приложение написано на React, а бэкофис — на Angular. И хочется одинаковости и всяческого переиспользования кодовой базы. А веб-компоненты замечательно себя чувствуют в разных экосистемах ^[11].

Если вам близок подход «дизайн в браузере». Вы сможете творить без постоянных пересборок приложения и без лишних зависимостей. Это делает прототипирование весьма приятным занятием и позволяет вашему приложению плавно эволюционировать от состояния прототипа до состояния production-версии. Люблю такое.

Если вы любите старое-доброе ООП: создаете класс наследованием от HTML-елемента, реализуете в нем желаемые фишки и плюшки общего плана, а потом наследуете от него классы для специализированных компонентов. И вот у вас получился свой собственный микрофреймворк. Красота!

Если вы ненавидите БЭМ: Shadow DOM изолирует стили компонента. Нет необходимости ни в многоэтажных монструозных именованиях, ни в обеспечении навигации к декларациям в общей куче CSS. Все компактно упаковано в компоненте: стили, разметка, логика.

Если вы разрабатываете приложения на основе Electron. Текущая версия Chromium в Electron уже поддерживает все необходимое. Не смотря на общий лаг в версиях.

Если вы хотите написать свой фреймворк/библиотеку. Веб-компоненты — это отличная композиционная основа для подобных экспериментов.

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

Если ваши пользователи используют современные браузеры. Само-собой.

Если вы разрабатываете PWA: основные мобильные платформы поддерживают все «из коробки». Для быстрого старта есть pwa-starter-kit ^[12].

Если вы заинтересованы в повышенной безопасности приложения а детальный аудит зависимостей для вас непомерно дорог. Тут все просто: меньше зависимостей — меньше неподконтрольных дыр.

Если вы маньяк-оптимизатор и любите работать с DOM API: веб-компоненты — это часть DOM API, со всеми стандартными возможностями обычных DOM-элементов.

Если вы обжигались о поломку обратной совместимости версий библиотек: когда все основано на хардкорном стандарте — оно как-то надежнее.

Когда вам НЕ стоит использовать веб-компоненты

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

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

Когда вы имеете дело, преимущественно, с легаси-кодом.

Когда вы и ваши коллеги используете только что-то модное и ничего другого знать не хотите.

Зачем мне все это? У меня есть React/Vue/Angular/etc, мне хватает...

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

Автор: i360u

Источник ^[13]