Советы и инструменты Sass Best Practices для разработчиков
Очень похоже на то, как jQuery революционизировал ванильный JavaScript, Sass революционизировал ванильный CSS. Большинство разработчиков, которые изучают Sass, соглашаются, что они никогда не захотят возвращаться. Многие также согласны с тем, что самая большая проблема с новыми разработчиками путь они используют Sass, а не сам Sass.
Я просмотрел сеть и скомпилировал эту статью лучшие практики для написания расширяемого и многократно используемого кода Sass. Предложения взяты из моего собственного мнения и с таких надежных сайтов, как Sass Guidelines.
Вам, конечно, не нужно внедрять все эти функции в ваш рабочий процесс. Но стоит хотя бы развлечь эти идеи и обдумать потенциальные выгоды.
Организация файлов
Лучшее место для начала разработки Sass - это организация файлов. Если вы уже знакомы с модульным кодом, вы должны понимать значение импорта и частичных значений (подробнее об этом позже).
Но пока просто взгляните на этот пример структуры файла из DoCSSa. Я воссоздал эту файловую структуру, которую вы можете увидеть ниже:
Это всего лишь предложение, и это один из многих способов организации ваших файлов. Вы можете найти другие методы, которые используют различные структуры папок, такие как “глобалы” для всей системы SCSS и “страницы” для конкретной страницы SCSS.
Давайте пройдемся по этому предлагаемому стилю организации, чтобы изучить назначение каждой папки:
- / Глобал - содержит файлы Sass, которые применяются по всему сайту, такие как типография, цвета и сетки
- /компоненты - содержит файлы Sass со стилями компонентов, такими как кнопки, таблицы или поля ввода
- / разделы - содержит файлы Sass, предназначенные для определенных страниц или областей на странице (может лучше работать в сочетании с / компонентами / папкой)
- / Utils - содержит сторонние утилиты, такие как Normalize, которые могут динамически обновляться с помощью таких инструментов, как Bower.
- main.scss - основной файл Sass в корневой папке, который импортирует все остальные.
Это просто базовая отправная точка, и есть много возможностей для расширения с вашими собственными идеями..
Но независимо от того, как вы решите организовать свою SCSS, очень важно, чтобы вы иметь какую-то организацию с отдельным файлом (или папкой) для библиотек, таких как Normalize, которые необходимо обновить, плюс компоненты в Sass partials для вашего проекта.
Sass partials жизненно важны для современной передовой практики. Они настоятельно рекомендуются командой разработчиков Zurb и многими другими профессиональными разработчиками внешнего интерфейса..
Вот цитата с сайта Sass, объясняющая особенности:
“Вы можете создать частичные файлы Sass, которые содержат небольшие фрагменты CSS, которые вы можете включить в другие файлы Sass. Это отличный способ модульный ваш CSS и помогает упростить обслуживание. Частичное - это просто файл Sass с именем, начинающимся с подчеркивания. Вы могли бы назвать это что-то вроде _partial.scss. Подчеркивание позволяет Sass знать, что файл является только частичным файлом и что его не следует создавать в файле CSS. Частицы Sass используются с @Импортировать директива.”
Также взгляните на эти посты, касающиеся структуры файлов Sass:
- Как я структурирую свои проекты Sass
- Aesthetic Sass: организация архитектуры и стиля
- Структуры каталогов, которые помогают вам поддерживать ваш код
Стратегии импорта
Недостаточно сказать о значении импорта и частичек Sass. Организация кода - это ключ к получению структуры импорта и рабочего процесса, который просто работает.
Лучше всего начать с таблицы глобальных параметров, содержащей импорт, переменные и миксины. Многие разработчики предпочитают разделять переменные и миксины, но это сводится к семантике.
Имейте в виду, что миксин способ импорта или, точнее, дублирования Sass-кода. Они невероятно мощные, но не должны использоваться с “статический” код. Имейте в виду, что есть разница между миксинами, расширениями и заполнителями, все из которых используются в разработке Sass.
Миксины лучше всего использовать с динамическими значениями, передаваемыми в миксин для изменения кода. Например, посмотрите этот миксин Sass, который создает градиент фона между двумя цветами..
@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-Градиент (вверху, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / background: -o-linear-Градиент (вверху, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / background: -ms-linear-Градиент (сверху, $ сверху 0%, $ снизу 100%); / * IE10 + * / background: линейный градиент (внизу, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /
Миксин принимает два значения: верхний цвет и нижний цвет. Вы можете написать разные миксины для разных типов градиентов, которые включают в себя 3 или 4 + разных цветов. Это позволяет импортировать и клонировать миксин-код при изменении параметров для пользовательских параметров..
Пример из Code Responsible выглядит следующим образом:
.button @include linearGradient (#cccccc, # 666666);
С миксином связан заполнитель Sass, который в первую очередь полезен с помощью директивы расширения. По общему признанию, он более сложный, чем миксин, но это может быть способом объединить селекторы вместе без переписывания лишнего кода.
Хотя в Sass есть только один метод @import, я включил миксины и заполнители, чтобы продемонстрировать гибкость кода, который можно написать в одном файле, но включить куда угодно.
При построении структуры импорта просто не забывайте следовать принципам СУХОГО кодирования (не повторяйте себя).
Соглашения об именах
Общие правила для соглашений об именах применяются к переменным, функциям и миксинам. При именовании чего-либо в Sass рекомендуется используйте все строчные буквы с тире для разделения.
Синтаксис кода Sass фактически основан на наборе правил CSS. Вот некоторые рекомендуемые рекомендации, которые следует иметь в виду:
- два (2) пробела, отступы отсутствуют
- в идеале, строки шириной 80 символов или менее
- осмысленное использование пробелов
- используйте комментарии для объяснения операций CSS
Это не обязательные элементы для действительного кода Sass. Но эти предложения приходят от профессиональных разработчиков, которые обнаружили, что эти наборы правил обеспечивают наиболее единообразный опыт кодирования.
Но в отношении соглашений об именах вы можете получить две разные структуры: одну для имен Sass и другую для имен классов CSS. Некоторые разработчики предпочитают БЭМ, а не предложения Sass. Ни один из них не является более или менее правильным; просто разные с разными операционными процедурами.
Проблема в том, что БЭМ плохо переносится на переменные или миксины Sass, потому что они не имеют структуры блок / элемент / модификатор (БЭМ). Лично я предпочитаю использовать соглашения о присвоении имен Sass, но вы можете попробовать все, что угодно, от camelCase до собственного внутреннего синтаксиса.
При организации ваших переменных и миксинов рекомендуется разделите их по категориям, затем перечислите в алфавитном порядке. Это значительно упрощает редактирование, потому что вы точно знаете, где что-то найти.
Например, чтобы изменить цвет ссылки, откройте файл переменных (возможно, _variables.scss) и найдите раздел для цветовых переменных. Затем найдите ссылку по имени (ссылка на заголовок, текстовую ссылку и т. Д.) И обновите цвет. просто!
Чтобы получить представление о том, как вы можете структурировать оглавление для ваших файлов Sass, посмотрите файл настроек Foundation.
// Основа для настройки сайтов // ----------------------------- // // Содержание: // // 1 . Global // 2. Точки останова // 3. Сетка // 4. Базовая типография // 5. Помощники типографики… // 1. Global // --------- $ 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 чистый и пригоден для повторного использования.
- Используйте вложение, когда это имеет смысл, а не как вариант по умолчанию.
Разработчик Джош Бротон (Josh Broton) предлагает в случае необходимости вкладывать отступ, а в остальное - в качестве общего правила синтаксиса..
Отступы селекторов не вызовут каскадных эффектов CSS. Но вам будет легче просматривать Sass-файл, определяя, какие классы связаны друг с другом..
Петли могут также быть чрезмерным, если не применяется должным образом. Три петли Сасса @за, @в то время как, а также @each. Я не буду вдаваться в подробности о том, как они все работают, но если вам интересно, посмотрите этот пост.
Вместо этого я хотел бы покрыть цель использования петель и как они функционируют в Sass. Их следует использовать для экономии времени при написании кода, который можно автоматизировать. Например, вот фрагмент кода из сообщения Clubmate, показывающий некоторый код Sass с последующим выводом:
/ * Код Sass * / @for $ i от 1 до 8 $ width: процент (1 / $ i) .col - # $ i width: $ width; / * output * / .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%;
Эти классы столбцов можно использовать вместе с сеткой. Вы можете даже добавить больше столбцов или удалить некоторые, просто отредактировав код цикла.
Loops должен не использоваться для дублирования селекторов или свойств для селектора; это то, что миксин для.
Также при зацикливании есть нечто, называемое Sass-картами, в котором хранятся пары ключ-значение. Опытные пользователи должны использовать их по возможности.
Но обычные циклы Sass просты и эффективны для обеспечения вывода кода без повторений. Лучшая причина для использования петель с Свойства CSS, которые изменяют вывод данных.
Вот хороший способ проверить, полезен ли ваш цикл: спросите себя если есть какой-либо другой способ вывести CSS, который вам нужен, с меньшим количеством строк кода. Если нет, то синтаксис цикла, вероятно, отличная идея.
Если вы когда-нибудь запутались или хотите получить отзывы о вложенности или циклах Sass, вы должны опубликовать вопрос в / r / sass / или / r / css /, активных сообществах Reddit с очень хорошо осведомленными разработчиками Sass..
Модульность
Практика написания модульного Sass является абсолютной необходимостью для большинства проектов (я бы сказал, каждый проект). Модуляризация - это процесс разбить проект на более мелкие модули. Это можно сделать с помощью Sass обертоны.
Идея модульного Sass заключается в написании отдельных файлов SCSS с определенной целью, предназначенных для глобального контента (типография, сетки) или элементов страницы (вкладки, формы).
Определение модуля Sass довольно ясно и дает очень конкретное предложение: импорт модуля никогда не должен выводить код.
Идея обязательного вывода для всех модулей была бы кошмаром для оптимизации. Вместо этого вы должны создавать модули индивидуально и звоните только те, которые вам нужны. Модули могут быть определены с помощью миксинов или функций, но можно создавать модули, которые также содержат селекторы.
Однако статья Sass Way предлагает писать все селекторы как миксины и вызывать их только по мере необходимости. Принимаете ли вы это или нет, в конечном итоге ваш выбор. Я думаю, что это зависит от размера проекта и вашего удобства работы с миксином..
Цитирую Джона Лонга из его поста о Sass Way:
“Для меня модули стали основными единицами или строительными блоками моих проектов Sass.”
Если вы действительно ищете рутину Sass, я рекомендую использовать полностью модульную систему. Попробуйте построить почти все как модульную часть, которая будет включена в основной файл CSS. Сначала этот рабочий процесс может показаться пугающим, но он имеет смысл в более широком масштабе - особенно в больших проектах.
Кроме того, гораздо проще копировать модули из одного проекта в другой, если они расположены в отдельных файлах.. гибкость а также код многократного использования являются краеугольными камнями модульного развития.
Чтобы узнать больше о модулях Sass и методах модульности, ознакомьтесь со следующими статьями:
- CSS-модули: добро пожаловать в будущее
- Плюсы и минусы модульной Sass
- Модульная организация CSS с SMACSS & SASS
Найдите свой идеальный рабочий процесс
У каждой команды и отдельного разработчика есть свои собственные методы, которые работают лучше всего. Вы должны принять методы, которые работают лучше всего для вас лично, или выбрать те, которые лучше всего работают для вашей команды профессионально.
Также рассмотрите возможность использования Gulp или Grunt для автоматизации проекта и минимизации вашего кода. Это позволит сэкономить много ручного труда, и инструменты автоматизации теперь, несомненно, являются частью лучших практик для разработки современного интерфейса..
Пролистайте библиотеки с открытым исходным кодом, такие как SCSS Foundation на GitHub, чтобы узнать больше о лучших практиках, используемых другими библиотеками..
Суть лучших практик в том, что они действительно улучшают вашу работу большую часть времени, но есть много альтернатив. Просто попробуйте вещи и посмотрите, что они чувствуют. Вы всегда будете учиться, поэтому ваши лучшие практики могут быстро измениться в течение 5 лет.
Последнее предложение, которое у меня есть для всего процесса Sass: принимать решения с ясностью. Напишите код, который облегчит вашу работу. Не усложняйте проект, если есть более простой способ сделать это.
Sass предназначен для улучшения опыта разработки CSS, поэтому работать с ясностью и лучшими практиками чтобы получить наилучший опыт.
Заворачивать
Перегрузка в рабочем процессе Sass может быть исправлена путем настройки стилей кода и следуя лучшим рекомендациям. В этом посте я изложил несколько предложений от блогов Sass и профессиональных разработчиков..
Лучший способ узнать больше - применить эти методы в своем рабочем процессе и посмотрим, что работает. Со временем вы обнаружите, что некоторые виды деятельности более полезны, чем другие, и в этом случае вам следует оставь все, что работает, и брось, что не.
Воспользуйтесь этими ссылками, чтобы найти больше советов и рекомендаций по разработке Sass:
- Sass Guidelines
- Видение нашего нахала
- 8 советов, которые помогут вам получить максимум от Sass
- Расширение в Sass без создания беспорядка
- Sass Best Practices - Вложение более 3-х уровней
