Sass Най-добри практики Съвети и инструменти за разработчици

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

Прегледах мрежата и съставих тази статия най-добри практики за писане на разширяем и повторно използваем код на Sass. Предложения са от моите собствени мнения и от надеждни уебсайтове като Sass Guidelines.

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

Организация на файла

Най-доброто място да започнете с развитието на Sass е файловата организация. Ако вече сте в модулен код, трябва да разберете стойността на вноса и частичните (повече за тях по-късно).

Но за сега просто погледнете този пример за структурата на файла от DoCSSa. Пресъздадохме тази файлова структура, която можете да видите по-долу:

Това е само предложение и това е един от многото начини да организирате файловете си. Можете да намерите други методи, които използват различни структури на папки “глобални” за SCSS и за целия сайт “страници” за специфична за страницата SCSS.

Нека да преминем през този предложен стил на организация, за да разгледаме целта на всяка папка:

• / глобални - съдържа Sass файлове, които се прилагат за целия сайт като типография, цветове и мрежи
• / компоненти - съдържа Sass файлове със стилове на компоненти като бутони, таблици или полета за въвеждане
• / секции - съдържа Sass файлове, предназначени за конкретни страници или области на страница (може да работи по-добре в папката / components /)
• / UTILS - съдържа помощни програми на трети страни като Normalize, които могат да се актуализират динамично с инструменти като Bower.
• main.scss - основния файл Sass в главната папка, който импортира всички останали.

Това е само основна отправна точка и има много място за разширяване с вашите собствени идеи.

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

Sass parts са жизненоважни за съвременните най-добри практики. Те са силно препоръчани от дизайнерския екип на Zurb и от много други професионални разработчици.

Ето цитат от уебсайта на Sass, в който се обясняват частици:

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

Също така разгледайте тези други публикации относно Sass файловата структура:

• Как структурирам проектите си
• Естетичен Сас: Организация на архитектурата и стила
• Структури на директории, които ви помагат да поддържате вашия код

Стратегии за внос

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

Най-доброто начало е с глобален лист, съдържащ внос, променливи и миксини заедно. Много разработчици предпочитат да разделят променливи и миксини, но това се свежда до семантиката.

Имайте предвид, че миксините са начин за импортиране или по-скоро дублиране на кода на Sass. Те са невероятно мощни, но не трябва да се използват с тях “статичен” код. Имайте предвид, че има разлика между миксините, разширенията и местата за задържане, като всички те се използват в разработката на Sass.

Mixins се използват най-добре с динамични стойности, преминали в mixin за промени в кода. Например, вижте този Sass mixin, който създава фонов градиент между два цвята.

