Стратегия разбиения верстки на блоки?

Здравствуйте
Подскажите как вы разбиваете вашу верстку на блоки
Вот возьмем, например, header. Предположим внутри блока есть кнопка, которая есть и в других блоках. Маргины мы прописываем в стилях к этой кнопке и добавляем соответствующий модификатор? А как эти кусочки потом собрать? С помощью pug includes или gulp-...
Предположим еще в этом блоке есть меню, которое больше нигде не используется, его мы уже верстаем не отдельно, а вместе?
  • Вопрос задан
  • 1461 просмотр
Решения вопроса 1
Hyubert
@Hyubert
JS
Подскажите как вы разбиваете вашу верстку на блоки
Вот возьмем, например, header.

Хедере это конкретный блок со своим классом и модификаторами (если нужно). Далее все намного проще - позиционирование мы не включаем в стили модификатора, это скорее изменение его внешнего вида, об этом следует помнить.

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

Ну так и делайте ее отдельным блоком, например с классом .btn или .button и у нее будут свои модификаторы. Чаще всего у блока кнопки их много. Пример как делаю я:
.btn {}
/* style */
.btn--primary {}
.btn--secondary {}
/* size */
.btn--sm {}
.btn--md {}
.btn--xl {}
/* special */
.btn--link {}


Маргины мы прописываем в стилях к этой кнопке и добавляем соответствующий модификатор?

Нет, отступы и кастомные стили (очень специфичные) мы задаем в зависимости от родительского блока в котором находиться кнопка, в данном случае это хедер. Мы может сделать так:

.header .btn {}
или например такой класс сделать
.header__btn {}

Я предпочитаю вложенность (но не больше 1 уровня)

А как эти кусочки потом собрать? С помощью pug includes или gulp


Ну тут уже по разному, как вам удобней и зависит от конкретного инструмента, если говорить о pug, то я делал так
1. объявление миксина в отдельном файле
mixin button(caption)
  button.button&attributes(attributes)!= caption

2. Подключал в глобальный скоуп через шаблоны (include)
3. Пользовался миксином в любом места.

Предположим еще в этом блоке есть меню, которое больше нигде не используется, его мы уже верстаем не отдельно, а вместе?


Сделайте отдельным компонентом - не пожалеете. Во первых держать весь код в порядке (в одном понятном виде) удобно. Во вторых - если будет нужно расширение проекта или почти такое же меню но в другом месте, это вам пригодиться.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
KornevaViktoria
@KornevaViktoria
Frontend Developer
.header
         
.header__action (обертка для кнопки с маджинами и тд)
    .action.action--buy (кнопка + модификтор (кнопка "купить"))
         
.header__menu (для стилизации меню для этого блока)
    .menu (меню, которое может использоваться хоть где на сайте)
Ответ написан
Комментировать
@float64
Для разбиения верстки на блоки есть специальная методология которая называется Atomic Design, вот описание основных ее компонентов: atomicdesign.bradfrost.com/chapter-2

Если в одной картинке - то выглядит это так: 5d16e97162677234688043.png

Для работы по методологии Atomic Design существует проект Pattern Lab: https://patternlab.io
Это вроде как и фреймворк и набор инструментов и static site generator, короче целая экосистема для тех кто делает верстку по принципам Atomic Design.

Принципы Atomic Design не зависят от используемого языка или фреймворка.

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

Из минусов - придется с нуля въехать в новую методологию, порог вхождения таки есть, плюс надо будет найти инструменты под те технологии на которых вы строите UI.
Ответ написан
Комментировать
@Spaceoddity
"Не стоит плодить сущности без нужды" (с) У. Оккам
Разбивайте блоки по логическим и семантическим признакам. Т.е. просто задумайтесь - как ВАМ БУДЕТ УДОБНЕЕ потом работать.
Кнопки - окей. Выносите для них общие стили. А позиционирование делайте контекстным селектором от родителя. Либо навешивайте отдельный класс (именно для позиционирования).
Тут ещё такой момент, что вы заранее не можете знать насколько общие стили будут иметь эти "переиспользуемые блоки" (ну серьёзно, у меня уже просто люто бомбит от этого БЭМа, переиспользуются в основном как раз элементы, но по "семантике БЭМа" - это, мать их за ногу, блоки)))
Например, вы вынесли весь декоратив в общий стиль. А для модификации оставили позиционирование. А зватра вам дизайнер даёт практически идентичную кнопку, но другой высоты. Вы её можете контекстом снова поправить. А послезавтра снова другая высота. И в итоге получается что выносить надо как раз стиль для поздних кнопок, а вот первую делать "модифицируемой".
Так что я бы просто набирал стили as is. А уж потом, при желании, можно и рефакторинг сделать - и объединить, вынести какие-то отдельные стили.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы