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


Как следствие проблемы: на создание новых страниц тратится неоправданно много времени. Теряется целостность сайта. Растёт файл стилей и код.


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


Что делать?


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


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

Подобная синергия достигается следованию трём принципам, приведенным ниже.


1. Покажите всё что есть
Чаще всего дизайнер просто не знает о том, что подобная кнопка уже есть на странице подтверждения адреса электронной почты из-за её труднодоступности. Хорошо бы было представить имеющиеся функциональные элементы сайта где-то в одном месте. Да так чтоб поддерживать эту коллекцию в актуальном состоянии было как можно легче. И тут на сцену выходит библиотека компонентов. Так же известная как “styleguide” или “pattern library”. На данный момент существует огромный выбор средств генерации стайлгайдов и написано немало статей на эту тему.


Пользователь Гитхаба и по совместительству автор Jekyll Styleguide Дэвид Ханд постарался классифицировать существующие генераторы библиотек компонентов. На этой странице можно ознакомиться со списком имеющихся инструментов.


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


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


1. Компоненты представляются в файле стилей


+ Легче поддерживать: поменял стили, в том же файле изменил комментарий с примером, вуаля!
— Неудобно на больших примерах, в том числе ввиду отсутствия подсветки и поддержки IDE


Вот достаточно большой список имеющихся генераторов подобного типа.


2. Элементы хранятся в отдельных файлах


+ Все прелести IDE, больше свободы в добавлении и хранении примеров
— Еще один файл, нуждающийся в поддержке


Примеры библиотек: Fractal, Pattern Lab on Node, Fabricator.


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


Напоследок


Я бы хотел поделиться своей наработкой, появившейся как результат нескольких лет использования стайлгайдов: Component Library. Вот пример её использования на основе компонентов Хабра.
Несмотря на огромный выбор библиотек компонентов, Component Library объединила в себе преимущества многих инструментов:


  • Невероятно простая интеграция в текущую систему. Если у вас существует процесс сборки фронтенда, то библиотека компонентов без труда внедряется на одном из этапов
  • Бесконфликтность со стилями и скриптами самого вебсайта
  • Простота поддержки. Каждый компонент — это отдельный HTML файл, который доступен как в общем списке компонентов, так и отдельной страницей
Поделиться с друзьями
-->

Комментарии (8)


  1. napa3um
    22.04.2017 12:06

    С Web Components не сравнивали свою библиотеку?


    1. search
      22.04.2017 13:12

      Спасибо за ссылку. Это немного разные вещи. Web Components — технология, позволяющая создавать переиспользуемые компоненты. Component Library — это список переиспользуемых компонент. По сути, Components Library может состоять из Web Components.


      1. napa3um
        22.04.2017 14:02

        https://www.webcomponents.org/ — а вот и список.


        1. search
          22.04.2017 14:24
          +1

          Цель Component Library — предоставить возможность создавать и поддерживать список компонентов конкретного вебсайта (например Хабра: https://sneas.github.io/habrahabr/index.html). Я так понимаю https://www.webcomponents.org/ задумывался как глобальная коллекция существующих веб компонент?


  1. lifeart
    22.04.2017 13:32

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


    1. lifeart
      22.04.2017 13:47

      Доклад по теме — «как разрабатывать и поддерживать компоненты»


  1. RubaXa
    23.04.2017 10:33

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


    Посмотрите этот доклад, там есть краткий обзор существующих решений и не только.


    1. search
      23.04.2017 17:42

      Большое спасибо за полезный доклад.
      Своё решение, как водится, родилось от отчаяния. Требовалось всего-то:


      • показать все компоненты на одной странице
      • иметь отдельную страницу для каждой из компонент. Очень помогает при отладке адаптивных элементов
      • древовидная структура представления компонент (папки-подпапки)

      Единственная библиотека, подходящая по перечисленным критериям была Tapestry. Может еще есть? Беда в том, что нужно попотеть чтоб встроить Tapestry в билд процесс и она люто конфликтовала с имеющимся кодом. Такие дела.