@mixin linearGradient ($ top, $ bottom) фон: $ 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-linear-gradient (отгоре, $ top 0%, $ bottom 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (отгоре, $ top 0%, $ bottom 100%); / * IE10 + * / фон: линеен градиент (до дъното, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Миксинът има две стойности: цвят отгоре и цвят на дъното. Можете да напишете различни миксини за различни типове градиенти, които включват 3 или 4 различни цвята. Това ви позволява да импортирате и клонирате кода на mixin, докато променяте параметрите за потребителски опции.

Примерът от Отговорен код изглежда така:

.бутон @include linearGradient (#cccccc, # 666666); 

Свързан с mixin е Sass 'placeholder, който е предимно полезен с директивата за разширяване. Несъмнено е по-сложно от миксините, но това може да бъде начин Комбинирайте селекторите заедно, без да пренаписвате излишния код.

Докато Sass има само един @import метод, аз включих mixins и placeholders, за да демонстрирам гъвкавостта на кода, който може да бъде написан в един файл, но включен навсякъде.

Когато създавате структура за импортиране, не забравяйте да следвате концепциите за 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. Типография Помощници… // 1. Глобален // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1.5; // и т.н.

Друга практика за именуване се отнася до отзивчиви прекъсвания. Когато назовавате Sass breakpoints, опитайте се да избягвате специфични за устройството имена. По-добре е да напишете имена като малки, med, lg и xlg, защото те са относително една спрямо друга.

Това е по-добре за вътрешни връзки между точките на прекъсване, но също така и за екипите, при които разработчиците може да не знаят кои устройства са свързани помежду си.

Що се отнася до действително отхвърлянето на имена, препоръчваме ви да бъдат възможно най-конкретни без допълнителни дълги променливи. Ти трябва приемайте общоприети правила за именуване, които са лесни за запомняне при кодиране.

Дайте конкретни правила за именуване за всичко като цветове, полета, стекове на шрифтове и височини на линии. Не само бързо могат да се припомнят имената, но и прави работата ви по-лесна, когато пишете нови имена на променливи, които трябва да съответстват на съществуващ синтаксис.

Но има тънка граница между специфичност и намотка. Практиката ще ви помогне да откриете тази линия и писането на по-запомнящи се имена улеснява копирането на кода в други проекти.

Гнездене и обръщане

Тези две техники на Sass са много различни в действието, но и двете имат способност да се злоупотребява, ако не се използва внимателно.

Разполагане е процесът на добавяне на селектори, вмъкнати заедно чрез отстъп, за да се създаде повече специфичност с по-малко код. Sass има ръководство за вграждане, което илюстрира примери за кодиране в действие. Но е лесно да се увлечете с гнездене. Ако прекалявате, можете да получите код, който изглежда така:

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

Прекалено специфичен и почти невъзможен за презаписване, този тип код премахва целта на каскадните стилове.

Скипирайки този SitePoint ръководство, ще намерите три златни правила за гнездене:

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

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

Насочването на селекторите няма да доведе до каскадни CSS ефекти. Но ще имате по-лесен начин да премахнете Sass файла, като определите кои класове се отнасят един към друг.

Петли също могат използвайте, ако не се приложи правилно. Трите пет саса са @за, @докато, и @each. Аз няма да отида в подробности за това как всички те работят, но ако сте заинтересовани проверете тази публикация.

Вместо това бих искал да покрия предназначение за използване на примки и как функционират в Сас. Те трябва да се използват за спестяване на време за писане на код, който може да бъде автоматизиран. Например, тук е кодов фрагмент от публикацията на 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%;

Тези класове на колони могат да се използват заедно с мрежова система. Можете дори да добавите повече колони или да премахнете някои само чрез редактиране на цикъла на цикъла.

Loops Трябва не да се използва за дублиране на селектори или свойства за селектор; за това са миксините.

Също така, когато се прави цикъл, има нещо, наречено Sass maps, което съхранява двойки ключ: стойност. Напредналите потребители трябва да се възползват от тях, когато е възможно.

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

Ето един добър начин да проверите дали цикълът ви е полезен: попитайте себе си ако има някакъв друг начин да изведете CSS, който ви е необходим, с по-малко реда код. Ако не, тогава синтаксисът на цикъла вероятно е страхотна идея.

Ако някога сте объркани или искате да получите обратна информация за гнездене или Sass петел, трябва да публикувате въпрос в / r / sass / или / r / css /, активни общности на Reddit с много познати програмисти.

модуларизация

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

Идеята на модулния Sass е да се пишат отделни SCSS файлове с конкретна цел, насочена към глобално съдържание (типография, мрежи) или елементи на страницата (табулации, формуляри).

Дефиницията на модула Sass е доста ясна и предлага много специфично предложение: импортирането на модул никога не трябва да извежда код.

Идеята за задължителна продукция за всички модули би била кошмар за оптимизация. Вместо това трябва да създавате модули поотделно и обадете се само на онези, от които се нуждаете. Модулите могат да бъдат дефинирани от миксини или функции, но е възможно да се създават модули, които съдържат и селектори.

Въпреки това една статия на Sass Way предлага да се пишат всички селектори като миксини и да се извикват само ако е необходимо. Независимо дали приемате това или не, това е вашият избор. Мисля, че това зависи от размера на проекта и вашия комфорт при работа с миксини.

Цитирайки Джон Лонг от поста си в The Sass Way:

“За мен модулите са се превърнали в основни единици или градивни елементи на моите проекти на Sass.”

Ако наистина търсите рутинна програма на Sass, препоръчвам ви да бъдете напълно модулни. Опитайте да изградите почти всичко като модулна част, която се включва в основния CSS файл. Първоначално този работен процес може да изглежда обезсърчително, но има смисъл в по-голям мащаб - особено при големи проекти.

Освен това е много по-лесно да копирате модули от един проект в друг, когато се намират в отделни файлове. гъвкавост и код за многократна употреба са крайъгълните камъни на модулното развитие.

За да научите повече за Sass модулите и методите за модулация, вижте тези публикации:

• CSS модули: Добре дошли в бъдещето
• За и против на Modular Sass
• Модулна CSS организация със SMACSS и SASS

Намерете своя перфектен работен поток

Всеки екип и индивидуален разработчик имат свои собствени практики, които работят най-добре. Трябва да приемете практики, които работят най-добре за вас лично, или да изберете да възприемете тези, които работят най-добре за вашия екип професионално.

Също така обмислете използването на Gulp или Grunt за автоматизация на проекта и намаляване на кода. Това ще спести много ръчен труд и средствата за автоматизация сега несъмнено са част от най-добрите практики за модерно развитие на frontend.

Прочетете чрез библиотеки с отворен код като SCSS на Фондацията на GitHub, за да научите повече за най-добрите практики, използвани от други библиотеки.

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

Едно последно предложение, което имам за целия процес на Sass е да вземане на решения с яснота в ума. Напишете код, който улеснява работата ви. Не усложнявайте проекта, ако има по-лесен начин да го направите.

Sass има за цел да подобри опита за развитие на CSS, така че работа с яснота и добри практики за да получите възможно най-добрия опит.

Увийте-Up

Претоварването в работния процес на Sass може да бъде коригирано чрез променяне на стиловете на код и следване на най-добрите практики. Описах няколко предложения в този пост, дадени от блоговете на Sass и професионалните разработчици.

Най-добрият начин да научите повече е да приложите тези практики във вашия работен процес и виж какво работи. С течение на времето ще откриете, че някои дейности са по-полезни от други, в който случай трябва дръжте каквото работи и изпуснете това, което не.

Разгледайте тези връзки, за да намерите повече съвети и най-добри практики за разработката на Sass:

• Указания на Sass
• Визия за нашия Сас
• 8 съвета за да получите най-доброто от Sass
• Разширяване в Sass без създаване на бъркотия
• Sass Best Practices - Гнездене на повече от 3 нива