Тред о применении кастомных элементов в 2020. С момента релиза Firefox 63 прошло почти два года, в Safari поддержка появилась еще раньше. Так что уже можно делать некоторые выводы.
На сегодняшний день кастомные элементы используют Adobe, Apple, Esri, GitHub, Firefox, IBM, ING, Internet Archive, Microsoft, Nintendo, Oracle, Red Hat, Salesforce, SAP, Tencent, Tesla, VMWare.
По данным Chrome Platform Status, уровень использования достигает 10% показов страниц. Их методика подсчета и провалы на графике вызывают вопросы, но другой такой статистики я не встречал.
chromestatus.com/metrics/featur…
Причина роста популярности — у ряда крупных компаний есть запрос на framework-agnostic. Типичный юзкейс: библиотека компонентов, используемая в проектах на разных фреймворках.
На самом деле, от фреймворков поддержка кастомных элементов требует определенных усилий. Набор тестов на совместимость можно найти на сайте Custom Elements Everywhere.
custom-elements-everywhere.com
Обращаю внимание на то, что с React все не так просто. Есть надежда, что полная совместимость появится в React 18.
github.com/facebook/react…
Возможно, поэтому некоторые компании поддерживают две реализации своей дизайн-системы — на React и на кастомных элементах: Spectrum от Adobe, Carbon от IBM, PatternFly от RedHat.
Для разработки в энтерпрайзе кастомные элементы привлекательны возможностью постепенно модернизировать существующий стек технологий, избегая внешних зависимостей и vendor lock-in.
При этом стек может быть любым: свой фреймворк (LWC от Salesforce, UI5 от SAP, FAST от Microsoft), набор библиотек вроде jQuery и Knockout (Oracle JET), библиотека компонентов (Sencha ExtWebComponents).
В Vaadin мы используем кастомные элементы как фундамент для Java-фреймворка, предыдущая версия которого была основана на GWT. Публичные API во многом удалось сохранить.
Все вышеперечисленное — примеры использования кастомных элементов для создания компонентов интерфейса. Это наиболее частый случай их применения, но не единственный.
Интересный сценарий — инкрементальная миграция с помощью кастомных элементов. Этот подход описал Денис Мишунов в докладе "Я создал Франкенштейна" и статье в двух частях.
smashingmagazine.com/2019/09/franke…
Особенность “франкенштейн-миграции” в том, что кастомные элементы и Shadow DOM в данном случае — средство, а не цель. Если для проекта такой вариант оптимален, почему бы и нет?
К похожим юзкейсам я бы отнес микрофронтенды. Кастомные элементы упоминаются как один из элементов концепции, которую сформулировал Michael Geers на сайте micro-frontends.org
Раньше точечному использованию веб-компонентов в проектах на другом стеке мешали проблемы с производительностью полифиллов. Нативная реализация делает такие сценарии возможными.
Встраиваемые виджеты могли бы не засорять страницу своей разметкой, пряча ее за HTML-тегом. Также им пригодилась бы изоляция Shadow DOM, о котором мы еще поговорим.
Но вообще использовать Shadow DOM вместе с кастомными элементами не обязательно. Это независимые части стандарта, напрямую никак не связанные между собой.
Разработчики GitHub следуют идее прогрессивного улучшения и используют кастомные элементы без Shadow DOM. Об этом они рассказали в известной статье о выпиливании jQuery.
github.blog/2018-09-06-rem…
Кастомные элементы GitHub (в частности, меню и модальный диалог) сохраняют часть функций при выключенном JavaScript благодаря использованию стандартного элемента <details>.
github.com/github/details…
Но этот пример — исключение. Чаще кастомные элементы используют там, где о выключенном JS не заботятся. Это админки, дашборды, корпоративные порталы с формочками и табличками.
Среди примеров могу назвать инструменты для CMS от проекта HAX (редакторы для Drupal и Wordpress) и Joomla UI custom elements (частично на них построен интерфейс админки Joomla 4).
В концепцию генераторов статики кастомные элементы тоже вписываются (они же сами — часть HTML). Чаще других в этом смысле упоминают 11ty. Вот, например, статья от авторов web.dev.
web.dev/how-we-build-w…
Есть еще одна область, в которой потенциал кастомных элементов, на мой взгляд, далеко не раскрыт. Я имею в виду альтернативу jQuery-плагинам для небольших сайтов вроде лендингов.
Плагины вроде Swiper обычно требуют HTML с определенными классами или атрибутами. Кастомный элемент с Shadow DOM мог бы помочь сделать код чище, а API — более унифицированным.
Напоследок упомяну еще и про такой феномен, как “HTML framework” (термин предложил Paul Bakaus из команды AMP). Пример подобного набора примитивов — Numl от @tenphi.
github.com/numldesign/numl