WEB COMPONENTS

4 года спустя

goo.gl/V1z9WM

анонс • тезисы • презентация • видео • статья

Web Components

Shadow DOM, Custom Elements, HTML Templates, HTML Imports


Возможности:

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


Стек стандартов Web Components разрабатывается 10 лет (с 2008г),
впервые реализован в Google Chrome v.25 (4 года назад)

Web Components


Shadow DOM:
— механизмы объявления и использования независимых Shadow DOM деревьев
— средства инкапсуляции шаблона компонента и его стилей
— реализует изоляцию Shadow DOM деревьев
— связывает в единое целое возможности технологий вебкомпонентов


HTML Templates:
— реализация шаблонов на стороне браузера
— декларирует элемент <template />
— позволяет объявлять фрагменты документа в качестве шаблонов

Web Components


Custom Elements:

  • создание пользовательских компонент (тегов)
  • управление жизненным циклом компонента


HTML Imports:

  • реализует механизм импортов для HTML-документов:
    <link rel="import">
  • сложный, противоречивый стандарт

Прогресс в веб-технологиях

За прошедшие 4 года с момента первой реализации вебкомпонентов в веб-технологиях произошли значительные изменения:

  • архитектура:
    — концепция “веб-сайт” сменилась на “веб-приложение”
    — фронтенд стал независимой архитектурной частью

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

  • создание средств реализации этих принципов и решений:
    — систем сборки, транспайлеров, css-препроцессоров
    — js-фреймворков уровня приложения со своими реализациями архитектурных решений

Все необходимое реализовано и применяется - зачем нужны вебкомпоненты?

Web Components: развитие

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

Появились новые версии спецификаций Shadow DOM v.1 и Custom Elements v.1,
вышел Polymer v.2

Shadow DOM v1
Custom Elements v1
HTML Templates
HTML Imports
Polymer v2

Shadow DOM: v.0 vs v.1

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

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

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

Custom Elements: v.0 vs v.1

  • описание пользовательского элемента v.0 и v.1 в виде класса:
    class ElementClass extends HTMLElement {}

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

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

  Custom Elements v0 Custom Elements v1
создание экземпляра createdCallback constructor
добавление в DOM attachedCallback connectedCallback
изменение атрибутов attributeChangedCallback attributeChangedCallback
добавление в чужой DOM — adoptedCallback
удаление из DOM detachedCallback disconnectedCallback

Сизифов труд

Вопрос:
— Кто делал свою реализацию дроп-дауна на:
vanila-js / JQuery / NockoutJS / AngularJS / ReactJS / Angular2

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

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

Вопрос:
— Какой это фреймворк?

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

<button /> <textarea /> <select /> <video /> <input />


Мы даже не сомневаемся будут ли они работать в любом фреймворке.

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

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

Стандарты Web Components дают возможность:
— использовать эти “низкоуровневые” инструменты
для создания собственных компонент
— создавать компоненты сложной внутренней организации
с прозрачным внешним API

Web Components vs JS-framework


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

Вебкомпоненты по функционалу наиболее близки к ReactJS:

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

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

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

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

JS-фреймворки: проблемы миграции

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

Проблемы накатывают лавиной:
— выбор application-фреймворка подразумевает и выбор ui-фреймворка
— смена фреймворка приводит к замене наработанной базы ui-компонент
— издержки на адаптацию, стилизацию, отладку и тестирование

На практике произошло: purejs ➛ jquery / jquery ➛ AngularJS / jquery ➛ Angular2 ...

Причем заказчик считает что:
— необходимые ui-компоненты можно заимствовать из числа уже реализованных
— задача сводится к тривиальной стилизации
— доводы о трудозатратах на разработку не убедительны

От пректа к проекту, процесс разработки ui-библиотеки повторяется.

Web Components или JS-framework?

Вебкомпоненты по своей сути можно использовать с любым js-фреймворком уровня приложения и ui-фреймворком:

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

  • фреймворки используют virtual DOM, реализованный уровнем выше, чем Shadow DOM

  • механизмы изоляции в Shadow DOM обеспечивают изоляцию внутренних процессов вебкомпонентов от внешней среды в обоих направлениях

  • Shadow DOM вебкомпонент не прозрачен для virtual DOM

  • вебкомпоненты “замкнуты” внутри своего Shadow DOM

  • взаимодействие с внешней средой фреймворка через js-api вебкомпонента и его атрибуты

Вебкомпоненты дают возможность использовать единую ui-билиотеку

Polymer

Polymer позволяет использовать вебкомпоненты уже сегодня.

Возможности:

  • создание пользовательских элементов:
    — регистрация пользовательского элемента, его ассоциация с именем и классом, описывающим жизненный цикл и логику работы элемента
    — управление жизненным циклом элемента
    — использование property-api элемента для его интеграции с Polymer data system

  • использование Shadow DOM в polymer-компонентах позволяет:
    — изолировать DOM-дерево пользовательского элемента
    — создать DOM-дерево пользовательского элемента на основе DOM-template

  • система событий

  • Data system
    — data binding для свойств и атрибутов
    — property observers
    — вычисляемые свойства / computed properties.

Polymer: улучшения в 2.0

  • улучшена функциональная совместимость с библиотеками и фреймворками
    — код Shadow DOM-полифила Shady DOM выведен из Polymer
    — для манипуляций с DOM используется стандартный API спецификации Shadow DOM

  • стандартизация
    — поддержка спецификаций Shadow DOM v.1, Custom Elements v.1
    — использование ES6 классов для описания polymer-компонента
    — жизненный цикл polymer-компонента соответствует Custom Elements v.1

Polymer: под капотом

Polymer использует набор полифилов, объединенных в пакет webcomponentsjs:
— полифилы Shadow DOM: Shady DOM, Shady CSS
— полифилы Custom Elements, HTML Imports, HTML Templates

Зачем понадобился еще один полифил Shadow DOM:
— существующие достаточно сложны и медленны
— представляет собой shim
— реализует изоляцию дерева без потерь производительности
— предоставляет API в соответствии со спецификацией Shadow DOM

Полифилы реализованы с учетом:
— минимизации потерь производительности
— максимальной совместимости по API со стеком стандартов Web Components
— переключения браузерную реализацию вебкомпонентов при ее наличии
— упрощения использования Polymer с другими библиотеками и фреймворками

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

WEBCOMPONENTS.ORG

единый репозиторий UI-компонент, созданных на вебкомпонентах и Polymer

  • PolymerElements
    (elements.polymer-project.org)
  • GoogleWebComponents
    компоненты для работы с сервисами Google (входил в состав elements.polymer-project.org)
  • Vaadin

Web Components / Polymer

Проекты:

Примеры:

Ссылки