Два умных способа организации структуры Sass

Источник: «2 smartest ways to structure SASS»
В зависимости от размера проекта над которым вы работаете, вы можете структурировать Sass двумя способами: простым для небольших и более сложным для крупных проектов.

Sass - дополнительная рука CSS; фактор мощности который придаёт элегантность вашему коду.

В Sass всё сводится к переменным, вложенности, миксинам, фрагментам, импорту, наследованию и управляющим директивам. Sass делает ваш код более удобным в обслуживании и многократном использовании.

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

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

Типы структур каталогов Sass

Вы можете использовать несколько различных структур каталогов Sass. Я предпочитаю использовать две — простую и более сложную организацию фалов Sass. Давайте их рассмотрим.

Простая структура каталогов Sass

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

Ещё один пример простой структуры Sass файлов для небольшого проекта:

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

Зачем использовать эту структуру

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

Во-вторых, эту структуру намного проще поддерживать, поскольку существует только один файл.

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

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

Структура каталогов 7-1

Название этой структуры каталогов Sass происходит от 7 каталогов и 1 файла. Многие используют эту организацию файлов Sass, так как она считается хорошей основой для больших проектов. Всё, что вам нужно сделать — организовать фрагментированные файлы в семи разных папках, и один файл (app.sass) должен находится в корне, обрабатывая импорты. Вот пример:

sass/
|
|- abstracts/
| |- _mixins // Sass Mixins Folder
| |- _variables.scss // Sass Variables
|
|- core/
| |- _reset.scss // Reset
| |- _typography.scss // Typography Rules
|
|- components/
| |- _buttons.scss // Buttons
| |- _carousel.scss // Carousel
| |- _slider.scss // Slider
|
|- layout/
| |- _navigation.scss // Navigation
| |- _header.scss // Header
| |- _footer.scss // Footer
| |- _sidebar.scss // Sidebar
| |- _grid.scss // Grid
|
|- pages/
| |- _home.scss // Home styles
| |- _about.scss // About styles
|
|- sections/ (or blocks/)
| |- _hero.scss // Hero section
| |- _cta.scss // CTA section
|
|- vendors/ (if needed)
| |- _bootstrap.scss // Bootstrap
|
- app.scss // Main Sass file

В каталоге abstract Sass файл с переменными, подкаталог с миксинами и подобными компонентами.

В core содержится типографика, сбросы и шаблонный код, которые используются во всём проекте. После создания этого кода, его дальнейшая перезапись не требуется.

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

В layout хранятся стили необходимые для макета сайта, такие как хедер и футер.

Pages содержит стили для отдельных страниц. Почти каждая страница содержит стили, которые должны использоваться только на этой конкретной странице.

Для каждой <section>, что бы её было проще повторно использовать существует каталог section или blocks. Кроме того, важно иметь этот каталог, что бы вам не приходилось искать, находится ли конкретный код в файлах home.sass или about.sass в каталоге pages.

Хорошей идеей будет поместить каждую секцию в отдельный Sass файл. Таким образом если у вас есть две секции hero, разместите их код в одном файле. Если вы будете следовать этому шаблону, большинство файлов будет в этом каталоге.

Vendors предназначен для фреймворков, поэтому если вы используете их в своём проекте создайте этот каталог.

В качестве основного файла я рекомендую использовать app.sass. Он должен выглядеть, примерно, так:

// Abstract files
@import "abstracts/all";

// Vendor Files
@import "vendor/bootstrap.scss";

// Core files
@import "core/all";

// Components
@import "components/all";

// Layout
@import "layout/all";

// Sections
@import "sections/all";

// Pages
@import "pages/all";

Вместо того, что бы импортировать множество Sass файлов, создайте _all.sass в каждой папке. Каждый _all.sass должен содержать импорты всех используемых Sass файлов этого каталога.

Организация

Самым большим преимуществом этой структуры является организация файлов Sass. Вы всегда знаете, где искать, если нужно что-то изменить. Например, вы хотите изменить отступ в секции или блоке, вы переходите непосредственно в каталог sections или blocks (в зависимости от того, как вы его назвали). Вам не нужно искать в каком Sass файле находиться нужный класс.

Упрощение

Когда код структурирован, процесс разработки упрощается. Он оптимизирован, и каждый сегмент кода расположен на своём месте.

Заключение

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

Дополнительные материалы

Предыдущая Статья

Git: Руководство по исправлению ошибок (Часть 2)

Следующая Статья

Laravel: Как создать функцию хелпер