В цьому році у мене було кілька презентацій про SC5 Style Guide. в яких я ділилася досвідом використання інструменту на проектах одного із наших клієнтів - мобільного оператора Elisa. З огляду на, що Elisa - величезна компанія з масою вебсайтів, на яких потрібно підтримувати єдиний стиль, не дивно, що SC5 Style Guide як інструмент там дуже корисний. Але як щодо невеликих проектів? Чи варто для них робити стайл гайди? Я сама не знала відповідь на це питання і захотіла поекспериментувати. В якості піддослідного сайту взяла власний блог.
Живий стайл гайд мого блогу виглядає ось так: varya.me/styleguide. Ви можете бачити весь інтерфейс, розділений на блоки, кожен з яких має на увазі самостійний компонент. Я до сих пір не дивилася на інтерфейс свого блогу в такому ключі, і це змушує мене навіть переглянути CSS-архітектуру проекту. Але давайте про все по порядку.
Налаштування SC5 Style Guide
Все починається з установки пакета
Після цього я змогла згенерувати веб-сайт стайл гайда. Для цього знадобилася парочка gulp ТАСК.
Мені потрібно було трохи відступити від конфігурації, яка пропонується в документації, щоб вирішити свої завдання. Напишу про це докладно.
Використання параметра appRoot
Мій стайл гайд знаходиться не в корені домену, а в папці, яка називається styleguide. Про це потрібно повідомити інструменту, щоб сгенерированное їм додаток використовувало вірні посилання:
Але насправді потрібна ще одна хитрість. Мої компоненти написані на i-bem.js і автоматично не започатковано по domReady. Це як раз те що потрібно для блогу, адже сторінки статичні і вся HTML-розмітка відразу завантажується. Але сайт стайл гайда - це SPA (односторінкове додаток), і там це не працювало. Компоненти отрісовиваємих на сторінках стайлгайда "на льоту", і очевидно, що це відбувається пізніше domReady. Тобто вони не започатковано автоматично. На щастя, можна використовувати подія styleguide: onRendered на об'єкті window. яке SC5 Style Guide створює кожен раз, коли компонент перересовивается. Я зробила ініціалізацію компонент на цю подію, тобто відразу після того як вони з'являються на сторінці. Така ініціалізація потрібна тільки на сайті стайл гайда, тому цей код не включається в загальну збірку і підключається до стайл гайду як додатковий файл.
Стайл гайд як статична сторінка
Для режиму розробки у SC5 Style Guide запускається сервер, який разруливает всі шляхи в кореневій каталог, звідки і лунає сгененірованний SPA-сайт. Якщо ви хочете користуватися результатом в своєму сервері, про таку маршрутизації доведеться подбати самостійно. Але в моєму випадку сайт розташовується на GitHub Pages, це статичний хостинг і там ніякої маршрутизації не передбачено. Однак на цей випадок є настройка disableHtml5Mode: true. Вона каже генератору, що в додатку повинні бути старі добрі посилання з гратами #. Так що все працює.
документування компонент
Ще до впровадження стайл гайда, у мене весь CSS був написаний по БЕМ, тобто з компонентів підходом. Для стайл гайда потрібно було тільки поставити компонентів структуру і задокументувати блоки за допомогою KSS.
структурування коду
Виявилося, що файлова структура, яку пропонує БЕМ, не найкраще рішення для розробки живого стайлгайда. На файлової системи всі компоненти представлені довгим плоским списком:
Тобто маленькі атомарні компоненти ніяк не відрізняються від блоків для структури сторінки (таких як Header або Footer), від блоків з сайдбара або від CSS для сторонніх віджетів. Зрозуміло, плоска структура більш зручна для збирачів, але з точки зору розробки потрібна якась каталогізація.
Для цього я зробила файл overview.css. в якому немає ніякого активного CSS, але він допомагає мені організувати блоки. У мене там 5 секцій, і в кожної пов'язані з нею компоненти:
Я ігнорую свої списки блоків, тому що вони ніяк не впливають на код. Але опису секцій залишаються.
опис блоків
У документації компоненти прорисованности окремо для кожного модифікатора: varya.me/styleguide/#/section/1.5.1
Для складені компоненти, які використовують всередині себе інші, я використовувала ключовий тег
Завдяки цьому документація в коді прийнятного розміру, а на сайті все розкривається в повному вигляді: varya.me/styleguide/#/section/4.1
Style-Guide-Driven Development
Якщо в отриманому стайл Гайд в поле для пошуку ви наберете "logo", то побачите всі компоненти, який використовують логотип! Пошук проводиться по всьому коду. Точно так само можна пошукати компоненти, в розмітці яких використовується . Або в чиїх стилях є font.
Мені особисто дуже подобається, що можна шукати і по розмітці. Цим можна користуватися під час рефакторінга. Наприклад, змінивши input, я можу знайти все що використовують його блоки і подивитися, чи не зламалися вони.
Хоча насправді це лише невелике доповнення до головній перевазі використання стайл гайда. По-моєму, його основний плюс - демонстрація помилок верстки.
В CSS мого блогу ще до впровадження стайл гайда використовувати компоненти підхід. З огляду на мій БЕМ досвід, я була на 100% впевнена, що компоненти написані добре. Але навіть така компонентна розробка все одно відбувалася з точки зору сторінки. До того як блоки були впроваджені в блог, я робила їх на окремій статичної сторінці. Тобто окремо, поза сторінки, вони ніколи і не існувало.
Блоки розроблялися як незалежні, я писала код, намагаючись цього досягти. Але будучи розміщеними разом на одній і тій же сторінці, вони ніколи незалежними були.
Після того як SC5 Style Guide чарівним чином отрисовать їх окремо, я можу бачити, що блок logo вирівняний по правому краю. Хоча чому б це? Очевидно, це моя помилка, допущена, коли я верстала логітіп всередині блоку Header.
Те ж саме відбулося з переключалкой мов. вона так само вирівняна вправо.
Звичайно, такі відкриття на увазі швидкий рефакторинг :-)
І на довершення потрібно сказати, що експеримент не закінчений. Є й інші відкриття для нових постів.