Страхотен CSS подход към стиловите таблици на Sass като програма - CSS-LIVE

Страхотен CSS: Подход към Sass Style Sheets като програма

Страхотен CSS, моля

В гореспоменатата статия („Atomic OOBEMITSCSS“) обясних как маркирам компоненти (като използвам Pinterest като пример) и ги стилизирам по съответния начин. Продължавам да използвам тази публикация като удобно ръководство за всеки, който се интересува от нашата предна архитектура, която оттогава е преминала през пълномащабно тестване спрямо голяма библиотека от модели.

sass
Един пример от статия на Sitepoint

В резултат на това бях изправен пред необходимостта да обясня тази система (и самия Sass) на хора с традиционно програмистско образование. Това ме накара да осъзная доколко системата за CSS архитектура, която описах, е програмна и базирана на класове. Затова искам да отделя малко време, за да му дам заслужено заглавие, от което не бих се срамувал, „Страхотен CSS “, и да го обясня по начин, който е малко по-близък до традиционните програмисти.

Тази публикация има три цели:

  1. Защитете @extend
  2. Представяме виГотин CSS (много по-лесен за произнасяне от " Atomic OOBEMITSCSS ")
  3. Говорете за мащабируем, модулен и базиран на клас подход към CSS

готин бутон

Е, нека да разгледаме как работи, използвайки примера на бутон (в края на краищата бутонът е CSS „здравей свят“):

Нека започнем с премахване на селектор с основен код за всеки бутон, използвайки леко променен синтаксис, подобен на BEM. Първата част от името му ще бъде обектът, към който се отнасяме (бутон или btn), а след двойното тире ще има модификатор (в този случай база, т.е. основа).Забележка : променливите се именуват по същия начин - типът на променливата в ролята на база (в примера по-долу това е цвят).

Това основнобутон е нашият клас бутон. Към това ще добавим всичко останало за всеки бутон, защотовсеки бутон е екземпляр на този клас. Всеки бутонен елемент е от тип "бутон", така че всички те имат общи характеристики (плътна линия, прозрачен фон и т.н.). Всеки бутон приема същите общи свойства и надгражда върху тях. Те не презаписват тези свойства, а добавят нови към тях. Всички те са бутони++, които наследяват свойствата на основния бутон. (Необходимо ли е да повторим същата идея по някакъв начин?)

А ето и тяхното използване:

стиловите
Илюстрация на прототипно наследяване от You Don't Know JS: Тази ключова дума и прототипи на обект

Ако ги напишете по "готин" начин, всекикомпонент (hero, sidebar, global-nav) ще има свой собствен частичен .scss файл, където се създават екземпляри на клас за реална употреба. Може да изглежда така:

И така, какво ще кажете за миксините?

Може би се чудите защо вместо това не използвате @mixin? Нашият начин за разделяне на класове във файлове е по-близо до това, за което е проектиран и предназначен @extend. Можем да създадем миксини в класове мъничета, върху които стилизираме, и след това да използваме @extend, за да инстанцираме класове с тези стилове.

В защита на @extend

Използването на @extend ни позволява да намалим получения CSS файл и да направим кода по-чист, ако разбираме какво се случва (ние добавяме стилове, а не ги дублираме). Можете да спорите, че това не е проблем, има gzip - но не винаги можете да разчитате на gzip, защото може да нямате достъп до настройките на сървъра.

За да разберете и използвате @extends във ваша полза, трябва да разберете точно какво се случва и какви са основните разлики между @mixin и @extend. Ето един добър пример:

стиловите

подход

@mixin е катоstamping : създава дублиран блок със свойства, с незадължително допълнение под формата на предадени аргументи. @extendдобавя елемента, който разширявате, към блока със свойства. Все едно да кажеш „Да, и ___ “.

Това означава, че нашият окончателен CSS файл ще бъде по-малък, защото не повтаряме блока от код всеки път, когато се използва. С @extend можем просто да препращаме към свойства. @extend директивите са идеални за това! Тяхното логично предназначение е съвсем разумно.#teamExtend

Недостатъкът тук е, че не знаем къде е блокът със свойства, тъй като не правим ново копие на кодовия блок в директивата, а просто го наричаме източник на стил (поради което не можете да използвате @extend в медийни изрази). Но това няма значение, стига да следваме принципите на Cool CSS. Вие разширявате класовете мъничета в реално използваеми класове и работите с екземпляри на тези класове, докато директивите @mixin са запазени за друга цел. С тяхна помощ изграждаме кода в класовете мъничета, които след това разширяваме.

В случая на Cool CSS,миксините са подобни на конструкторите и се използват само в предварително изработени селектори.

Например, нека създадем миксин за бутони, за да улесним завършването на основните и допълнителни бутони въз основа на него:

И полученият CSS файл изглежда така:

Предимства

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

Сред предимствата:

  • Гарантира, че кодът е организиран по такъв начин, че няма да има конфликти на специфичност и нищо няма да бъде предефинирано(вижте ITCSS) - което означава, че CSS става по-прост, по-ефективен и размерът на крайния CSS файл е по-малък.
  • Системата за последователно именуване (BEM) поддържа екипа последователен и намалява объркването чрез общи правила.
  • Системата е организирана, лесно поддържана и мащабируема

Напишете страхотен код и оставете Sass да ви помогне да реализирате най-смелите си идеи! 💁