Jump Start Sass: архитектура в Sass

Ниже приведен краткий отрывок из нашей недавней книги Jump Start Sass , доступной бесплатно для членов SitePoint Premium . Печатные копии продаются в магазинах по всему миру, или вы можете заказать их здесь . Мы надеемся, что вам понравится этот экстракт и вы найдете его полезным.

Архитектура всегда была одной из основных проблем в разработке CSS. Без каких-либо переменных, управляющих директив, макросов или наследования объектов, CSS-код имеет тенденцию быть длинным и повторяющимся — один постоянно растущий файл. Хотя технически возможно разделить простой CSS на несколько файлов, которые ссылаются друг на друга с помощью @import , дополнительные HTTP-запросы делают это плохим решением. Как вы уже видели, у Sass есть ответ на каждый кусочек архитектурной головоломки, но как лучше всего собрать все это вместе?

Спросите десять экспертов, и вы получите десять разных ответов, большинство из которых связаны с (или с помощью) Sass. OOCSS , SMACSS , Atomic Design , ITCSS и BEM — все это популярные системы для архитектуры CSS, но их гораздо больше. Если вы используете интерфейсную среду, такую ​​как Bootstrap или Foundation , возможно, уже есть некоторые архитектурные решения.

Это все надежные системы, ни одна из которых не была разработана с учетом вашего проекта. Архитектура CSS сложна, поэтому ошибочно доверять любому универсальному решению. Не существует «правильного» ответа, который работал бы для каждой команды в каждом проекте. Мы рекомендуем изучить их все, а затем собрать воедино лучшие части, чтобы создать систему, которая будет хорошо работать для вас.

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

Несколько файлов и папок

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

Sass предоставил новую силу правилу CSS @import , позволяя объединять файлы Sass и CSS во время компиляции, чтобы их можно было отправлять в браузер как один файл. Это единственное место, где Sass вступил в тупик существующей директивы CSS, поэтому в Sass он ведет себя иначе, чем в CSS.

CSS Импорт

Как уже упоминалось, директива CSS @import позволяет ссылаться на один файл CSS из другого. Импорт обрабатывается браузером и требует дополнительных HTTP-запросов, поскольку файл импорта должен быть проанализирован до @import директивы @import . Если у вас есть цепочка файлов, импортирующих друг друга, этот импорт будет происходить последовательно, блокируя рендеринг документа, пока не загрузится весь CSS. По этой причине большинство людей полностью избегают импорта CSS.

Используя CSS-импорт, вы можете ссылаться на другой CSS-файл, используя относительные или абсолютные пути, даже добавляя правило медиа-запроса для условного импорта. Даже несмотря на то, что Sass предоставляет разные функциональные возможности в рамках одного и того же правила, в разных случаях Sass возвращается к ванильному выводу CSS, например, когда:

• импортированный файл имеет расширение .css

• имя файла начинается с http:// или https://

• имя файла является функцией url(..)

• @import есть медиа-запросы

Следующее будет компилироваться в стандартный импорт CSS, даже в Sass:

 @import 'relative/styles.css'; @import 'http://absolute.com/styles.css'; @import url('landscape.css') screen and (orientation: landscape); 

Sass Импорт и Частичные

Импорт Sass похож на импорт CSS, но импортированные файлы скомпилированы в один выходной файл, как если бы их содержимое (включая переменные, миксины, функции и заполнители) было скопировано и вставлено на место перед компиляцией. Этот тип импорта Sass будет работать только с файлами с расширениями .sass или .scss , но вы можете оставить расширение отключенным при импорте (если нет файлов с одинаковыми именами). На самом деле, мы рекомендуем удалить расширение всякий раз, когда вы можете, для простоты. Также возможно импортировать несколько файлов в одной команде или импортировать файлы во вложенный контекст:

 // Import an explicit file relative to the current directory @import 'path/to/explicit.scss'; // Import a file with either the .sass or .scss extension @import 'implicit'; // Import multiple files... @import 'path/to/emory.scss', 'miko', 'path/to/gracie'; // Import a file into a nested context... // (imagine the file copied and pasted into this context) .latte { @import 'espresso'; } 

Наиболее распространенное использование импорта Sass — для частичных файлов — файлы Sass, которые не скомпилированы самостоятельно, но предназначены для импорта в другие файлы. Если вы хотите, чтобы файл Sass оставался некомпилированным до его импорта, добавьте подчеркивание ( _ ) в начало имени файла. Файлы Sass, начинающиеся с _ , сами по себе не компилируются, но могут быть импортированы в другие файлы. При импорте частичных файлов Sass позволяет вам отключить _ , что аналогично отключению расширения. Например:

 // _authors.scss .miriam { background: blue; } // jumpstartsass.scss @import 'authors'; // Shorthand for importing '_authors.scss' // jumpstartsass.css (compiled CSS) .miriam { background: blue; } 

Запуск Sass в этом каталоге ( sass --update . ) Компилирует sass --update . ; тем не менее, он не создаст файл _authors.css , так как он имеет нижнее подчеркивание.

Частицы Sass составляют основу любой архитектуры Sass. Поскольку все операции импорта Sass обрабатываются во время компиляции и никогда не прерывают работу браузера, совершенно безопасно (и рекомендуется) использовать столько партиалов, сколько необходимо, скомпилировав их в одну таблицу стилей для производства. Чтобы быть организованными, мы рекомендуем свободно разбивать партиалы, сортировать их по папкам и импортировать все обратно в один главный файл для компиляции. Общий каталог Sass для проекта может выглядеть так:

 sass/ | |– config/ | |– _colors.scss # Color palettes | |– _webfonts.scss # Webfont information | … # Etc. | |– layout/ | |– _navigation.scss # Navigation | |– _banner.scss # Site Banner | … # Etc. | |– modules/ | |– _calendar.scss # Calendar widget styles | |– _contact.scss # Contact form styles | … # Etc. | |– patterns/ | |– _buttons.scss # Buttons | |– _dropdown.scss # Dropdown | … # Etc. | |- main.scss # The primary Sass file to be compiled 

После организации всех ваших частей они могут быть импортированы в один основной файл main.scss для компиляции:

 // Primary Sass File: main.scss @import 'config/colors'; @import 'config/webfonts'; @import 'patterns/buttons'; @import 'patterns/dropdown'; @import 'layout/navigation'; @import 'layout/banner'; @import 'modules/calendar'; @import 'modules/contact'; 

Компоненты и организация

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

Большинство систем организации CSS и Sass основаны на некоторой концепции «компонентов» пользовательского интерфейса или отдельных частей, которые могут быть объединены в единый проект. Компоненты могут быть любого размера или формы, но они должны сосредоточиться на выполнении одной задачи независимо друг от друга и с возможностью многократного использования. Кнопка, раскрывающийся список, календарь и форма поиска — все это примеры компонентов, которые можно повторно использовать в разных местах проекта. Размышление о вашем проекте как о наборе компонентов поможет вам создать организованную и поддерживаемую архитектуру, независимо от того, используете ли вы Sass или простой CSS.

Из-за того, как работает CSS, порядок вашего кода также повлияет на его значение: более поздний код имеет приоритет в каскаде над кодом перед ним. Некоторые из популярных фирменных архитектур (те, которые вы знаете по имени) пытаются полностью исключить эту особенность каскада, но я использую ее в качестве руководства — организацию кода от самого общего к наиболее конкретному — поэтому имеет смысл переопределение приоритетов. Код, который мы хотим применить в целом по всему сайту, должен стоять на первом месте, постепенно увеличивая специфичность и детализацию по мере продвижения к более уникальным компонентам и специальным случаям.

Впервые я узнал об этом подходе из замечательного выступления CSS Systems Натали Даун в 2008 году, прежде чем я когда-либо использовал Sass. В то время ее архитектура начиналась с элементов ( h2 , ol , ul и т. Д.), Сгруппированных по «типу», за которыми следовали классы, сгруппированные по созданному «эффекту», и, наконец, идентификаторы, сгруппированные по «компоненту», на который они влияют. В наши дни принято вообще избегать идентификаторы и разбивать элементы на более мелкие части, но концепция остается той же: сначала глобальные значения по умолчанию, за которыми следуют шаблоны для всего сайта и широкие макеты, и, наконец, более конкретные модули, темы и переопределения.

Проекты Sass включают в себя еще одну категорию значений по умолчанию для всего сайта, которых нет в CSS: код без вывода вообще — например, переменные, функции и определения смешивания. Многие люди (включая меня) разбивают этот код на его собственный набор партиалов, чтобы импортировать его везде, где это может быть полезно. У меня есть полная папка только для Sass-помощников и конфигурации для всего сайта, которые не приводят к выводу. Эти файлы действуют как единая, окончательная и многократно используемая конфигурация, которая определяет границы проекта. Убедившись, что ваша конфигурация не содержит выходных данных, вы можете импортировать ее куда угодно, не беспокоясь о дублированных или нежелательных стилях.

Вот несколько рекомендаций для размышлений об архитектуре:

Однако существует множество вариантов того, как люди реализуют эти идеи.

Вы также можете обнаружить, что многие фирменные системы, разработанные крупными компаниями для крупных компаний и для крупных компаний, не всегда соответствуют небольшим группам и продуктам. У каждого проекта свои требования, поэтому никогда не следует предполагать, что лучшее решение для InstaFace или MyPinBook будет лучшим решением для вас.

Объектно-ориентированный CSS (OOCSS)

OOCSS — это одна из оригинальных интерфейсных архитектур, которая послужила источником вдохновения для добавления директивы @extend в Sass. Проект Николь Салливан , в котором сделан сильный акцент на поиске правильной гранулярности для объектов CSS, тема, которая возникает в большинстве систем, которые мы рассмотрим здесь.

Салливан утверждает, что вместо того, чтобы пытаться сопоставить внутренние объекты, объект CSS должен искать более детальные шаблоны проектирования, которые могут использоваться в различных типах контента. Ярким примером является то, что она называет медиа-объектом — медиа-элемент фиксированного размера (например, изображение или видео) наряду с текучим контентом, таким как текст.

Если вы посмотрите на Facebook, который Салливан помог реорганизовать, вы увидите один дизайн медиа-объектов, используемый на сайте для отображения широкого диапазона внутренних объектов — от историй и комментариев до уведомлений, рекламных объявлений и деталей профиля. Определяя объекты на уровне детализации, можно использовать небольшое количество CSS для стилизации больших областей приложения.

В лучшем случае, OOCSS — это мощный инструмент для упрощения CSS и повышения производительности крупномасштабных приложений. Но в крайнем случае, подход OOCSS может оставить вас в беспорядке универсальных служебных классов (таких как .padding-left-10px ), которые слишком тесно связывают ваш HTML и CSS, и исключают любые возможности сопровождения, которые вы можете получить из более семантического кода. , Вы должны найти правильный баланс для каждого проекта.

Что бы вы ни делали, стоит помнить о двух основных принципах OOCSS (в действительности, о выделении памяти), пока вы разрабатываете свою собственную архитектуру:

• Отдельная структура и кожа. Имея несколько скинов дизайна (цвета, фоны, границы и т. Д.), Которые можно смешивать и сопоставлять со структурными объектами, можно добиться большего визуального разнообразия с меньшим количеством кода. На практике это также означает отделение стилей от базовой семантики тегов HTML. .primary-header классы ( .primary-header ) вместо тегов ( h2 ), вы получаете больше гибкости, чтобы поддерживать смысл HTML, применяя согласованные стили везде, где это уместно.

• Отдельный контейнер и содержимое. Объекты OOCSS не должны зависеть от их местоположения или контекста, но должны использоваться повторно и иметь возможность заполнять любой контейнер, который им предоставляется. Это гарантирует, что объект будет выглядеть одинаково в любом контексте, и разработчикам не нужно будет угадывать, что данный элемент или класс будет делать в разных ситуациях.

В OOCSS нет встроенной организационной структуры, но на GitHub есть платформа, которая предоставляет ряд общих объектов, а также документацию по настройке платформы под ваши нужды.

Атомный дизайн

Атомный дизайн также обусловлен вопросами гранулярности. Первоначально разработанный Брэдом Фростом атомный проект разбит на пять этапов: атомы, молекулы, организмы, шаблоны и страницы. Идея состоит в том, чтобы стилизовать этапы по порядку, начиная с детализации и заканчивая наружу, при этом каждая ступень строится на предыдущей.

Согласно Атомному Проекту, атомы могут быть абстрактной информацией, такой как цветовые палитры, шрифты и типографские шкалы; они также могут быть стилями по умолчанию для таких тегов, как метки форм, кнопки и абзацы. Так как я никогда не могу вспомнить научные термины, я разделяю эти две идеи дальше и называю первые «конфигурацией» или «настройками» (не имеющими выхода самостоятельно), а последние «базовыми» или «начальными» стилями ( имея выход).

Атомы могут быть соединены, чтобы сформировать молекулы . Объедините изображение с абзацем и кнопкой (все атомы), и у вас получится простая молекула со списком товаров. Молекулы — это маленькие компоненты, которые хорошо справляются с одной задачей. Сгруппируйте несколько этих молекул вместе, и вы получите организм (в данном случае, галерею продуктов). Организмы — это более крупные сгруппированные компоненты, которые образуют часть интерфейса. Баннер вашего сайта также может быть организмом, объединяющим логотип, навигацию и форму поиска. Я называю следующие два этапа «шаблонами» и «компонентами», но рекомендуется, чтобы вы работали со своей командой, чтобы найти термины, которые вы все четко понимаете.

На этом этапе разработчики Atomic Design отказываются от своей биохимической аналогии и переходят к шаблонам . Шаблоны объединяют меньшие молекулы и организмы в фактические структуры макета. Если вы запускаете новостной сайт, у вас может быть шаблон списка и подробный шаблон для ваших статей. Каждый конкретный экземпляр шаблона называется страницей . Домашняя страница и страница архива вашего новостного сайта могут использовать шаблон списка статей, но их содержание различно. Страницы являются наиболее конкретной комбинацией всех других этапов.

Стандартный каталог Atomic Design будет организован в следующие пять папок:

 sass/ | |– atoms/ | |– _colors.scss | |– _buttons.scss | … | |– molecules/ | |– _navigation.scss | |– _search.scss | … | |– organisms/ | |– _banner.scss | |– _gallery.scss | … | |– templates/ | |– _list.scss | |– _detail.scss | … | |– pages/ | |– _home.scss | |– _archive.scss | … | |- main.scss 

Атомный дизайн также предоставляет платформу под названием Pattern Lab . Как и в случае с OOCSS, не следует путать структуру с философией системы проектирования. Вы можете применять эту философию где угодно, но инструменты все еще доступны, если они вам нужны. Фреймворки могут быть отличным способом поддержания целостности кода в большой команде или проекте, но всегда помните, что вы знаете свой проект лучше, чем Брэд Фрост, Николь Салливан или авторы этой книги. Если существует конфликт между вашими потребностями и используемой платформой, всегда ставьте проект на первое место.

Блок, Элемент, Модификатор (БЭМ)

БЭМ — система, разработанная командой Яндекса . Это гораздо более обширная система, в которой заложены все аспекты вашего кода — от структур данных JSON до шаблонов и CSS.

Архитектура BEM CSS построена вокруг трех идей в своем названии. Блоки являются компонентами любого размера и могут быть вложены друг в друга. Блок header может содержать блок logo блок navigation и блок search . Блоки могут быть использованы повторно, независимы и мобильны, поэтому их можно размещать в любом месте на странице и повторять так часто, как это необходимо. Элементы — это составные части, которые принадлежат конкретному блоку. Блок menu может состоять из четырех элементов tab . Модификаторы — это флаги на блоках или элементах, которые изменяют их внешний вид, поведение или состояние.

Наиболее сразу узнаваемым аспектом синтаксиса BEM является сложное соглашение об именах, которое использует длинные имена классов вместо вложенных селекторов. Вместо того, чтобы нацеливаться на .block .element , вы .block__element бы на .block__element . Существуют различия в точном синтаксисе, но формальная документация допускает дефисы ( - ) в имени блока, элемента или модификатора; двойное подчеркивание ( __ ) между именами блоков и элементов; и одиночное подчеркивание ( _ ) перед логическим модификатором (true / false) или между именем модификатора значения ключа и его заданным значением.

Вот пример прямо из документации БЭМ, которая определяет блок form с логическим модификатором _login модификатором _theme_forest ключа _theme_forest и двумя элементами:

 <form class="form form_login form_theme_forest"> <input class="form__input"> <input class="form__submit form__submit_disabled"> </form> 

Соответствующая часть Sass будет выглядеть так:

 .form {} .form_theme_forest {} .form_login {} .form__input {} .form__submit {} .form__submit_disabled {} 

Когда имена BEM стали популярными, люди начали использовать родительский селектор Sass ( & ), чтобы автоматически генерировать имена классов BEM с меньшим количеством повторений в коде: