Web components что это за программа? cloud-script.ru

Web components что это за программа?

Сила и мощь веб-компонентов

    Переводы, 12 марта 2019 в 14:22

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

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

HTML5 добавил несколько новых элементов типа и , которые позволили внедрить в веб-платформу некоторые востребованные виджеты общего назначения. Тем не менее, добавление в стандарт нового элемента для каждого достаточно распространённого UI-паттерна не выглядит подходящим вариантом.

15–16 февраля, Москва, беcплатно

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

Развитие стандартов

Упомянутый набор стандартов известен как веб-компоненты. Ранние версии стандартов в той или иной форме доступны в Chrome ещё с 2014, а полифиллы неуклюже заполняют пробелы в других браузерах.

Не так давно стандарты были усовершенствованы. Первоначальная версия теперь называется нулевой — v0, а для более зрелой первой версии виднеется поддержка во всех основных браузерах. В Firefox 63 добавлена поддержка двух стандартов из требуемых — Custom Elements и Shadow DOM — так что пора узнать, как можно стать HTML-изобретателем!

Разговоры о веб-компонентах идут давно, и существует множество доступных материалов по ним. Статью следует рассматривать как вводную по новым возможностям и ресурсам. Если вы хотите окунуться в тему глубже (а это определённо следует сделать), то можно почитать о веб-компонентах на MDN Web Docs и Google Developers.

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

Новый взгляд на элемент

Первый элемент не так нов, как остальные, поскольку потребность в нём возникла раньше идеи веб-компонентов. Иногда нужно просто где-нибудь хранить готовый HTML: может, это некоторая разметка, которую вы повторяете в нескольких местах, или же пока не законченный UI. Элемент содержит HTML-код, парсинг которого происходит без вставок в текущий документ.

Но куда вставляется разобранный HTML, если не в документ? Он добавляется в DocumentFragment — легковесную обёртку для хранения фрагмента HTML-документа, которая «растворяется» при вставке в DOM. Эти обёртки полезны для хранения набора элементов, требуемых позже, и выступают в роли контейнера, которым не нужно управлять вручную.

Теперь у нас есть DOM в неком «исчезающем» контейнере, а как им пользоваться?

Оказывается, можно просто вставить фрагмент в текущий документ:

Этот код работает прекрасно за тем исключением, что вы только что удалили контейнер. Если вы запустите код ещё раз, то получите ошибку, так как template.content исчез. Вместо этого сделайте копию фрагмента перед вставкой:

Название метода cloneNode говорит само за себя, но обратите внимание, что он принимает флаг для указания необходимости глубокого копирования.

Тег template подходит в любой ситуации, когда требуется повторять некоторую HTML-структуру. Он особенно полезен для задания внутренней структуры компонента, и потому входит в «клуб» веб-компонентов.

Новые возможности:

  • Элемент, который хранит HTML-код, но не добавляет его в текущий документ.

Обзорные материалы:

  • DocumentFragment
  • Дублирование узлов DOM с помощью cloneNode

Пользовательские элементы (Custom Elements)

Пользовательские элементы — флагман технологии веб-компонентов. Название говорящее — они позволяют разработчикам создать свои собственные HTML-элементы. Синтаксис версии v0 был громоздким, но сейчас пользовательские элементы в основном опираются на классы ES6. Если вы с ними знакомы, то знаете, как описать новый класс на базе существующего (наследование):

А что, если мы сделаем так?

До недавнего времени это считалось ошибкой. Браузеры запрещали наследовать как встроенный класс HTMLElement , так и любой из его потомков. Custom Elements снимают данное ограничение.

Браузер знает, что тегу

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

Для страницы теперь каждый тег ассоциирован с новым экземпляром класса MyElement . То есть конструктор класса MyElement будет вызван всякий раз, когда браузер встретит тег .

Но зачем в имени тега нужен дефис? Органы стандартизации хотят сохранить себе возможность вводить новые HTML-элементы, так что разработчики не могут просто так начать определять свои теги или . Во избежание в будущем конфликтов все пользовательские элементы должны содержать дефис, а органы стандартизации обещают никогда не вводить новые HTML-теги с этим символом. Проблема решена!

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

  • connectedCallback вызывается при добавлении элемента в документ (в общем случае несколько раз, так как элемент может быть перемещён или удалён и заново добавлен);
  • disconnectedCallback — в противоположность connectedCallback ;
  • attributeChangeCallback срабатывает при модификации атрибутов из специального списка.

Немного более выразительный пример:

Использование элемента на странице выглядит так:

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

Также необходимо указать в Registry, что мы расширяем существующий тег:

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

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

С этого момента уже можно применять традиционные техники веб-виджетов. Можно установить ряд обработчиков событий, стилизовать элемент и даже повторять его внутреннюю структуру через . Люди могут комбинировать ваш пользовательский элемент с их собственным кодом: через HTML-шаблонизацию, работу с DOM и даже в новомодных фреймворках, некоторые из которых поддерживают пользовательские теги в своих реализациях виртуального DOM. Пользовательские элементы используют стандартные интерфейсы, поэтому они позволяют реализовать действительно переносимые виджеты.

Новые возможности:

  • Наследование встроенного класса HTMLElement и его подклассов.
  • Registry пользовательских элементов и customElements.define() для работы с ним.
  • Специальные методы жизненного цикла для реагирования на создание элемента, вставку в DOM, изменений атрибутов и так далее.

Обзорные материалы:

  • ES6 Classes, в частности, наследование и ключевое слово extends

Теневая модель документа (Shadow DOM)

Мы сделали свой «дружелюбный» элемент и даже накинули немного стилизации. Теперь мы хотим использовать его на всех своих сайтах и делиться кодом с другими. Как предотвратить кошмар конфликтов, когда наш кастомизированный элемент столкнётся лицом к лицу с CSS других сайтов? Решение предоставляет Shadow DOM (теневой DOM).

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

Содержимое теневого корня стилизуется через добавление к нему (или
):

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

Что, если пользовательский элемент имеет нетеневой контент? Мы можем заставить их работать вместе, используя новый специальный элемент :

Если этот template будет прикреплен к теневому корню, то следующая разметка:

Будет отображена так:

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

Новые возможности:

  • Как бы «невидимая» DOM-структура, которая называется теневым корнем.
  • DOM APIs для создания теневых корней и доступа к ним.
  • Ограничение области видимости внутренних стилей теневого корня.
  • Новые псевдоклассы CSS для работы с теневыми корнями и их стилями.
  • Элемент

Собираем всё вместе

Давайте сделаем модную кнопку! Будем креативны и назовём элемент . Что именно сделает кнопку модной? У неё будут кастомные стили, которые позволят нам установить иконку и настроить внешний вид. Хотелось бы, чтобы вид кнопки сохранялся вне зависимости от сайта, на котором она используется, так что мы собираемся инкапсулировать стили в теневом корне.

Вы можете увидеть законченный пользовательский элемент в интерактивном примере. Обязательно посмотрите как на JS-код, так и на в HTML, который нужен для определения стиля и структуры элемента.

Заключение

Стандарты веб-компонентов основаны на той идее, что имея множество низкоуровневых средств, люди будут комбинировать их способами, которые никто не предвидел во время написания спецификаций. Пользовательские элементы уже были использованы для упрощения создания VR-контента в вебе, породили несколько UI-тулкитов и многое другое. Несмотря на длительный процесс стандартизации, обещанные возможности веб-компонентов придают разработчикам больше сил. Теперь, когда технология доступна в браузерах, будущее веб-компонентов в ваших руках. Что вы построите?

Веб-компоненты: что это такое и как они работают

Код, который можно повторно использовать в разных проектах, является основой современного веб-дизайна. Использование различных фронтенд-фреймворков и Sass-библиотек существенно ускоряет рабочий процесс и позволяет быстро найти решение практически любой проблемы. Однако многоразовые динамические элементы все еще находятся в стадии разработки и остается только догадываться, какое влияние они окажут на веб-дизайн в целом. Эти элементы называются веб-компонентами и их создатели пока ожидают, когда будет завершена спецификация W3C.

Читать еще:  Где смотреть оперативную память ноутбука?

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

Небольшое пояснение

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


Пока функционал находится в стадии тестирования, но W3C примет положительное решение по веб-компонентам в самое ближайшее время. Суть веб-компонентов заключается в идее создания динамических элементов интерфейса без написания JavaScript- кода. Кроме этого веб-компоненты можно собирать в собственные библиотеки. Так, например, если разработчику нужно вставить карту на веб странице, он может добавить специальный тег и карта будет корректно отображаться. Но есть проблема – браузеры. Использование веб-компонентов в современном веб-дизайне возможно только при условии поддержки всего множества технологий, которые были использованы при их создании.

Если говорить кратко, то в основе любого веб-компонента лежат четыре уникальных технологий W3C:

  • Пользовательские элементы, которые нужны для добавления новых HTML элементов в DOM.
  • Shadow DOM – правила о том, как создать уникальный DOM, инкапсулированный в HTML-разметку.
  • Импорт HTML – возможность импортирования HTML-код и повторного использования компонентов на других страницах.
  • Шаблон HTML – инструмент для создания повторно использовануемого кода с пояснениями визуальных характеристик

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

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

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

Что такое Polymer?

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

Polymеr – это одна из немногих WC-библиотек, где поддерживаются рекомендации разработчиков Google Chrome. Так что не приходится сомневаться, что будущее веб-компонентов будет связано именно с этим браузером.

В это можно не верить, но Polymer уже используется в некоторых продуктах Google, таких, к примеру, как Google Sites. Это может показаться странным выбором, поскольку данный фреймворк пока не поддерживается браузером. Вот перечень стабильных браузеров, где осуществляется поддержка все четырех основных технологий W3C.

  • Google Chrome
  • Firefox
  • Edge
  • Safari 7+
  • IE11
  • Mobile Chrome(Android)
  • Mobile Safari(iOS 7+)

Не столь популярные браузеры, такие как Opera, вряд ли смогут поддерживать все. Но вышеприведенный список достаточно полон, чтобы разработчики начали осваивать Polymer и своими глазами увидеть, насколько он полезен в работе. Для расширения кругозора можно изучить следующие материалы (eng):

Polymer против React

Вопрос использования веб-компонентов и Polymer вызывает бурные дискуссии в среде разработчиков. Противники Polymer аргументируют свою позицию тем, что созданная в недрах Facebook библиотека React является наиболее сильной и жизнеспособной альтернативой веб-компонентам. React использует свою собственную Shadow DOM и опирается на свои react-компоненты для быстрого создания интерфейсов. Учитывая, что сейчас многие разработчики изучают React, их позиция вполне понятна. Тем не менее, оба фреймворка преследуют одну и ту же цель – создание многоразовых элементов для динамических веб-сайтов.

Но есть множество причин, по которым веб-компоненты оказываются более полезными. Чтобы научиться работать с React, нужно знать npm, Gulp/Grunt, Babel, возможно JSX и некоторых других веб-технологии. И во всем этом очень непросто разобраться. А идея веб-компонентов как раз и заключается в том, чтобы их использование было максимально простым, особенно в связке с Polymer.

Если разработчику нужно создать небольшой и не особо интерактивный сайт, то сочетание Web Components/Polymer является оптимальным решением.

Будущее веб-компонентов

Теперь пара слов о нативной поддержке интерфейсов и технологий, используемых в веб-компонентах. Как правило, и это не удивительно, больше всего веб-компоненты поддерживает Chrome. Но если разработчик решит освоить Polymer, у него появится возможность создать такой компонент, который будет работать во всех браузерах, включая IE6. И это отличная новость для всех разработчиков интерфейсов, готовых развиваться и работать с новейшими технологиями.

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

SavePearlHarbor

Ещё одна копия хабора

Главное меню

Навигация по записям

Понятно и просто про WEB-компоненты и Polymer

Я — Александр Кашеверов. По образованию — магистр радиофизики. По профессии — веб-разработчик, работаю в компании DataArt с 2011 года, с 2009 увлекаюсь IT и веб-технологиями.

О чем статья, коротко

Рассмотрим, что такое web-components и polymer. Немного поразмышляем на тему развития веба. Посмотрим на технические детали, примеры, поддержку браузерами, тестирование. Коротко, понятно, по делу. С картинками.

Вступление

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

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

Для уменьшения головной боли хорошо бы, если в контексте веб:

  • CSS не пересекался.
  • Области видимости JS не пересекались.
  • HTML был понятным и читаемым, никаких лишних элементов.

В настоящее время это не совсем так. Относительно JavaScript: приходится следить, чтобы он не работал с global scope и разные компоненты случайно не взаимодействовали друг с другом. В CSS нет и не было инкапсуляции, приходится придумывать методологии вроде MCSS и bem, чтобы ничего лишний раз не сломалось. И наконец, в HTML можно увидеть множество лишних элементов на странице, например, даже сейчас в почте gmail…

Запутанно… Не правда ли?
Фреймворки в той или иной степени внедряют компонентизацию и стараются решить эти задачи. Однако, они так же построены на всё тех же HTML, CSS, JavaScript.

Web Components — коротко

Веб медленно, но верно движется к компонентизации — это естественный процесс. Сложное можно упростить, разбив на части. Параллельно развитию фреймворков идет работа и на более низком уровне. Набирают популярность веб-компоненты. Это реализация идеи компонентизации на уровне браузера.

История веб-компонентов началась в 2011 году (первое упоминание на github). Кратко — что это:

  • Custom Elements — создание своих html-элементов, дополнение существующих.
  • Shadow DOM — инкапсуляция логики и стилей.
  • Templates — шаблоны на уровне браузера!
  • HTML imports — вместо подключения отдельно разных файлов [css, js, …] можно подключать один HTML-документ, включающий все остальные файлы.

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

На самом деле, некое подобие веб-компонентов уже было создано давно. Простейший пример — элемент

Так же и с HTML5 элементами или .

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

Наверняка многие подключали в проект Bootstrap — для этого нужно отдельно прописать подгрузку стилей и скриптов. С компонентами это можно было бы сделать проще.

Web Components — не фреймворк. Это набор технологий, реализованных на уровне браузера.

Web Components — поддержка браузерами & polyfills

На данный момент (ноябрь 2015) три из чеырех технологий находятся в стадии «Working Draft» на W3C.
Так выглядит ситуация на данный момент (ноябрь 2015):

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

С их помощью, поддержка браузерами уже получше.

На web-странце, полифиллы подключается стандартно в head (до всех скриптов, которые используют веб-компоненты):

Web Components — ссылки
  • learn.javascript.ru — обучение.
  • w3.org — (eng) спецификация Web Components.
  • css-tricks.com (eng) — обзор.
  • youtube.com — (eng) обзор.
  • webcomponents.org — (eng) обсуждения и лучшие практики.
  • github.com — (eng) polyfills для поддержки старыми браузерами.
  • developer.mozilla.org — (eng) обучение.
  • caniuse.com — (eng) поддержка браузерами.
  • jonrimmer.github.io — (eng) поддержка браузерами.

Тем временем, Google всё упрощает и развивает. Работа началась осенью 2012 года, судя по истории коммитов на github. Они взяли веб-компоненты, полифилы и создали еще одну надстройку.

Цель Polymer — упростить создание качественных веб-приложений (цитата product manager с конференции Google IO).

Читать еще:  Артефакты видеокарты что делать как исправить?
Polymer — коротко

Библиотека представляет собой веб-компоненты в основе, полифилы для поддержки старых браузеров, это всё обернуто в целостную более удобную систему с добавлением сахара.

Сехматически это выглядит так:

Google создал набор готовых компонент и разделил их на логические части:

Невыполненные обещания веб-компонентов

Дисклеймер: в статье я часто говорю о React, но вы можете понимать под ним любую библиотеку на JavaScript: Inferno, Preact, Vue, Snabbdom, Virtual DOM или без него: Elm, Om и другие. Точно так же под Polymer можно иметь в виду Vaadin или X-Tag, или…

Кроме того, прочитайте великолепный ответ Роба Додсона.

Короткая, неполная и часто неточная история веб-компонентов

В 2011 интернет сделал прорыв. Со всеми его фейсбуками, гмейлами, гугл-доками и массой других онлайн-вещиц, которые уже нельзя было называть сайтами. Во всех смыслах это были полноценные приложения — одностраничные веб-приложения, или SPA (Single Page Application). Так просто.

Но их разработчикам приходилось непросто…

Уровень развития веб-интерфейсов в то время подразумевал использование шаблонизаторов, основанных на симбиозе серверной логики или клиентских библиотек: Backbone — для тех, кому повезло больше, jQuery UI или Sencha/ExtJs—если в вас был дух энтерпрайза.

Это было неудобно. Это было негибко. Прототипировать быстро и легко— невозможно. UI-библиотеки накладывали свои ограничения. Список проблем можно продолжить.

Это при том, что в нашем распоряжении был набор всё тех же HTML-элементов:

И вот, в 2011 Алекс Рассел предложил свое видение будущего (акценты в тексте — мои):

Мне кажется, сегодня мы застряли в ловушке расширяемости. Мы зацикливаемся на JavaScript, так как это базовый язык нашей экосистемы. Он один выручает нас, когда CSS и HTML не справляются. И вот мы набиваемся в спасательную шлюпку под названием JavaScript. Мы снова и снова делаем это.

Вчера Брюс указал на случай с пустым как примером того самого патологического желания запихнуть всё в JavaScript. Вы цепляетесь за него, пытаясь с его помощью воссоздать всё, что браузер и сам в общем-то способен сделать: передаете по цепочке скрипта кусок разметки, чтобы в конце концов получить тот же результат, как если бы добавили его сразу в HTML. Но есть причина. Gmail содержит пустой не потому, что он сделан глупо. Он содержит пустой , потому что это одновременно выразительный, надёжный и легко поддерживаемый способ реализовать нужную функциональность. А вы пытаетесь сыграть ва-банк, положить все яйца в одну корзину под названием JavaScript.

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

Это то, от чего выигрывают разработчики. Чем раньше возникнет интерес, тем больше шансов увидеть новинки на рынке и начать их использовать. Тогда все скажут: «да, это классная фича».

Таким образом, мы скованы невысказанной дилеммой между глубоким прагматизмом и стремлением к платоновскому идеалу. Но нам не хватает правильной модели, чтобы осмыслить это.

Чем больше функциональности или поведения [привычных разработчикам и реализованных в браузерах] мы забираем на себя, чем больше мы пытаемся сделать «руками» на JavaScript, тем дальше отходим от той идеи негласной договоренности, на которой держится весь мир.

Мы намерены поддерживать прогресс. На мой взгляд, мы застряли на обсуждении HTML5, и уже хватит.

Дальше он показывает демо и рассказывает о веб-компонентах, под которыми в то время подразумевали три разные вещи: инкапсуляцию CSS, Shadow DOM и веб-компоненты. (Я тоже, в целом, рекомендую его доклад).

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

Революция Facebook

Facebook — это сложно устроенное приложение. Возможно, это не очевидно, но это так. Эти маленькие разбросанные по странице блоки—полноценные компоненты. Они должны реиспользоваться, настраиваться и адаптироваться под разный контекст. Разработка с ними должна строиться буквально так: взять элемент box , вставить его в этом месте на странице, применить какие-то стили и при этом не сломать отображение других элементов.

И это должно работать относительно быстро, так как известно: DOM обновляется медленно. Есть бесчисленное количество статей, объясняющих, что минимальное количество обращений к DOMабсолютная необходимость.

Печально, что innerHTML (признак дурного кода) по скорости работы — на одном уровне или быстрее функций управления DOM.

И что же придумал Facebook? Всё просто: они просто написали собственную реализацию веб-компонентов полностью на JavaScript. C XML-схожим синтаксисом внутри. Его назвали React и показали миру в 2013 году.

Reaсt позволяет следующее:

  • создавать собственные кастомные элементы на основе HTML-подобного синтаксиса;
  • вставлять их в DOM;
  • использовать виртуальный DOM, сводя к минимуму работу напрямую с DOM браузера;
  • имеет всего несколько ограничений по работе с компонентами и внутри них (так как всё в ReactJavaScript, его DSL лишь обертка над небольшим количеством функций).

Не удивительно, что React стремительно завоевал свое место в мире веба. Кто не использовал библиотеку — обязательно говорил о ней. Очень быстро появились похожие и конкурирующие инструменты (Inferno, Preact) или некоторые части для работы с виртуальным DOM (Snabbdom, Virtual DOM и другие).

К 2017 React смог реализовать всё то, что ждали от спецификации веб-компонентов. Он позволяет создавать независимые реиспользуемые компоненты и работает практически во всех поддерживающих JavaScript браузерах (не поддерживается в IE

Так о каких невыполненных обещаниях идёт речь?

Ну, первый провал очевиден: что-то их нигде нет. Обещание «поддерживать прогресс» не выполнено. За шесть лет веб-компоненты породили шесть стандартов. Два из них успели устареть. Только один из основных браузеров вкладывается в поддержку (прости Opera, но ты больше не входишь в их число и к тому же работаешь на основе Chromium).

Другое невыполненное обещание, его сегодня много обсуждают в интернетах — зависимость от сторонних библиотек. И это вынуждает оставить здесь этот излишне длинный кусочек размышлений вслух. Потому, что есть Polymer.

Polymer — это попытка Google создать совместимую с веб-компонентами реализацию:

Откройте возможности веб-компонентов. Polymer — JavaScript-библиотека, которая помогает создавать кастомные реиспользуемые HTML-элементы для быстрых и простых в поддержке приложений.

Polymer демонстрирует главный минус веб-компонентов—DOM.

Разберём следующий код на React:

Перед нами кастомный компонент. Его стили определены в формате JavaScript-объекта. Его дочерние элементы — результат исполнения метода map и, одновременно, ещё один компонент. В данном случае, это

, но могло быть что угодно. Внутри— текущее значение элемента массива.

А как бы выглядел тот же трюк на веб-компонентах? Ну…

Если взять HTML как контрпример для JSX, то ничего не выйдет:

Ну а что с JS API? Помните, я говорил, что веб-компоненты — это DOM?

Код компонента будет неуклонно расти при усложнении каждого элемента. Представьте, мы хотим обернуть text внутри p в span ?

Сделать это на React? Раз плюнуть. Просто добавляем:

А на веб-компонентах:

Ломаем совместимость

Итак, представим, как описанные выше проблемы с самого начала возникли на пути Polymer. Что делать? Ну, можно создать что-то вроде собственного языка: «не-совсем-но-типа-джаваскрипт», чтобы и разметку умел и немного логики. И чтобы в виде строк.

Чтобы разобраться, пройдитесь по data system из Polymer. Здесь я покажу только несколько примеров:

Обратите внимание, [[]] , <<>> , $= и другие — не являются частью спецификации веб-компонентов.

И так далее. А вот моё любимое:

Запятая внутри строки: каждая запятая внутри строки должна обязательно экранироваться символом .

Ну серьёзно

А теперь серьёзно. Едва ли можно сказать, что веб-компоненты реализовали хотя бы часть возлагавшихся на них надежд. Едва ли они смогли ответить на стоявшие перед ними вызовы.

Спецификации зависят от JavaScript:

  • кастомные элементы работают на JS;
  • HTML-шаблоны существует только для обработки скриптом;
  • я вообще не уверен, может ли Shadow DOM работать без JavaScript;
  • и только HTML-импорты не нуждаются в JS.

Веб-компоненты — это DOM, поэтому:

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

Чтобы работать с ограничениями (вроде строчных атрибутов) библиотекам придётся (а куда деваться?) изобретать различные несовместимые друг с другом способы передачи параметров:

    Разве attr$=’<>’ из Polymer лучше или совместимее, чем item-label-path=»name.first» из Vaadin или

Всё это — только часть проблем. Те из них, которые в первую очередь приходят мне в голову. И я не встречал их серьезного обсуждения сообществом.

Команда React и вовсе заявила:

Мы не собираемся использовать веб-компоненты на Facebook. У нас нет планов интегрировать их с React, так как существует большая разница на уровне самих моделей — императивной в веб-компонентах и декларативной в React. В веб-компонентах нет нормального способа идиоматически описать вещи, вроде того, куда идут события. Как вы передадите данные, если все описано строками? Мы рассматриваем их больше как слой, помогающий различным фреймворкам взаимодействовать друг с другом.

Сейчас React позволяет использовать их в качестве конечных узлов дерева компонента, так как любой компонент с именем, начинающимся со строчной буквы, React интерпретирует как DOM-элемент.

Цитирую Пита Ханта:

В веб-компонентах много приятного. Например, возможность кастомизировать . Так что в них много хорошего, однако они не годятся для структурирования приложений. React же нацелен на решение таких задач: создание структуры и управление DOM. Веб-компоненты — продолжение обычного DOM API. Я придерживаюсь такого мнения: эта спека стандартизирует худшие практики.

Все эти вопросы поднимаются крайне редко, если не брать в расчет комментарии к некоторым статьям и обсуждения в Твиттере. Складывается ощущение, будто все согласны, что «веб-компоненты — это славное общедоступное и скорое будущее».

Мир веб-компонентов: разбираемся в трендах

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

Темы для рассмотрения

  • Поддержка браузерами.
  • Совместимость с фреймворками.
  • SSR + SEO/Боты.
  • Стилизация компонентов.
  • Специальные возможности (Accessibility).
  • Версионирование.
  • Загрузка в браузер.
  • Доступные инструменты.
  • Веб-компоненты vs Фреймворки.

Поддержка браузерами

IE 10–11 и Edge (с движком Chakra) находятся вне игры, поскольку они не поддерживают Shadow DOM. Это делает использование веб-компонентов нецелесообразным из-за сложности полифилов.

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

Совместимость с фреймворками

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

  • React/Preact — есть некоторые проблемы с расширенной интеграцией. И вам может понадобиться обернуть ваши веб-компоненты в React-компонент (может быть автоматизировано).
  • Vue.js — работает из коробки.
  • Angular — работает из коробки.

SSR (Рендеринг на стороне сервера) + SEO/Боты

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

Так что же нам тогда делать?

Ответ прост — вы можете жить без SSR для веб-компонентов. Конечно, этот подход имеет некоторые ограничения, но приходится работать с тем, что есть. Давайте посмотрим детальнее.

Чтобы рендерить веб-компоненты только на стороне клиента и не жертвовать SEO/совместимостью с ботами, вам нужно хранить контент в Light DOM и использовать атрибуты ARIA. Рассматривайте свои веб-компоненты как нативные элементы HTML. Вы можете согласиться с тем, что боту не нужно видеть Shadow DOM, например, для элемента , чтобы просмотреть его содержимое. Если компоненты хорошо спроектированы, ботам не нужно развернутое (Shadow + Light) DOM-дерево для получения текстового содержимого.

Давайте рассмотрим разметку компонента «Tab» в качестве примера:

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

Стилизация компонентов

Поскольку в наших компонентах мы используем Shadow DOM для внутренней разметки и слоты для контента, написание CSS поначалу может быть нетривиальной задачей. Давайте рассмотрим основные концепции, которые нужно держать в уме.

Изоляция CSS

Shadow DOM практически полностью изолирует свое содержимое от CSS, включенных на странице. В примере, приведенном выше, тег

(который находится внутри Shadow DOM) имеет текст, окрашенный в зеленый цвет, поскольку CSS свойство «color» было унаследовано.

Как включить CSS в Shadow DOM

В настоящее время самый простой способ включения CSS для веб-компонентов — это встраивание их inline в шаблон веб-компонента. Если вы включите их через тег
, вы увидите FOUC во время загрузки страницы, точно так же, как в примере выше (обратите внимание на текст «I’m Shared CSS»).

Однако это ограничение можно преодолеть, скрыв весь контент Shadow DOM перед загрузкой связанного CSS или добавив внешний CSS-код компонента в код главной страницы (разумеется, в этом случае его следует каким-то образом заскоупить).

Поэтому остается ждать поддержки спецификации Constructable Stylesheets во всех основных браузерах. Это дало бы нам больше контроля над CSS.

Контекстно-зависимые стили

Часто наши компоненты имеют разные стили отображения в зависимости от переданных им аргументов. Классический пример — . Когда вы передаете аргумент «multiple» компоненту «select» — он полностью меняет свой внешний вид. Для достижения аналогичного поведения веб-платформа предлагает псевдокласс :host() (не путайте с :host ).

К сожалению, этот псевдокласс не поддерживается в Safari и iOS, поэтому мы не можем его использовать. В качестве обходного пути мы можем использовать возможности JS для ручного проецирования атрибутов и классов хост-элемента в корневой элемент Shadow DOM, чтобы получить возможность писать обычный CSS.

Стилизация контента внутри слота ( )

Таблицы стилей, которые были добавлены в Shadow DOM, могут также применяться в элементах, находящихся внутри . Для этого у нас есть псевдоэлемент ::slotted() . Однако его поддержка браузерами все еще не идеальна. Посмотрите на приведенный выше пример: Safari не будет правильно обрабатывать селектор ::slotted(p)::before .

В качестве обходного пути мы можем добавить стили, отвечающие за стилизацию содержимого слота прямо на страницу (в Light DOM). Таким образом, следующий селектор ::slotted(p)::before для будет преобразован в my-component p::before . Это, естественно, несколько нарушает концепцию Shadow DOM, однако я не вижу другого пути на текущий момент.

Рекомендации

На этом этапе я бы рекомендовал продолжать (если вы уже это делаете) загружать CSS на страницу отдельным файлом с помощью тега
и включать этот тег в каждое Shadow DOM-дерево. В настоящее время я использую следующий код для этого:

Специальные возможности (Accessibility)

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

К счастью, есть решение, которое позволяет вернуть семантику в ваши веб-компоненты. Для этого вам просто нужно следовать спецификации WAI-AIRA. Так что, если вы уже позаботились о доступности, особых изменений в подходе здесь нет.

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

Чтобы увидеть больше примеров полностью доступных веб-компонентов, вы также можете обратиться к следующим инструкциям от Google.

Версионирование

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

Давайте посмотрим на варианты, которые у нас есть.

Никогда не делайте breaking changes. Это принцип, который используют браузеры. И хотя это возможно сделать, и это может быть даже наилучшим вариантом для начала, очевидно, что данный подход противоречит принципу «fail fast, fail safe» и не способствует инновациям.

Управление версиями на основе тегов. Таким образом, вместо у вас будет для того, чтобы иметь несколько мажорных версий компонента на странице. Поэтому, если для «Фрагмента 1» требуется button@1.1.5 , а для «Фрагмента 2» требуется button@1.2.1 — будет использоваться только button@1.2.1 . И если для «Фрагмента 1» требуется версия 1.1.5, а для «Фрагмента 2» требуется версия 2.0.0 — оба компонента будут зарегистрированы.

Версионирование по скоупу фрагмента. Таким образом, вместо у вас будет .

Загрузка в браузер для микросервисного фронтенда

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

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

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

Доступные инструменты

Библиотеки, которые вы можете использовать для создания своих веб-компонентов (отсортировано по моим предпочтениям сверху вниз):

  • LitElement — написан ребятами из Polymer, Google. На мой взгляд, самый оптимальный выбор.
  • Stencil — компилятор веб-компонентов плюс базовые классы. Создан командой Ionic. Его система сборки не очень совместима в Webpack.
  • SkateJS — крошечная обертка вокруг нативных API, которая позволяет использовать различные библиотеки рендера. Создано Trey Shugart, который подарил нам WC SSR PoC.
  • Svelte 3 — это скорее фреймворк, а не библиотека для упрощения создания веб-компонентов.
  • Riot.js.
  • Slim.js.
  • X-Tag — последняя версия все еще в бете.
  • Smart HTML Elements — платный.

Но, постойте, действительно ли мне нужен какой-то инструмент для комфортного написания веб-компонентов? И простой ответ — нет, вы можете написать их, используя Vanilla JS. И это будет работать для большинства простых компонентов, которые вы будете писать.

Веб-компоненты vs Фреймворки

Если вкратце: они разные. Не пытайтесь заменить веб-компонентами старые добрые фреймворки, такие как Vue.js или React.

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

Другой вариант использования — если вы пишете open source библиотеку UI-компонентов (например, Bootstrap или MDC) и хотите сохранить ее независимой от фреймворка.

Пример Material Design Components в эру до веб-компонентов и с веб-компонентами.

Со временем фреймворки, скорее всего, начнут использовать Custom Elements и Shadow DOM внутри, но я не ожидаю увидеть широкого распространения данного подхода в ближайшие 1-2 года.

Примечания

Если вы видите какие-либо пробелы или ошибки в статье, напишите в комментариях или отправьте мне Данный адрес e-mail защищен от спам-ботов, Вам необходимо включить Javascript для его просмотра. .

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

Ссылка на основную публикацию
Adblock
detector