Web components что это за программа
WebHive
После прочтения статьи What«s coming in ember in 2014 узнал много интересного и нового. Одним из таких открытий стал стандарт Web Components. Ну что — стоит разобраться и с этим вопросом.
Собственно Web Components это не что иное как набор стандартов, позволяющих создавать собственные HTML элементы.
Рассмотрим довольно типичный пример — слайдер, разметка для которого выглядит примерно так
И не забудем CSS …. хотя не стану приводить здесь 80-строчный кусок кода. Я думаю уже видно насколько горомоздкий получается код.
Что же предлагает нам Web Components? А вот что:
Из громоздкой конструкции из HTML+CSS кода мы оставляем только необходимый минимум — только теги которые действительно необходимы. Кто рискнет сказать, что это не красиво?
Но как? Элементарно Ватсон ….
На самом деле каждый компонент состоит из шаблона, JavaScript-а и стилей. Они просто не видны. Это так называемый Shadow DOM.
Чтобы посмотреть его в действии можно включить отображение в настройках Development Tools в Chrome (можно-ли это сделать в других браузерах я не знаю). Вот тут на картинке показано как это сделать. Эти настройки вызываются нажатием на кнопочку в правом нижнем углу инспектора.
Я удивлён … „о сколько нам открытий чудных …“ как говаривал классик.
Давайте же скорее использовать эту прекрасную технологию
Но тут нас поджидает изрядная ложка дёгтя. Не все так гладко как хотелось бы. Рассмотрим известные проблемы
Поддержка браузерами
С поддержкой этой технологии браузерами пока довольно туго. Ифактически полноценную работу обеспечивает только Chrome.
Эту проблему пытается разрешить Google выпустив библиотеку Polymer. Не буду углубляться в детали этого решения — возможно запилю статью на эту тему. Библиотека делает практически тоже-самое чтои WebComponents, но требует подключения отдельного js-файла. Как-то вот так:
Непонятно как роботы будут воспринимать и индексировать такие HTML элементы. Обнадёживает, что технологию активно проталкивает именно Google, поэтому вполне вероятно, что в скором времени как минимум этот поисковик научится понимать такую размётку.
Настройка внешнего вида
Все сайты выглядят по разному, поэтому крайне желательно иметь возможность настроить вид любого компонента по своему желанию. К сожалению WebComponets не позволяют такой роскоши и выглядеть будут именно так как прописано у них внутри в их собственных стилях.
Вывод
Довольно интересная и многообещающая технология. Будем ждать развития и одним глазом поглядывать в эту сторону.
Ссылки по теме
В данной статье я не буду вдаваться в нюансы реализации по ссылкам ниже есть более детальные описания. Ищите да обрящете.
Быстрый старт с WebComponents
Веб-компоненты это набор стандартов определяющих программные интерфейсы для организации компонентной архитектуры. Все они реализованы в современных версиях браузеров, т.е. не требуют подключения библиотек или транспиляторов кода, однако, если нужна совместимость например с Internet Explorer 11, то и библиотеки и транспиляторы использовать видимо все-таки придется.
Данная статья ориентирована на начальный уровень подготовки и разработчиков имеющих опыт с тем или иным фронтенд фреймворком, но возможно, благодаря некоторым фокусам, будет интересна и многоопытным специалистам.
Все эксперименты приводимые далее проверялись в Chrome и Firefox может быть даже не самых новых версий.
Итак начнем.
Для начала создадим директорию для проекта и перейдем в него.
в этом каталоге ответив на все вопросы по умолчанию.
Создадим в каталоге файл index.html с самым простым содержимым.
Добавим тег для элемента, имя должно обязательно содержать дефис, это сигнал для подсистемы CusomElements для попытки определения этого элемента как надстраивающего стандартные.
Добавим класс обработчик в теге script.
В модульном теге script, мы определили новый класс который c помощью метода customElements.define() определили за тегом my-webcomp. А добавив код в метод connectedCallback() мы обеспечили его вызов при добавлении реализации компонента в дерево. Результат уже можно посмотреть в браузере:
Однако, размещать html верстку прямо в код если и удобно для небольших кусочков, то вообще не правильно, что особенно сказывается когда кусочки разрастаются до приличных размеров. Например на форме с 20ю элементами, которую побить на подкомпоненты тоже не всегда может быть удобно. Поэтому мы для начала вынесем верстку в шаблон, который будет располагаться в том же html, хотя ничто не помешает его нам загрузить из отдельного файла при необходимости.
В коде компонента вставку строки c html мы заменили на получение элемента шаблона по id. Импорт, т.е. создание копии этого элемента и прицепление к содержимому текущего.
id назван в нотации camelCase т.к. все айдишники элементов прокидываются в глобальное пространство имен и при использовании дефисов или других спец. символов доступ к ним может быть менее элегантен. Т.е. мы могли бы вместо:
написать в одну строчку:
и этот код работал бы точно так же, но это считается не очень безопасным. Также если мы присвоим id нашему элементу, то сможем обращаться к нему из любой точки контекста как к экземпляру из глобального пространства имен вызывая методы и получая значения свойств.
Например вот так:
При таком раскладе алерт будет показываться сразу при загрузке страницы.
Теперь повесим обработчик клика мышки для нашего компонента который будет выводить алерт сообщение.
Теперь при нажатии на сообщение у нас будет реакция на действия пользователя.
Аргументом метода showMessage() также объявляется объект event, который хранит данные о событии, например координаты клика или ссылку на сам элемент.
Часто каждый конкретный элемент надо сконфигурировать уникальным для него образом, это можно сделать используя атрибуты.
Добавим второй экземпляр элемента и определим для каждого из них разные свойства greet-name значения которых будут выводиться при нажатии на элемент.
Теперь при нажатии на первый будет выводиться “This is the message for John”, а на второй “This is the message for Josh”.
Может так случиться что атрибут надо будет использовать не в обработке события, а прямо отрендерить в шаблон, для этого мы добавим id целевому элементу и подставим значение из апи сразу после рендеринга копии объекта шаблона.
Получается вот так:
Вместо .textContent может быть .innerHTML или можно вызвать у объекта из селектора тот же метод .insertAdjacentHTML() мы делали в самом начале.
Долгое время использование айдишников считалось дурным тоном, потому что на значительных объемах кода они могли дублироваться, что приводило к коллизиям. Однако, с появлением технологии теневого дерева можно внутреннее содержимое элемента изолировать использовать айдишники, стили и прочие ресурсы без опасений. Для веб-компонентов включается теневое дерево следующим образом:
Теперь правда все DOM обращения к this придется заменить на this.shadowRoot благо их пока не так много.
Визуально работа этого кода опять никак не изменится, но теперь в глобальном пространстве имен не будет никакого helloLabel, а у на странице уже 2 элемента с таким идентификатором. А получить доступ к ним можно будет например вот так:
и то если вы не закроете дерево передав соответствующий атрибут в методе .attachShadow().
У нас получилось довольно много кода и размещать его прямо в html файле тоже не очень правильно. Поэтому создадим файл my-webcomp.js и перенесем в него наш класс предварив инструкцией export, а в теге script добавим импорт этого класса, чтобы получилось вот такое:
Правда с этого момента открывать index.html как локальный для разработки не получится, т.к. браузер заблокирует загрузку скрипта с файловой системы. Если у вас есть nodejs можно поставить простейший веб-сервер:
и запускать его командой http-server в каталоге с проектом, при запуске он подскажет хост и порт с которого можно открывать страницу
Которая и будет отныне адресом отладочной страницы с нашим элементом.
Немаловажным для разработки является написание тестов, они помогают удерживать код работоспособным в ходе развития его компонентов. Для тестирования веб-компонентов можно использовать mocha в режиме запуска из браузера.
Для этого создадим каталог test и добавим в него файл all.html такого содержимого:
Скопируем наш index.html в test/ задав ему имя my-webcomp.tests.html и добавим такое же содержимое head как и в all.html.
Однако, нам обычную инициализацию и манипуляции теперь надо будет заменить на производимую в рамках запуска тестов:
Теперь при заходе на
будет показан отчет о выполнении тестов.
Но может потребоваться запускать тесты автоматизировано и в разных браузеров для этого надо поставить специальную утилиту:
и запускать вот так:
Эту строчку можно добавить в секцию test файла package.json и запускать как:
Рекомендуется тестировать каждый значимый метод класса в рамках отдельного теста. Если надо сделать общую для каждого инициализацию ее следует определить в методе suiteSetup():
На этом наверное хватит для первого раза, мы получили некоторый минимальный проект которому решай он конкретную задачу не стыдно было бы сделать.
Книг на тему пока не так уж много, но вся расширенная документация легко находится по словам Web Components, CustomElements, ShadowDOM, Native Template Tag, Custom Events.
А продолжение темы демонстрирующее способы взаимодействия между компонентами за счет использования событий можно найти вот тут
Web Components — будущее Web
Спустя какое время стало ясно, что основная идея Prototype вошла в противоречие с миром. Создатели браузеров ответили на возрождение Javascript добавлением новых API, многие из которых конфликтовали с реализацией Prototype.
Код на стороне клиента становится сложнее и объёмнее. Появляются многочисленные фреймворки, которые помогают держать этот хаос под контролем. Backbone, ember, angular и другие создали, чтобы помочь писать чистый, модульный код. Фреймворки уровня приложения — это тренд. Его дух присутствует в JS среде уже какое-то время. Не удивительно, что создатели браузеров решили обратить на него внимание.
Web Components — это черновик набора стандартов. Его предложили и активно продвигают ребята из Google, но инициативу уже поддержали в Mozilla. И Microsoft. Шучу, Microsoft вообще не при делах. Мнения в комьюнити противоречивые (судя по комментариям, статьям и т.д.).
Основная идея в том, чтобы позволить программистам создавать “виджеты”. Фрагменты приложения, которые изолированы от документа, в который они встраиваются. Использовать виджет возможно как с помощью HTML, так и с помощью JS API.
Я пару недель игрался с новыми API и уверен, что в каком-то виде, рано или поздно эти возможности будут в браузерах. Хотя их реализация в Chrome Canary иногда ставила меня в тупик (меня, и сам Chrome Canary), Web Components кажется тем инструментом, которого мне не хватало.
Стандарт Web Components состоит из следующих частей:
Фрагменты HTML, которые программист собирается использовать в будущем.
Содержимое тегов парсится браузером, но не вызывает выполнение скриптов и загрузку дополнительных ресурсов (изображений, аудио…) пока мы не вставим его в документ.
Инструмент инкапсуляции HTML.
Импорт фрагментов разметки из других файлов.
В Web Components больше частей и маленьких деталей. Некоторые я ещё буду упоминать, до каких-то пока не добрался.
Templates
Концепция шаблонов проста. Хотя под этим словом в стандарте подразумевается не то, к чему мы привыкли.
В современных web-фреймворках шаблоны — это строки или фрагменты DOM, в которые мы подставляем данные перед тем как показать пользователю.
В web components шаблоны — это фрагменты DOM. Браузер парсит их содержимое, но не выполняет до тех пор, пока мы не вставим его в документ. То есть браузер не будет загружать картинки, аудио и видео, не будет выполнять скрипты.
К примеру, такой фрагмент разметки в документе не вызовет загрузку изображения.
Пример работы шаблонов можно посмотреть здесь.
Все примеры в статье следует смотреть в Chrome Canary со включенными флагами:
Для Чего?
На данный момент существует три способа работы с шаблонами:
Минусы такого подхода в том, что браузер попытается “выполнить” код шаблона. То есть загрузить картинки, выполнить код скриптов и т.д.
Минус в том, что приходится работать со строками. Это создаёт угрозу XSS, нужно уделять дополнительное внимание экранированию.
У нет этих недостатков. Мы работаем с DOM, не со строками. Когда выполнять код, также решать нам.
Shadow DOM
Инкапсуляция. Этого в работе с разметкой мне не хватало больше всего. Что такое Shadow DOM и как он работает проще понять на примере.
Когда мы используем html5 элемент код выглядит примерно так:
Но на странице это выглядит так:
Мы видим множество контролов, прогресбар, индикатор длины аудио. Откуда эти элементы и как до них добраться? Ответ — они находятся в Shadow Tree элемента. Мы можем даже увидеть их в DevTools, если захотим.
Чтобы Chrome в DevTools отображал содержимое Shadow DOM, в настройках DevTools, вкладка General, раздел Elements ставим галочку Show Shadow DOM.
Содержимое Shadow DOM тега в DevTools:
Теория Shadow DOM
Shadow Tree — это поддерево, которое прикреплено к элементу в документе. Элемент в этом случае называется shadow host, на его месте браузер показывает содержимое shadow tree, игнорируя содержимое самого элемента.
Фишка shadow dom в том, что стили, определённые в нём с помощью
Зелёный фон в примере получит только `
` внутри shadow tree. То
есть стили «не вытекут» в основной документ.
Наследуемые стили
Авторские стили
Селекторы ^ и ^^
Инкапсуляция это здорово, но если мы всё таки хотим добраться до shadow tree и изменить его представление из стилей документа, нам понадобится молоток. И кувалда.
Селектор div ^ p аналогичен div p с тем исключением, что он пересекает одну теневую границу (Shadow Boundary).
Селектор div ^^ p аналогичен предыдущему, но пересекает ЛЮБОЕ количество теневых границ.
Зачем нужен Shadow DOM?
Shadow DOM позволяет изменять внутреннее представление HTML элементов, оставляя внешнее представление неизменным.
Custom Elements
API кастомного элемента
Прототип должен наследовать HTMLElement или его наследника,
например HTMLButtonElement :
Зачем нужны Custom Elements?
или
- хорошо подходят для низкоуровневой вёрстки, тогда как Custom Elements позволят писать модульный, удобочитаемый код на высоком уровне.
Shadow DOM и Custom Elements дают возможность создавать независимые от контекста виджеты, с удобным API и инкапсулированным внутренним представлением.
HTML Imports
Импорты — простое API, которому давно место в браузерах. Они дают возможность вставлять в документ фрагменты разметки из других файлов.
Object.observe()
Этот метод доступен в Chrome, если включить флаг Experimental Web Platform features.
TODO widget
Согласно древней традиции, вооружившись этими знаниями, я решил сделать простой TODO-виджет. В нём используются части Web Components, о которых я рассказывал в статье.
Добавление виджета на страницу сводится к одному импорту и одному тегу в теле документа.
Заключение
На мой взгляд, Web Components — это следующий шаг. Разработчики смогут создавать интерактивные виджеты. Их легко поддерживать, переиспользовать, интегрировать.
Код страницы не будет выглядеть как набор “блоков”, “параграфов” и “списков”. Мы сможем использовать элементы вроде “меню”, “новостная лента”, “чат”.
Конечно, стандарт сыроват. К примеру, импорты работают не так хорошо, как шаблоны. Их использование рушило Chrome время от времени. Но объём нововведений поражает. Даже часть этих возможностей способна облегчить жизнь web-разработчикам. А некоторые заметно ускорят работу существующих фреймворков.
Некоторые части Web Components можно использовать уже сейчас с помощью полифилов. Polymer Project — это полноценный фреймворк уровня приложения, который использует Web Components.
Ссылки
Eric Bidelman, серия статей и видео о Web Components:
Понятно и просто про веб-компоненты и Polymer
Кто я
Я — Александр Кашеверов. По образованию — магистр радиофизики. По профессии — веб-разработчик, работаю в компании DataArt с 2011 года, с 2009 увлекаюсь IT и веб-технологиями.
О чем статья, коротко
Рассмотрим, что такое веб-компоненты и polymer. Немного поразмышляем на тему развития веба. Посмотрим на технические детали, примеры, поддержку браузерами, тестирование. Коротко, понятно, по делу. С картинками.
Вступление
Веб постоянно развивается. Технологии были придуманы и внедрены, исходя из потребностей, актуальных на момент создания. Десять лет назад невозможно было сделать то, что мы реализуем сейчас, и сложно представить, что будет еще через 10 лет.
Бизнес требует создания крупных и сложных программных веб-продуктов с богатой функциональностью, красотой, высокой производительностью. Такие решения нетривиальны сами по себе, так еще и накладывается специфичность веб-технологий. Зачастую, чтобы уменьшить сложность продукта, его разделяют на множество более простых частей. Такой компонентный подход уменьшает хаос, улучшает структуру, понимаемость, увеличивает эффективность командной работы.
Для уменьшения головной боли хорошо бы, если в контексте веб:
Запутанно… Не правда ли?
Фреймворки в той или иной степени внедряют компонентизацию и стараются решить эти задачи. Однако, они так же построены на всё тех же HTML, CSS, JavaScript.
Веб-компоненты — коротко
Веб медленно, но верно движется к компонентизации — это естественный процесс. Сложное можно упростить, разбив на части. Параллельно развитию фреймворков идет работа и на более низком уровне. Набирают популярность веб-компоненты. Это реализация идеи компонентизации на уровне браузера.
История веб-компонентов началась в 2011 году (первое упоминание на github). Кратко — что это:
При использовании этих четырех технологий вместе, получаются автономные переиспользуемые блоки — веб-компоненты.
На самом деле, некое подобие веб-компонентов уже было создано давно. Простейший пример — элемент
В этом и есть суть веб-компонентов — создание простых и понятных независимых элементов со скрытой логикой, стилями.
Наверняка многие подключали в проект Bootstrap — для этого нужно отдельно прописать подгрузку стилей и скриптов. С компонентами это можно было бы сделать проще.
Веб-компоненты — не фреймворк. Это набор технологий, реализованных на уровне браузера.
Веб-компоненты — поддержка браузерами & polyfills
На данный момент (ноябрь 2015) три из четырех технологий находятся в стадии «Working Draft» на W3C.
Так выглядит ситуация на данный момент (ноябрь 2015):
Так как веб-компоненты в перспективе имеют высокую ценность, но, как обычно, не поддерживаются всеми браузерами, создаются способы улучшить поддержку. Так появились полифиллы.
С их помощью, поддержка браузерами уже получше.
На веб-странице полифиллы подключается стандартно в head (до всех скриптов, которые используют веб-компоненты):
Веб-компоненты — ссылки
Polymer
Тем временем, Google всё упрощает и развивает. Работа началась осенью 2012 года, судя по истории коммитов на github. Они взяли веб-компоненты, полифилы и создали еще одну надстройку.
Цель Polymer — упростить создание качественных веб-приложений (цитата product manager с конференции Google IO).
Polymer — коротко
Библиотека представляет собой веб-компоненты в основе, полифилы для поддержки старых браузеров, это всё обернуто в целостную более удобную систему с добавлением сахара.
Схематически это выглядит так:
Google создал набор готовых компонент и разделил их на логические части:
Можно заметить, что постоянно фигурирует слово «элемент». Google считает, что для всего можно сделать элемент. «There is an element for that» («для этого есть элемент») — звучит, как слоган в докладах Google IO 2015.
Да, даже для ajax запроса есть элемент. Выглядит так:
При создании приложений мы сталкиваемся с примерно одинаковыми задачами, и Google предлагает набор готовых строительных блоков для этого. С какой бы проблемой мы не столкнулись — для ее решения есть элемент. «There is an element for that».
Создан каталог готовых Polymer-компонентов.
Polymer — не фреймворк, как и веб-компоненты — не фреймворк. Polymer — это обертка и сахар. Я бы идейно ее сравнил с jQuery. jQuery создана для работы с DOM, а Polymer — для работы с веб-компонентами.
Polymer — тестируемость
Да, он тестируемый, и для этого создана отдельная утилита web-component-tester. Понятное описание.
Пробовал. Работает (при установке могут возникнуть проблемы с Java и Selenium).
Написать тест, просто html файл (по-умолчанию, в папке `./test`):
Polymer — поддержка браузерами
Polymer — сахар веб-компонента, поэтому и поддержка браузерами точно такая же. Таблицы были представлены выше.
К слову, у меня так и не получилось запустить на старом Android-телефоне.
Polymer — оптимизация vulcanize
HTML imports позволяет быстро и удобно подключить документ в другой документ, но в этом удобстве скрывается и проблема производительности: создается множество http-запросов. Решение есть —- соединить все подключаемые файлы в один. Для этого служит утилита vulcanize.
Polymer — starter kit
Polymer — альтернативы
Polymer — ссылки
Polymer — про взаимодействие с библиотеками
Веб-компоненты и Polymer — примеры
Рассмотрим простой пример веб-компонента и его Polymer-реализацию:
Пример чистого веб-компонента:
Используем на странице (в
С Polymer будет выглядеть заметно понятней и проще: