Лучшая практика для создания пользовательских элементов
Перевод статьи Best Practice for Creating Custom Elements с сайта www.broken-links.com, c разрешения автора — Питера Гастона.
В целом, похоже на то, что пользовательские элементы и веб-компоненты начинают прорываться в умы разработчиков, т.к. я вижу всё больше и больше статей и разговоров на эту тему, дискуссий о том, где лучше использовать пользовательские элементы и как их создавать.
Однако, поскольку они ещё не так активно используются в разработке, я считаю, что есть хорошая возможность определить лучшие практики в том, как мы их используем. В этой статье я хочу предложить оптимальный метод для написания пользовательских элементов: я сделаю это путём сравнения двух методов для создания пользовательских элементов, наряду с преимуществами и недостатками каждого из них.
Небольшое отступление: я в шоке, что здесь, в моём блоге, я ещё ничего не писал про пользовательские элементы, несмотря на то, что выступил с несколькими докладами и написал несколько опубликованных статей на эту тему. В случае, если вы не знаете, что это такое, я рекомендую вам сначала прочитать моё Подробное руководство по пользовательским элементам.
Важное замечание: Пожалуйста, обязательно прочитайте раздел «Будущее пользовательских элементов» в конце этой статьи, ради некоторых важных новостей о статусе пользовательских элементов.
Новый пользовательский элемент
Первый способ создать пользовательский элемент – это написать его с нуля, зарегистрировав абсолютно новый элемент в DOM. В этом примере я зарегистрировал, а затем реализовал новый элемент, который я буду использовать в качестве кнопки. Я назвал свой элемент new-button, т.к. я человек с ограниченным воображением.
//JS-файл
document.registerElement('new-button');
<!-- HTML file -->
<new-button>Отправить</new-button>
Я считаю, что это имеет два существенных недостатка. Во-первых, если в браузере пользователя не работает JS, то эта кнопка ничего не будет делать; всё что увидит пользователь, это текст внутри элемента. И это относится не только к случаям, когда JS не сработал или был отключен, но также и когда он ещё не загрузился (большой JS-файл, медленное сетевое соединение).
Второй, и более затруднительный для меня, это то, что новый элемент использовал бы стандартный интерфейс HTMLElement API, так что, чтобы заставить его действовать, как кнопка, мне пришлось бы вручную добавлять все уникальные свойства и методы кнопки: все свойства формы, функции доступности, признаки поведения, методы валидации, и конечно же, основная возможность отправки формы.
Расширение существующего элемента
Вторым способом создания пользовательского элемента – это расширить существующий элемент, учитывая все его свойства. В этом примере я снова создам элемент new-button, но на этот раз включу параметр extends, чтобы показать, что элемент должен быть построен по стандарту button, и добавлю в разметку атрибут is, чтобы указать какой пользовательский элемент нужно использовать для его расширения:
//JS-файл<
document.registerElement('new-button', {
extends: 'button'
});
<!-- HTML file -->
<button is="new-button">Отправить</button>
При использовании этого метода мой элемент new-button получает все свойства и и все функции кнопки без каких-либо дополнительных усилий с моей стороны. И, если по какой-то причине JS не будет работать, пользователь по-прежнему увидит обычную кнопку, позволяя ему отправить форму независимо от этого.
Можете взглянуть на реальный пример этого метода в действии на Github, где расширен элемент time:
<time is="relative-time" datetime="…">Jan 27, 2015</time>
Когда JS работает и браузер поддерживает пользовательские элементы, то элемент relative-time используется и метка времени отображается как относительная («2 часа назад»);
Самый лучший способ создать пользовательский элемент
Мне ясно, что второй метод превосходит первый; на самом деле я не могу вспомнить ни одного недостатка в создании пользовательского элемента таким способом.
Я сделал живой пример метода расширения пользовательского элемента, демонстрирующий расширенный элемент <button> с пользовательским прототипом. Чтобы увидеть, как работает этот метод, вам необходимы Chrome, Opera или Firefox с поддержкой dom.webcomponents.enabled.
Я считаю, что до тех пор, пока пользовательские элементы зависимы от JS, мы должны расширять существующие элементы при написании пользовательских. Это имеет смысл для разработчиков, т.к. у новых элементов есть доступ к свойствам и методам, которые определены и испытаны в течение многих лет; и для пользователей, т.к. они увидят запасное решение в случае неработающего JS, со встроенной базовой доступностью.
Единственная трудность, которую я вижу – это выбор правильного типа для нового пользовательского элемента; например, если я использую элемент google-maps, должен ли я расширить пустой div или img со статичной картой в src? Это важное решение, и результат вашего выбора должен всегда позволять пользователям полностью решать поставленные ими задачи, хотя бы и в более ограниченной форме. Однако, я не считаю это препятствием к применению практики.
Заключение
Честно говоря, это не новый совет; можете признать его как хорошее старомодное прогрессивное улучшение. Запасное решение, поведение и доступность, должны рассматриваться всегда, когда вы можете улучшить или создать новый элемент UI при помощи JavaScript. Как выразился Роджер Йоханссон:
Если вы действительно должны сделать полностью пользовательский элемент «select», убедитесь, что вы воспроизвели всю функциональность родного select-а. Для каждой платформы.
Из того лишь, что пользовательские элементы — новая технология, еще не следует, что мы должны забыть уроки прошлого.
Будущее пользовательских элементов
Когда я подготавливал этот пост, то узнал, что обсуждается вопрос об удалении метода is/extends из спецификации пользовательских элементов, чисто скриптовую систему надстроек, целиком основанную на скрипте. Существует много причин для этого, и если вы заинтересованы (и у вас есть свободное время), то можете следить за дискуссией в списке рассылки Web Apps. Пока это только на уровне разговоров, но, вероятно, произойдёт. Я публикую этот пост, потому что информация в нем верна на момент публикации (и, честно говоря, потому что потратил на него немало времени!), но имейте в виду, что вряд ли именно этот метод мы станем использовать в будущем. Однако, важно отметить, что в широком смысле прогрессивное улучшение всё ещё в силе.
Большое спасибо Стюарту Лангриджу, Брюсу Лоусону и Патрику Лауке за дотошную вычитку этой статьи, вдохновлённой короткой беседой в Твиттере со Стюартом и постом «О доступности веб-компонентов. Снова.» в блоге Брюса.
Обратите внимание, что я упростил пример ради иллюстрации; в реальной задаче я бы хотел добавить некоторое поведение или свойства к моей кнопке, помимо стандартных, чтобы оправдать использование пользовательского элемента для нее. Это показано в последнем примере.
P.S. Это тоже может быть интересно: