Sass Best Practices: советы и инструменты для разработчиков

Примечание редактора: эта статья является частью нашей серии «Оптимизация кода», в которой мы рассмотрим, как оптимизировать кодирование для повышения эффективности в стремлении стать лучшими программистами.

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

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

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

Подробнее: начните с SASS с этим руководством

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

Но пока просто взгляните на этот пример структуры файла из DoCSSa. Я воссоздал эту файловую структуру, которую вы можете увидеть ниже:
Это всего лишь предложение, и это один из многих способов организации ваших файлов. Ты можешь найти другие методы которые используют различные структуры папок, такие как «глобальные» для SCSS всего сайта и «страницы» для SCSS для конкретных страниц.

Давайте пройдемся по этот предложенный стиль организации изучить назначение каждой папки:

• / globals – содержит файлы Sass, которые применяются по всему сайту, такие как типография, цвета и сетки.
• / component – содержит файлы Sass со стилями компонентов, такими как кнопки, таблицы или поля ввода
• / section – содержит файлы Sass, предназначенные для определенных страниц или областей на странице (может лучше работать в сочетании с / компонентами / папкой)
• / utils – содержит сторонние утилиты, такие как Normalize, которые можно динамически обновлять с помощью таких инструментов, как Беседка,
• main.scss – основной файл Sass в корневой папке, который импортирует все остальные.

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

Но независимо от того, как вы решите организовать свою SCSS, очень важно, чтобы у вас была какая-то организация с отдельным файлом (или папкой) для библиотек, таких как Normalize, которые необходимо обновить, плюс компоненты в Sass partials для вашего проекта.

Sass partials жизненно важны для современной передовой практики. Это настоятельно рекомендуется Команда дизайнеров Zurb и многими другими профессиональными разработчиками внешнего интерфейса.

Вот цитата из сайт Sass объясняя частичные:

«Вы можете создавать частичные файлы Sass, которые содержат небольшие фрагменты CSS, которые вы можете включить в другие файлы Sass. Это отличный способ модульности вашего CSS и облегчения обслуживания. Частичное – это просто файл Sass с именем, начинающимся с подчеркивания. Вы можете назвать это как _partial.scss. Подчеркивание позволяет Sass знать, что файл является только частичным файлом и что его не следует создавать в файле CSS. Частицы Sass используются с директивой @import ».

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

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

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

Подробнее: 11 библиотек Sass mixin для дизайнеров

Миксины лучше всего использовать с динамическими значениями, передаваемыми в миксин для изменения кода. Например, проверьте это Sass Mixin это создает градиент фона между двумя цветами.
@mixin linearGradient ($ top, $ bottom) {
    фон: $ top; / * Старые браузеры * /
    background: -moz-linear-Gradient (сверху, $ сверху 0%, $ снизу 100%); / * FF3.6 + * /
    background: -webkit-градиент (линейный, слева вверху, слева внизу, color-stop (0%, $ top), color-stop (100%, $ bottom)); / * Chrome, Safari4 + * /
    background: -webkit-linear-Gradient (сверху, $ сверху 0%, $ снизу 100%); / * Chrome10 +, Safari5.1 + * /
    фон: -o-линейный градиент (верх, $ top 0%, $ bottom 100%); / * Опера 11.10+ * /
    фон: -ms-линейный градиент (верх, $ top 0%, $ bottom 100%); / * IE10 + * /
    фон: линейный градиент (внизу, $ top 0%, $ bottom 100%); / * W3C * /
    фильтр: progid: DXImageTransform.Microsoft.gradient (startColorstr = ‘# ffffff’, endColorstr = ‘# 000000’, GradientType = 0); / * IE6-9 * /
}
Миксин принимает два значения: верхний цвет и нижний цвет. Вы можете написать разные миксины для разных типов градиентов, которые включают 3 или 4 + разных цветов. Это позволяет вам импортировать и клонировать смешанный код, изменяя параметры для пользовательских параметров.

Пример из Ответственный за код выглядит так:
.button {
    @include linearGradient (#cccccc, # 666666);
}
С миксином связано Sass ’ заполнитель что в первую очередь полезно с продлить директиву, По общему признанию, он более сложный, чем миксин, но это может быть способом объединения селекторов вместе без переписывания лишнего кода.

Пока у Сасса только один @Импортировать метод, я включил миксины и заполнители, чтобы продемонстрировать гибкость кода, который может быть написан в одном файле, но включен где угодно.

При построении структуры импорта просто не забывайте следовать принципам СУХОЕ кодирование (Не повторяйте себя).
Соглашения об именах
Общие правила для соглашения об именах применять к переменным, функциям и миксинам. При именовании чего-либо в Sass для разделения рекомендуется использовать все строчные буквы с тире.

Синтаксис кода Sass на самом деле основан на Правила CSS набор правил. Вот некоторые рекомендуемые рекомендации, о которых следует помнить:

• два (2) пробела, отступы отсутствуют
• в идеале, строки шириной 80 символов или менее
• осмысленное использование пробелов
• используйте комментарии для объяснения операций CSS

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

Но в отношении соглашений об именах вы можете получить две разные структуры: одну для имен Sass и другую для имен классов CSS. Некоторые разработчики предпочитают BEM За нахальный предложения. Ни один из них не является более или менее правильным; просто разные с разными операционными процедурами.

Узнайте больше о BEM здесь: Понимание методологий написания CSS

Проблема в том, что БЭМ плохо переносит переменные или миксины Sass, потому что у них нет структуры блок / элемент / модификатор (БЭМ). Лично я предпочитаю использовать соглашения о присвоении имен Sass, но вы можете попробовать что угодно верблюжьего к вашему собственному внутреннему синтаксису.

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

Например, чтобы изменить цвет ссылки, откройте файл переменных (возможно, _variables.scss) и найдите раздел для переменных цвета. Затем найдите ссылку по имени (ссылка на заголовок, текстовую ссылку и т. Д.) И обновите цвет. Просто!

Чтобы получить представление о том, как вы можете структурировать оглавление для ваших файлов Sass, посмотрите Файл настроек Фонда,

// Основы для настройки сайтов
// —————————–
//
// Оглавление:
//
// 1. Глобальный
// 2. Точки останова
// 3. Сетка
// 4. Базовая типография
// 5. Типографские помощники
…
// 1. Глобальный
// ———

$ global-font-size: 100%;
$ global-width: rem-calc (1200);
$ global-lineheight: 1,5;
// так далее
Другая практика именования относится к отзывчивым контрольным точкам. При именовании Sass точки останова, попробуйте избежать конкретных имен устройств. Лучше писать такие имена, как small, med, lg и xlg, потому что они относятся друг к другу.

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

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

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

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

Вложенность – это процесс добавления селекторов, вложенных вместе с помощью отступов, для создания большей специфичности с меньшим количеством кода. У Sass есть руководство по вложениям, которое иллюстрирует примеры вложения кода в действие. Но с вложением легко увлечься. Если вы слишком усердны, вы можете получить код, который выглядит следующим образом:
body div.content div.container {…}
body div.content div.container div.articles {…}
body div.content div.container div.articles> div.post {…}

Этот тип кода слишком специфичен и почти невозможен для перезаписи. Он не отвечает требованиям каскадных таблиц стилей.

Скольжение это руководство SitePoint Вы найдете три золотых правила для вложения:

• Никогда не заходите глубже, чем на 3 уровня.
• Убедитесь, что вывод CSS чистый и пригоден для повторного использования.
• Используйте вложение, когда это имеет смысл, а не как вариант по умолчанию.

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

Отступы в селекторах не вызовут каскадных эффектов CSS. Но вам будет легче просматривать Sass-файл, определяя, какие классы связаны друг с другом.

Циклы также могут быть чрезмерно использованы, если не применяются должным образом. Три цикла Sass – это @for, @ while и @each. Я не буду вдаваться в подробности о том, как все они работают, но если вам интересно проверить этот пост,

Вместо этого я хотел бы рассказать о цели использования циклов и о том, как они работают в Sass. Их следует использовать для экономии времени при написании кода, который можно автоматизировать. Например, вот фрагмент кода из Почта одноклубника показывая некоторый код Sass с последующим выводом:
/ * Sass код * /
@for $ i от 1 до 8 {
    $ ширина: процент (1 / $ i)

    .col – # {$ i} {
        ширина: $ ширина;
    }
}

/* вывод */
.col-1 {ширина: 100%;}
.col-2 {ширина: 50%;}
.col-3 {ширина: 33,333%;}
.col-4 {ширина: 25%;}
.col-5 {ширина: 20%;}
.col-6 {ширина: 16,666%;}
.col-7 {ширина: 14,285%;}
.col-8 {ширина: 12,5%;}
Эти классы столбцов могут использоваться вместе с сеткой. Вы можете даже добавить больше столбцов или удалить некоторые, просто отредактировав код цикла.

Петли должны не использоваться для дублирования селекторов или свойств для селектора; для этого и нужны миксины.

Также при цикле есть что-то под названием Sass карты этот магазин ключ: пары значений данных. Опытные пользователи должны использовать их по возможности.

Но обычные петли Sass просто и эффективно при обеспечении вывода кода без повторов. Лучшая причина для использования циклов – свойства CSS, которые изменяют вывод данных.

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

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

Идея модульного Sass заключается в написании отдельных файлов SCSS с определенной целью, ориентированных на глобальный контент (типография, сетки) или элементы страницы (вкладки, формы).

Определение модуля Sass довольно ясно и дает очень конкретное предложение: импорт модуля никогда не должен выводить код.

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

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

Цитируя Джона Лонга из его пост на пути Sass:

«Для меня модули стали основными единицами или строительными блоками моих проектов Sass».

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

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

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

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

Просматривайте библиотеки с открытым исходным кодом, такие как Фонд SCSS на GitHub, чтобы узнать больше о лучших практиках, используемых другими библиотеками.

Суть лучших практик в том, что они действительно улучшают вашу работу большую часть времени, но есть много альтернатив. Просто попробуйте вещи и посмотрите, что они чувствуют. Вы всегда будете учиться, поэтому ваши лучшие практики могут быстро измениться в течение 5 лет.

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

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

Подробнее: Простой и легкий гид по Uunderstand Sass

Заворачивать
Перегрузка в рабочем процессе Sass может быть исправлена ​​путем настройки стилей кода и следуя лучшим рекомендациям. В этом посте я изложил несколько предложений от блогов Sass и профессиональных разработчиков.

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

Воспользуйтесь этими ссылками, чтобы найти больше советов и рекомендаций по разработке Sass: