Sass Кращі практики Поради та інструменти для розробників

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

Я розібрався в Інтернеті і зібрав цю статтю найкращі методи написання розширюваного та багаторазового коду Sass. Пропозиції стосуються моїх власних думок та надійних веб-сайтів, таких як Sass Guidelines.

Ви, звичайно, не повинні виконувати всі ці функції у вашому робочому процесі. Але варто хоча б розважати ці ідеї і розглянути потенційні вигоди.

Організація файлів

Найкращим місцем для початку розвитку Sass є організація файлів. Якщо ви вже перебуваєте в модульному коді, ви повинні розуміти значення імпорту та часткових (більше про них пізніше).

Але поки що просто погляньте на цей приклад файлової структури з DoCSSa. Я знову створив цю структуру файлів, яку можна переглянути нижче:

Це лише пропозиція, і це один з багатьох способів організації файлів. Ви можете знайти інші методи, які використовують різні структури папок “глобал” для SCSS і “сторінок” для специфічної для сторінки SCSS.

Пройдіться цим запропонованим стилем організації, щоб вивчити призначення кожної папки:

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

Це лише основна відправна точка, і є багато можливостей для розширення власних ідей.

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

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

Ось цитата з веб-сайту Sass, що пояснює частково:

“Можна створити часткові файли Sass, які містять невеликі фрагменти CSS, які можна включити в інші файли Sass. Це відмінний спосіб модулюйте свій CSS і допоможіть зберегти речі простіше. Частковий - це просто файл Sass, названий головним підкресленням. Ви можете назвати це щось подібне _partial.scss. Підкреслення дозволяє Sass знати, що файл є лише частковим файлом і що він не повинен генеруватися у файлі CSS. Sass частки використовуються з @import директиви.”

Ознайомтеся з іншими повідомленнями щодо структури файлів Sass:

• Як структурувати проекти Sass
• Естетична освіта: організація архітектури та стилю
• Структури каталогів, які допомагають підтримувати свій код

Імпортні стратегії

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

Найкращим місцем для початку є таблиця globals, що містить імпорт, змінні та міксини разом. Багато розробників вважають за краще розділяти змінні і міксини, але це зводиться до семантики.

Майте на увазі, що суміші спосіб імпортування, а точніше, копіювання коду Sass. Вони неймовірно потужні, але не повинні використовуватися “статичний” код. Майте на увазі, що різниця між mixins, extends і заполнителями, які використовуються в розробці Sass.

Mixins найкраще використовувати з динамічними значеннями, що передаються в mixin для зміни коду. Наприклад, ознайомтеся з цим Sass mixin, який створює фоновий градієнт між двома кольорами.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Старі браузери * / background: -moz-linear-gradient (зверху, $ top 0%, $ bottom 100%); / * FF3.6 + * / background: -webkit-gradient (лінійний, лівий верхній, лівий нижній, колір-стоп (0%, $ top), колір-стоп (100%, $ bottom)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (зверху, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / background: -o-лінійний градієнт (верхній, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (зверху, $ top 0%, $ bottom 100%); / * IE10 + * / background: лінійний градієнт (донизу, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin приймає два значення: верхній колір і нижній колір. Ви можете написати різні міксини для різних типів градієнтів, які включають 3 або 4 різних кольорів. Це дозволяє імпортувати та клонувати код mixin, змінюючи параметри користувацьких параметрів.

Приклад з Code Responsible виглядає так:

.кнопка @include linearGradient (#cccccc, # 666666); 

Пов'язаний з mixin є Sass 'замінник, який в першу чергу корисно з розширенням директиви. Це, звичайно, більш складне, ніж mixins, але це може бути шлях об'єднуйте селектори, не переписуючи зайвий код.

Хоча у Sass є лише один метод @import, я включив міксини та заповнювачі, щоб продемонструвати гнучкість коду, який можна записати в один файл, але містити в будь-якому місці.

При створенні структури імпорту просто не забувайте дотримуватися концепцій кодування DRY (не повторювати себе).

Умовні позначення

Загальні правила для іменних угод застосовуються до змінних, функцій і міксинів. При іменуванні нічого в Sass рекомендується використовувати всі малі літери з тире для розділення.

Синтаксис коду Sass фактично базується на наборі правил CSS. Нижче наведено деякі рекомендовані кращі практики:

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

Це не потрібні елементи для дійсного коду Sass. Але ці пропозиції походять від професійних розробників виявили, що ці набори правил забезпечують найбільш рівномірний досвід кодування.

Але щодо угод про іменування ви можете отримати дві різні структури: одну для імен Sass, а іншу для імен класів CSS. Деякі розробники віддають перевагу BEM над пропозиціями Sass. Жоден з них не є більш чи менш правильним; просто відрізняється від різних операційних процедур.

Проблема полягає в тому, що BEM не переносить добре на змінні Sass або mixins, тому що вони не мають структуру block / element / modifier (BEM). Я особисто вважаю за краще використовувати Sass іменування, але ви можете спробувати що-небудь від camelCase до вашого власного внутрішнього синтаксису.

При організації змінних і міксінів рекомендується поділіть їх за категоріями, а потім перелічіть їх в алфавітному порядку. Це робить редагування набагато простішим, тому що ви точно знаєте, де щось знайти.

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

Щоб отримати уявлення про те, як можна структурувати зміст для файлів Sass, перевірте файл налаштувань Фонду.

 // Фундаментальні параметри сайтів // ----------------------------- // // Зміст: // // 1 Глобальна // 2. Точки зупинки // 3. Сітка // 4. Базова типографія // 5. Типографіка Helpers… // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // і т.д.

Інша практика іменування стосується відповідні контрольні точки. При назві точок зупинки Sass, намагайтеся уникати імен, специфічних для пристрою. Краще писати імена, такі як малі, med, lg і xlg, тому що вони відносно один одного.

Це краще для внутрішніх взаємозв'язків між точками розриву, але також чудово підходить для команд, де розробники можуть не знати, які пристрої пов'язані один з одним.

Що стосується власне написання імен, то вам рекомендується бути якомога більш конкретними без надмірних змінних. Ти повинен прийняти загальноприйняті угоди про імена, які легко запам'ятати під час кодування.

Вкажіть конкретні правила назв для всіх, як кольори, поля, стеки шрифтів і висоти рядків. Імена можна не тільки швидко згадати, але й полегшує роботу з написанням нових імен змінних, які повинні відповідати існуючому синтаксису.

Але є тонка грань між специфікою і згорткою. Практика допоможе вам знайти цю лінію, а написання більш пам'ятних імен полегшує копіювання коду в інші проекти.

Вкладання і цикли

Ці дві методи Sass дуже різні в дії, але обидва мають здатність бути зловживаною, якщо вона не використовується ретельно.

Вкладання є процес додавання селекторів, вкладених разом через відступ, для створення більшої специфічності з меншим кодом. У Sass є вказівка ​​про вкладання, яка ілюструє приклади вкладеності коду в дію. Але легко захоплюватися гніздуванням. Якщо ви перестараєтеся, ви можете отримати код, який виглядає так:

body div.content div.container … тіло div.content div.container div.articles … тіло div.content div.container div.articles> div.post … 

Занадто специфічний і майже неможливо переписати, цей тип коду перемагає призначення каскадних таблиць стилів.

Переглядаючи цей посібник, ви знайдете три золоті правила для вкладеності:

• Ніколи не переходьте на більш ніж 3 рівні.
• Переконайтеся, що вивід CSS є чистим і багаторазовим.
• Використовуйте вкладеності, якщо це має сенс, а не як варіант за замовчуванням.

Розробник Джош Бротон пропонує вкладенню, коли це необхідно, відступ решти як загальне правило синтаксису.

Відступ ваших селекторів не призведе до каскадних ефектів CSS. Але вам буде простіше зняти файл Sass, визначивши, які класи відносяться один до одного.

Петлі також можуть бути зловживанням, якщо не застосовується належним чином. Три петлі Sass є @for, @while, і @each. Я не буду вдаватися в подробиці про те, як всі вони працюють, але якщо ви зацікавлені перевірити цю посаду.

Замість цього я хотів би охопити призначення для використання петель і як вони функціонують у Sass. Вони повинні використовуватися для економії часу написання коду, який можна автоматизувати. Наприклад, ось фрагмент коду з повідомлення Clubmate, який показує код Sass, за яким йде вивід:

/ * Код Sass * / @ для $ i від 1 до 8 $ width: процент (1 / $ i) .col - # $ i width: $ width;  / * вихід * / .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%;

Ці класи стовпців можуть використовуватися разом з сітковою системою. Ви навіть можете додати більше стовпців або видалити деякі лише шляхом редагування коду циклу.

Петлі слід ні використовувати для дублювання селекторів або властивостей селектора; це те, для чого є mixins.

Крім того, при циклічному перекладі є те, що називається картами Sass, які зберігають пари ключів: значення. Просунуті користувачі повинні користуватися цими можливостями, коли це можливо.

Але звичайні петлі Sass є простими і ефективними при забезпеченні виведення коду без повторення. Найкращою причиною для використання циклів є Властивості CSS, які змінюють вихід даних.

Ось хороший спосіб перевірити, чи ваш цикл корисний: запитайте себе якщо є інший спосіб вивести потрібний CSS з меншим числом рядків коду. Якщо ні, то синтаксис циклу, ймовірно, є чудовою ідеєю.

Якщо ви коли-небудь плутаєтеся або хочете отримати відгук про вкладеності або петлі Sass, ви повинні опублікувати запитання в / r / sass / або / r / css /, активних спільнотах Reddit з дуже відомими розробниками Sass.

Модуляризація

Практика написання модульного Sass є абсолютною необхідністю для більшості проектів (я вважаю, кожен проект). Модуляризація - це процес розбиття проекту на менші модулі. Це можна зробити за допомогою Sass часткові.

Ідея модульного Sass полягає в тому, щоб писати окремі файли SCSS з певною метою, орієнтованої на глобальний вміст (типографіка, сітки) або елементи сторінки (вкладки, форми).

Визначення модуля Sass досить чіткий і робить дуже специфічну пропозицію: імпорт модуля ніколи не повинен виводити код.

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

Однак стаття Sass Way пропонує писати всі селектори як міксини і лише закликати їх у міру необхідності. Якщо ви приймаєте це чи ні, це, нарешті, ваш вибір. Я думаю, що це залежить від розміру проекту та вашого комфорту з обробкою сумішей.

Цитуючи Джона Лонга з посади на The Sass Way:

“Для мене модулі стали базовими одиницями або складовими моїх проектів Sass.”

Якщо ви дійсно шукаєте рутину Sass, я рекомендую повністю модульний. Спробуйте побудувати практично все як модульну частку, яка входить до основного файлу CSS. Спочатку цей робочий процес може здатися складним, але він має сенс у великих масштабах - особливо у великих проектах.

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

Щоб дізнатися більше про модулі Sass та методи модуляції, ознайомтеся з цими повідомленнями:

• Модулі CSS: Ласкаво просимо в майбутнє
• Плюси і мінуси модульного Sass
• Модульна організація CSS з SMACSS & SASS

Знайдіть ідеальний робочий процес

Кожна команда та окремий розробник мають свої власні практики, які працюють краще. Ви повинні застосовувати практику, яка найкраще підходить для вас особисто, або вибирати ті, які найкраще працюють для вашої команди професійно.

Також розгляньте можливість використання Gulp або Grunt для автоматизації проекту та мінімізації коду. Це дозволить заощадити багато ручної праці, а засоби автоматизації тепер, безсумнівно, є частиною кращих практик для сучасних розробок.

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

Найкраща практика полягає в тому, що більшість часу вони дійсно покращують вашу роботу, але є багато альтернатив. Просто спробуйте і подивіться, як вони себе почувають. Ви завжди будете вчитися, щоб ваші найкращі практики швидко змінювалися протягом 5 років.

Один остаточний варіант, який я маю для всього процесу Sass, - це приймати рішення з ясністю. Пишіть код, який полегшує вашу роботу. Не надто ускладнюйте проект, якщо є простіший спосіб зробити це.

Sass покликаний підвищити досвід розробки CSS працювати з ясністю та найкращими практиками щоб отримати найкращий досвід.

Підведення підсумків

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

Найкращий спосіб дізнатися більше - це застосувати ці практики до робочого процесу подивитися, що працює. З часом ви побачите, що деякі заходи більш вигідні, ніж інші, і в цьому випадку вам слід тримайте все, що працює, і викидайте те, що ні.

Перегляньте ці посилання, щоб знайти додаткові поради та найкращі практики для розробки Sass:

• Керівництво Sass
• Бачення нашого Сасса
• 8 порад, які допоможуть вам отримати найкраще з Sass
• Розширення в Sass без створення Mess
• Sass Best Practices - Вкладання більш ніж на 3 рівні