Вебкомпоненты: 4 года спустя SECON'2017. Доклад

• анонс
• материалы конференции
• тезисы
• презентация
• видео: YouTube, Vimeo
• статья

Web Components

Shadow DOM, Custom Elements, HTML Templates, HTML Imports

Вебкомпоненты:

• предоставляют нативные (браузерные) средства разработки пользовательских компонент
• cодержат средства описания шаблона, стилей и логики компонента, а также механизм их инкапсуляции в единую независимую сущность.

Пилотные варианты спецификаций W3C Web Components: были реализованы 4 года назад в Google Chrome

За это время произошли глобальные изменения в архитектуре веб-приложений:

• устарела концепция “веб-сайт”
  (веб-приложение с серверным рендерингом страниц, где фронтенд-технологии применялись для интерфейсных улучшений)
• на смену ей пришла концепция “spa-приложение”,
  в которой произошло разделение на бекенд и фронтенд, которые взаимодействуют через API

Для построения фронтенда как независимой архитектурной части web-приложения стало необходимо применять общепринятые архитектурные принципы и решения:

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

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

• системы сборки (Grunt/Gulp/Webpack)
• транспайлеры (Babel/TypeScript)
• css-препроцессоры (LESS/SASS/SCSS/PostCSS)
• библиотеки CSS-in-JS
• высокопроизводительные js-фреймворки (Angular/React/Ember),
  предоставляющие свои реализации архитектурных решений

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

Какое место претендуют занять вебкомпоненты в современном стеке фронтенд-технологий? Зачем и как применять вебкомпоненты в jquery/angular/react/<ваш_фреймворк>-приложениях?

Web Components: развитие

Развитие фронтенд-тулинга форсировало прогресс браузерных технологий.
Ускорилась разработка w3c/ecmascript-стандартов и их имплементация в браузерах.
Стек стандартов Web Components тоже не остался без внимания.

За прошедшие 4 года с момента экспериментальной реализации стека Web Components в Google Chrome:

• вышли новые версии спецификаций Shadow DOM v1 и Custom Elements v1
• HTML Templates были реализованы во всех основных браузерах, кроме IE
• вышел Polymer v.2

Shadow DOM: v.0 vs v.1

Наибольшие изменения претерпела спецификация Shadow DOM

• создание shadow root
  v.0: element.createShadowRoot()
v.1: element.attachShadow({ mode: ... })

• поддержка множественных shadow root
  v.0: поддерживается
  v.1: не поддерживается

• closed shadow root
  v.0: не поддерживается, shadow root постоянно доступен извне: e.shadowRoot
v.1: режим задается: element.attachShadow({ mode: 'open' || 'closed' })
  работа геттеров e.shadowRoot, e.assignedSlot зависит от режима

• shadow host
  v.0: любой элемент может стать shadow host
  v.1: список элементов регламентирован

• механизм распределения контента - позиции отображения контента из другого дерева:
  v.0: Insertion points
  v.1: Slots

Custom Elements v.0 vs v.1

• появление в браузерах поддержки es6 классов позволяет описывать пользовательский элемент v0 и v1 в виде класса:
  class MyElementClass extends HTMLElement {}

• регистрация элемента
  v.0: window.document.registerElement('my-element', MyElementClass)
v.1: window.customElements.define('my-element', MyElementClass)

• промис момента регистрации элемента
  v.1: customElements.whenDefined('my-element')

• определение конструктора класса элемента по его имени:
  v.1: customElements.get('my-element')

• жизненный цикл элемента:

Сизифов труд

Вопрос: Кто делал свою реализацию дроп-дауна на:

• vanila-js
• JQuery
• NockoutJS
• AngularJS
• ReactJS
• Angular2

Не пора ли остановиться?

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

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

Один UI-фреймворк всеже есть и его использует каждый из нас.
Вопрос: Какой это фреймворк?

Это нативные UI-компоненты браузера.

Нативные UI-компоненты браузера

<button />
<input type="text"/>
<input type="checkbox" />
<input type="radio" />
<textarea />
<select />
<video />
...

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

Вопрос: Что под капотом этого “фреймворка”?

Если открыть отладчик, включить Show user agent shadow DOM и проинспектировать стандартные компоненты браузера

• вы увидете что скрыто “под капотом”.

Да, это вебкомпоненты.

Почему эти компоненты работают везде? — реализованы на более низком уровне, чем js-фреймворк
— используется Shadow DOM для изоляции собственного DOM-дерева и его стилей
— компонент предоставляет js-api и api атрибутов для взаимодействия с внешней средой

Имплементация стека стандартов Web Components предоставляет стандартное api, позволяющее использовать эти “низкоуровневые” инструменты для создания собственных компонент.

Web Components vs JS-framework

Сравнения по функционалу Web Components vs JS-framework корректны в той же степени, что и сравнение колеса с автомобилем - тема одна и таже, на этом сходства заканчиваются.

Относительно современных js-фреймворков по функционалу вебкомпоненты наиболее близки к ReactJS:

• “из коробки” не содержат механизмов, типичных для application-фреймворков (фреймворков уровня приложения), таких как Angular, Ember: роутинги, контроллеры, модели, хранилища состояния, …
• предоставляют лишь инструменты для создания компонент, не более того

Основное назначение application-фреймворка:
— предоставить средства создания инфраструктуры приложения.

Назначение вебкомпонентов:
— предоставить средства создания компонент.

Не пора ли начать использовать инструменты по их прямому назначению?