Sass Teknikker fra Skyttergravene

0
12

Etter å ha vært i web utvikling bransjen for mer enn 14 år, jeg har sett og skrevet min fair share av gode og dårlige CSS. Når jeg begynte på Ramsey Løsninger for fem år siden, ble jeg introdusert til Sass. Det blåste mitt sinn hvor nyttig det var! Jeg stupte rett i, og ønsket å lære alt jeg kan om det. I løpet av de siste fem årene, jeg har brukt en rekke forskjellige Sass teknikker og mønstre og falt i kjærlighet med noen som, for å stjele Apple ‘ s frase, bare arbeid.

I denne artikkelen vil jeg utforske et bredt spekter av emner:

  • The power of the ampersand
  • Variabler og omfang
  • Betydningen av import
  • Mixin’ den opp
  • Å få funksjonelle
  • Velgeren for at plassholdere rotet opp

I min erfaring, er det å finne balansen mellom enkle og komplekse er avgjørende komponent for å lage god programvare. Programvaren skal ikke bare være lett for folk å bruke, men for deg og andre utviklere å opprettholde i fremtiden. Jeg ville vurdere disse teknikkene til å være avansert, men ikke nødvendigvis smart eller kompleks, med hensikt!

“Alle vet at debugging er dobbelt så vanskelig som det er å skrive et program i første omgang. Så hvis du er så smart som du kan være når du skriver det, hvordan vil du noensinne debug det?”

Elementer av Programmering og Stil (2. Utgave), Kapittel 2

Med det i tankene, la oss først se på Sass’ – tegnet.

The power of the ampersand

Det er mange forskjellige navnekonvensjoner du kan bruke til å organisere CSS. Jeg liker å bruke mest, er FARGE, en variant av BEM (som er en forkortelse for B– lås, Element, Modifier). Hvis du ikke er kjent med SUIT eller BEM, vil jeg anbefale å ta en titt på en eller begge av dem før du går videre. Jeg skal bruke FARGE-konvensjonen gjennom resten av denne artikkelen.

Hva naming convention du velge base-ideen er at hver stil element får sin egen klasse navn, prepended med komponent navn. Denne ideen er viktig for hvordan noen av de følgende organisasjonen fungerer. Også denne artikkelen er beskrivende, og ikke normative. Hvert prosjekt er forskjellig. Du trenger å gjøre hva som fungerer best for dine prosjekt og ditt team.

The ampersand er den viktigste grunnen til at jeg liker å bruke FARGE, BEM, og konvensjoner som dem. Det tillater meg å bruke hekkende og omfang uten enten å bite tilbake med spesifisitet. Her er et eksempel. Uten å bruke tegnet, ville jeg trenger for å lage egne velgere til å lage-tittel og innhold av elementer.

.MyComponent {
.MyComponent-tittel {}
}

.MyComponent-innhold {}

// Kompileres til
.MyComponent .MyComponent-tittel {} // Ikke hva vi ønsker. Unødvendig spesifisitet!
.MyComponent-innhold {} // Ønsket resultat

Når du bruker PASSER, jeg vil at andre resultat for -innhold til å være hvordan kan jeg skrive alle mine velgere. Å gjøre så, vil jeg må gjenta navnet på komponenten hele. Dette øker min sjanse til å feilstaver navnet på komponenten som jeg skriver nye stiler. Det er også svært støyende som det ender opp med å ignorere begynnelsen av mange velgere, noe som kan føre til glossing over åpenbare feil.

.MyComponent {}
.MyComponent-tittel {}
.MyComponent-innhold {}
.MyComponent-author {}
// Osv.

Hvis dette var normal CSS, vil vi bli sittende fast skriftlig ovenfor. Siden vi bruker Sass, det er en mye bedre tilnærming å bruke tegnet. The ampersand er fantastisk fordi den inneholder en referanse til de gjeldende selector sammen med alle foreldre.

.En {
// & = ‘.En’
.B {
// & = ‘.A .B’
.C {
// & = ‘.A .B .C’
}
}
}

Du kan se i eksempelet over hvordan ampersand referanser hvert selector i kjeden som det går dypere inn i den nestede kode. Ved å benytte denne funksjonen, kan vi skape nye velgere uten å måtte skrive navnet på komponenten hver gang.

.MyComponent {
og-tittel {}

og-innhold {}
}

// Kompileres til
.MyComponent {}
.MyComponent-tittel {}
.MyComponent-innhold {}

Dette er flott fordi vi kan dra nytte av tegnet for å skrive inn navnet på komponenten én gang og bare en referanse til den komponent navn i hele. Dette reduserer sjansen for at komponentens navn er feilskrevet. Plus, det dokumentet som helhet blir lettere å lese uten .MyComponent gjentatt over hele koden.

Det er tider når komponenten er behov for en variant eller spesialtasten, som de kalles i DRESS og BEM. Ved hjelp av tegnet mønster gjør det lettere å skape modifikatorer.

<div class=”MyComponent MyComponent–xmasTheme”></div>
.MyComponent {
&–xmasTheme {}
}

// Kompileres til
.MyComponent {}
.MyComponent–xmasTheme {}

“Men, hva om endring barnet elementer?” spør du kanskje. “Hvordan er de velgere som er opprettet? Modifier er ikke nødvendig på hvert element, ikke sant?”

Dette er hvor variabler som kan hjelpe!

Variabler og omfang

I det siste, har jeg laget modifikatorer et par forskjellige måter. Mesteparten av tiden, vil jeg skrive om den spesielle tema navn jeg ønsker å bruke når du endrer element.

.MyComponent {
og-tittel {
.MyComponent–xmasTheme & {
}
}

og-innhold {
.MyComponent–xmasTheme & {
}
}
}

// Kompileres til
.MyComponent-tittel {}
.MyComponent–xmasTheme .MyComponent-tittel {}
.MyComponent-innhold {}
.MyComponent–xmasTheme .MyComponent-innhold {}

Dette får jobben gjort, men jeg er tilbake til å skrive komponent navn på flere steder, for ikke å nevne modifier navn. Det er definitivt en bedre måte å gjøre dette på. Skriv inn Sass variabler.

Før vi utforske Sass variabler med velgere, vi trenger for å forstå hvordan de er omfattet. Sass variablene har omfang, akkurat som de ville gjort i JavaScript, Ruby, eller andre programmeringsspråk. Hvis den deklareres utenfor en velger, variabelen er tilgjengelig for hver selector i dokumentet etter sin erklæring.

$fontstørrelse: 1.4 rem;

.en { font-size: $fontstørrelse; }
.b { font-size: $fontstørrelse; }

Variabler deklarert inne i en selector er omfattet bare til at velgeren og sine barn.

$fontstørrelse: 1.4 rem;

.MyComponent {
$fontWeight: 600;
font-size: $fontstørrelse;

og-tittel {
font-weight: $fontWeight; // Fungerer!
}
}

.MyComponent2 {
font-size: $fontstørrelse;

og-tittel {
font-weight: $fontWeight; // lager en “udefinert variabel” – feil
}
}

Vi vet variabler kan lagre font navn, heltall, farger, etc. Visste du at det også kan lagre velgere? Ved hjelp av streng interpolering, kan vi skape nye velgere med variabel.

// Sass string interpolering er syntaksen #{VARIABEL}
$blokk: “.MyComponent”;

#{$block} {
og-tittel {
#{$block}–xmasTheme & {
}
}
}

// Kompileres til
.MyComponent {}
.MyComponent-tittel {}
.MyComponent–xmasTheme .MyComponent-tittel {}

Det er kult, men variabelen er globalt omfattet. Vi kan løse dette ved å lage den $blokk variable inne i komponenten erklæringen, som ville omfang er det i denne komponenten. Da kan vi re-bruke $blokk variable i andre komponenter. Dette hjelper til med å TØRKE opp temaet modifier.

.MyComponent {
$blokk: ‘.MyComponent’;

og-tittel {
#{$block}–xmasTheme & {
}
}

og-innhold {
#{$block}–xmasTheme & {
}
}
}

// Kompileres til
.MyComponent {}
.MyComponent-tittel {}
.MyComponent–xmasTheme .MyComponent-tittel {}
.MyComponent-innhold {}
.MyComponent–xmasTheme .MyComponent-innhold {}

Dette er nærmere, men igjen, vi er nødt til å skrive temaet navn over og over. La oss lagre det i en variabel også!

.MyComponent {
$blokk: ‘.MyComponent’;
$xmasTheme: ‘.MyComponent–xmasTheme’;

og-tittel {
#{$xmasTheme} og {
}
}
}

Dette er mye bedre! Men vi kan forbedre dette ytterligere. Variabler kan også lagre verdien til tegnet!

.MyComponent {
$blokk: &;
$xmasTheme: #{og}–xmasTheme;

og-tittel {
#{$xmasTheme} og {
}
}
}

// Fortsatt kompileres til
.MyComponent {}
.MyComponent-tittel {}
.MyComponent–xmasTheme .MyComponent-tittel {}

Det er hva jeg snakker om! “Caching” selector med tegn lar oss lage vår modifikatorer på toppen og holde temaet endringer med innslag det er endring.

“Jada, det fungerer på øverste nivå,” sier du. “Men hva hvis du er nestet virkelig dyp, som åtte nivåer i?” Du stiller gode spørsmål.

Uansett hvor dype redet, dette mønsteret alltid fungerer fordi den viktigste komponenten navn er aldri knyttet til noen av barna, takket være den PASSER naming convention og tegnet combo.

.MyComponent {
$blokk: &;
$xmasTheme: #{og}–xmasTheme;

og-innhold {
font-størrelse: 1,5 rem;
farge: blå;

ul {
li {
sterk {
span {
&::før {
background-color: blue;

#{$xmasTheme} og {
background-color: red;
}
}
}
}
}
}
}
}

// Kompileres til
.MyComponent-innhold {
font-størrelse: 1,5 rem;
farge: blå;
}

.MyComponent-innhold ul li sterk span::før {
background-color: blue;
}

/*
* Temaet er fortsatt lagt til begynnelsen av selector!
* Nå, vi trenger aldri å skrive dypt nestede Sass det er vanskelig å opprettholde og
* ekstremt skjøre: https://css-tricks.com/sass-selector-combining/
*/
.MyComponent–xmasTheme .MyComponent-innhold ul li sterk span::før {
background-color: red;
}

Koden organisasjonen er den viktigste grunnen til at jeg liker å bruke dette mønsteret.

  • Det er relativt TØRT
  • Det støtter “opt-in” – tilnærming, som holder modifikatorer med elementer de endre
  • Navngi ting er vanskelig, men dette gjør oss i stand til å bruke felles element navn som “tittel” og “innhold”
  • Det er lave løft for å legge til en modifikator til en komponent ved å plassere modifier klasse på den overordnede komponent

“Hhhmmmmm… ikke at det blir vanskelig å lese om når du oppretter du en haug av forskjellige komponenter? Hvordan vet du hvor du er på når alt er oppkalt &-tittel og &-innhold?”

Du fortsetter å stille gode spørsmål. Hvem sa kilden Sass måtte være i én fil? Vi kan importere disse komponentene, så la oss slå til at emnet!

Betydningen av import

Credit: @Julien_He

En av Sass’ beste funksjonene er @import. Vi kan opprette separate Sass-filer (partials) og importere dem til andre Sass-filer som setter sammen med den importerte filen ligger på stedet den er importert. Dette gjør det enkelt å pakke opp relaterte stiler for komponenter, verktøy, etc. og trekke dem inn i en enkelt fil. Uten @import, vi hadde behov for å linke til egen CSS-filer (skape mange nettverk forespørsler, som er badong) eller skrive alt i en enkelt stilsett (som er vanskelig å navigere og vedlikeholde).

.Component1 {
og-tittel {}
og-innhold {}
&-author {}
}

.Component2 {
og-tittel {}
og-innhold {}
&-author {}
}

.Component3 {
og-tittel {}
og-innhold {}
&-author {}
}

.Component4 {
og-tittel {}
og-innhold {}
&-author {}
}

.Component5 {
og-tittel {}
og-innhold {}
&-author {}
}

// Et par hundre linjer senere…

.Component7384 {
og-tittel {}
og-innhold {}
&-author {}
}

// HVOR ER JEG?

En av de mer populære metoder for å organisere Sass-filer er 7-1 Mønster. Det er syv forskjellige mapper som inneholder Sass-filer som er importert til en enkelt Sass-fil.

Disse mappene er:

  • sammendrag
  • base
  • komponenter
  • layout
  • sider
  • temaer
  • leverandør

Bruk @import for å trekke hver Sass-filen i de mappe til en main Sass-fil. Vi ønsker å importere dem i følgende rekkefølge for å opprettholde god omfang og unngå konflikter under kompilering:

  1. sammendrag
  2. leverandør
  3. base
  4. layout
  5. komponenter
  6. sider
  7. temaer

@import, sammendrag/variabler’;
@import, sammendrag/funksjoner”;
@import, sammendrag/mixins’;

@import ‘leverandører/noen-tredje-part-komponent’;

@import “base/normalisere’;

@import “layout/navigasjon’;
@import “layout/header’;
@import “layout/footer’;
@import “layout/sidebar’;
@import “layout/forms’;

@import ‘components/ – knappene’;
@import ‘components/hero”;
@import ‘components/pull-sitat’;

@import ‘pages/home’;
@import ‘pages/kontakt’;

@import “temaer/standard’;
@import “temaer/admin’;

Du kan eller ikke ønsker å bruke alle disse mappene (jeg personlig ikke bruke temaet mappen siden jeg holder temaer med sine komponenter), men tanken om å skille alle stiler inn i forskjellige filer gjør det lettere å vedlikeholde og å finne koden.

Flere av fordelene ved å bruke denne tilnærmingen:

  • Små komponenter er lettere å lese og forstå
  • Debugging blir enklere
  • Det er klarere for å avgjøre når en ny komponent, bør være opprettet som når en enkelt komponent-fil blir for lang, eller selector kjeden er for komplisert
  • Dette understreker re-bruk — for eksempel, kan det være fornuftig å generalisere tre komponent filer som egentlig gjøre det samme i en komponent

Snakker av re-bruk, det er slutt mønstre som blir brukt ofte. Det er da vi kan nå for mixins.

Mixin’ den opp

Mixins er en flott måte å bruke stiler i løpet av et prosjekt. La oss gå gjennom opprette en enkel mixin og deretter gi den en liten bit av intelligens.

Designer jobber jeg med på en jevnlig basis alltid setter font-størrelse, font-vekt, og line-height til bestemte verdier. Jeg fant meg selv å skrive alle tre ut hver gang jeg trengte for å justere fonter for en komponent eller et element, så jeg laget en mixin å raskt sette disse verdiene. Det er som en liten funksjon som jeg kan bruke til å definere de egenskaper uten å måtte skrive dem i sin helhet.

@mixin tekst($size, $lineHeight, $vekt) {
font-size: $størrelse;
line-height: $lineHeight;
font-weight: $vekt;
}

På dette punktet, mixin er ganske enkel, det ligner på noe som en funksjon i JavaScript. Det er navnet på mixin (tekst) og det tar tre argumenter. Hvert argument er knyttet til en CSS-egenskapen. Når mixin er kalt, Sass vil kopiere egenskaper og pass i argumentet verdier.

.MyComponent {
@inkluderer tekst(18px, 27px, 500);
}

// Kompileres til
.MyComponent {
font-size: 18px;
line-height: 27px;
font-vekt: 500;
}

Mens det er en god demonstrasjon, denne spesielle mixin er litt begrenset. Det forutsetter at vi alltid ønsker å bruke font-size, line-height, og font-weight egenskaper når det er kalt. Så la oss bruke Sass’ if-setning å bidra til å styre produksjonen.

@mixin tekst($size, $lineHeight, $vekt) {
// Hvis $størrelse argumentet ikke er tom, deretter utgang argumentet
@dersom $størrelse != null {
font-size: $størrelse;
}

// Hvis $lineHeight argumentet ikke er tom, deretter utgang argumentet
@dersom $lineHeight != null {
line-height: $lineHeight;
}

// Hvis $vekt argumentet ikke er tom, deretter utgang argumentet
@dersom $vekt != null {
font-weight: $vekt;
}
}

.MyComponent {
@inkluderer tekst(12px, null, 300);
}

// Kompileres til
.MyComponent {
font-size: 12px;
font-vekt: 300;
}

Det er bedre, men ikke helt der. Hvis jeg prøver å bruke den mixin uten å bruke null som en parameter på verdier som jeg ikke ønsker å bruke eller gi, Sass vil generere en feilmelding:

.MyComponent {
@inkluderer tekst(12px, null); // venstre av $vekt
}

// Kompileres til en feil:
// “Mixin tekst mangler argument $vekt.”

For å komme rundt dette, kan vi legge til standard verdier til parametrene, slik at vi kan forlate dem av funksjonen samtale. Alle valgfrie parametere må erklæres etter at alle nødvendige parametere.

// Definerer vi `null` som standard verdi for hvert argument
@mixin tekst($size: null, $lineHeight: null, $vekt: null) {
@dersom $størrelse != null {
font-size: $størrelse;
}

@dersom $lineHeight != null {
line-height: $lineHeight;
}

@dersom $vekt != null {
font-weight: $vekt;
}
}

.MyComponent {
og-tittel {
@inkluderer tekst(16px, 19px, 600);
}

&-author {
@inkluderer tekst($vekt: 800, $size: 12px);
}
}

// Kompileres til
.MyComponent-tittel {
font-size: 16px;
line-height: 19px;
font-vekt: 600;
}

.MyComponent-author {
font-size: 12px;
font-vekt: 800;
}

Ikke bare standard argument verdier gjør mixin enklere å bruke, men vi vil også få muligheten til å nevne parametere og gi dem verdier som kan være vanlig. På Linje 21 ovenfor, mixin blir kalt med argumenter ut av ordre, men siden de verdier blir kalt ut så godt, mixin vet hvordan du skal bruke dem.

Det er et bestemt mixin som jeg bruker på daglig basis: min bredde. Jeg foretrekker å lage alle mine nettsteder mobile first, eller i utgangspunktet med den minste viewport i tankene. Som viewport vokser bredere, jeg definerer stoppunkter for å justere layout og koden for det. Dette er hvor jeg kommer for min-bredde mixin.

// La oss kalle dette “min-width” og ta et enkelt argument vi kan
// brukes for å definere viewport bredde i en media query.
@mixin min-bredde($grense) {
// Vi ringer opp en annen funksjon (scut-rem) for å konvertere punkter til rem-enheter.
// Vi vil dekke det i neste avsnitt.
@media-skjerm, og (min-width: scut-rem($terskel)) {
@innhold;
}
}

.MyComponent {
display: block;

// Ringe min-bredde mixin og passere 768 som argument.
// min-bredde passerer 768 og scut-rem konverterer enhet.
@inkluderer min-bredde(768) {
skjerm: flex;
}
}

// Kompileres til
.MyComponent {
display: block;
}

@media-skjerm, og (min-width: 48rem) {
.MyComponent {
skjerm: flex;
}
}

Det er et par av nye ideer her. Den mixin har en nestet funksjon som kalles @innhold. Så, i det .MyComponent klasse, kan vi ikke lenger kalle mixin alene, men også en blokk med kode som blir output inne i media spørring som er generert. Den resulterende koden vil kompilere der @innhold er kalt. Dette gjør at mixin å ta vare på @media-erklæringen og aksepterer fortsatt egendefinert kode for en bestemt stoppunkt.

Jeg også er inkludert mixin innenfor .MyComponent erklæring. Noen mennesker argumentere for å holde alle responsive samtaler i et eget stilark for å redusere mengden av ganger @media er skrevet ut i et stilark. Personlig, jeg foretrekker å holde alle variasjoner og endringer som en komponent kan gå gjennom med denne komponenten er erklæringen. Det har en tendens til å gjøre det enklere å holde oversikt over hva som skjer og hjelpe debug-komponenten hvis noe ikke gå til høyre, snarere enn sifting gjennom flere filer.

La du merke til scut-rem-funksjonen i det? Det er en Sass-funksjonen tatt fra en Sass bibliotek kalt Scut, skapt av David Clark. La oss ta en titt på hvordan det fungerer.

Å få funksjonelle

En funksjon er forskjellig fra en mixin i at mixins er ment til å sende vanlige grupper av egenskaper, mens en funksjon endrer egenskaper basert på argumenter som returnerer et nytt resultat. I dette tilfellet, scut-rem tar pixel verdi og konverterer den til en rem-verdi. Dette gir oss muligheten til å tenke i piksler, mens du arbeider med rem enheter bak kulissene for å unngå alt som matematikk.

Jeg har forenklet scut-rem i dette eksemplet fordi det har et par ekstra funksjoner som bruker looper og lister, som er utenfor omfanget av det vi dekker her. La oss se på funksjonen i sin helhet, så bryte det ned trinn-for-trinn.

// Forenklet fra den opprinnelige kilden
$scut-rem-base: 16 !standard;

@funksjon scut-stripe-enhet ($tall) {
@return $num / ($a * 0 + 1);
}

@funksjon scut-rem ($bildepunkter) {
@return scut-stripe-enhet($punkter) / $scut-rem-base * 1rem;
}

.MyComponent {
font-size: scut-rem(18px);
}

// Kompileres til
.MyComponent {
font-size: 1.125 rem;
}

Første ting å merke seg er den erklæring på Linje 2. Det er med !standard ved å deklarere en variabel, som forteller Sass for å angi verdien til 16, med mindre denne variabelen er allerede definert. Så hvis en variabel er deklarert tidligere i stilsettet med en annen verdi, er det ikke overstyres her.

$fontstørrelse: 16px;
$fontstørrelse: 12px !standard;

.MyComponent {
font-size: $fontstørrelse;
}

// Kompileres til
.MyComponent {
font-size: 16px;
}

Den neste brikken i puslespillet er scut-stripe-enhet. Denne funksjonen tar en px, rem, prosent eller andre etterfølges verdi og fjerner enheten etiketten. Kall scut-stripe-enhet(12px) returnerer 12 i stedet for 12px. Hvordan gjør man det? I Sass, en enhet som er delt med en annen enhet av samme type vil stripe enheten og gå tilbake tallet.

12px / 1px = 12

Nå som vi vet at, la oss se på scut-stripe-enhet fungere igjen.

@funksjon scut-stripe-enhet ($tall) {
@return $num / ($a * 0 + 1);
}

Funksjonen tar inn en enhet og deler det med 1 av samme enhet. Så hvis vi går i 12px, funksjonen vil da se slik ut: @return 12px / (12px * 0 + 1). Følgende rekkefølgen av operasjoner, Sass vurderer hva som er i parentesene først. Sass smart ignorerer px etikett, evaluerer uttrykk, og stifter px tilbake på når det er gjort: 12 * 0 + 1 = 1px. Ligningen er nå 12px / 1px som vi vet returnerer 12.

Hvorfor er dette viktig å scut-rem? Ser og ser på det igjen.

$scut-rem-base: 16 !standard;

@funksjon scut-rem ($bildepunkter) {
@return scut-stripe-enhet($punkter) / $scut-rem-base * 1rem;
}

.MyComponent {
font-size: scut-rem(18px);
}

På Linje 4, scut-stripe-enhet funksjonen fjerner px fra argument og returnerer 18. Base variabelen er lik 16 som slår inn i ligningen: 18 / 16 * 1rem. Husk, Sass ignorerer enhver enhet til slutten av ligningen, så 18 / 16 = 1.125. Som resultat multiplisert med 1rem gir oss 1.125 rem. Siden Scut strimler enheten ut av argumentet, vi kan kalle scut-rem med enhet- / mindre verdier, som scut-rem(18).

Jeg skriver ikke at mange funksjoner fordi jeg prøver å holde ting jeg lager så enkel som mulig. Å være i stand til å gjøre noen komplekse konverteringer ved hjelp av noe som scut-rem er nyttig om.

Velgeren for at plassholdere rotet opp

Ende opp der jeg tror det gjorde at CSS?

Jeg virkelig ikke liker å bruke plassholdere og @utvide i koden min. Jeg synes det er lett å komme i trøbbel med dem for et par forskjellige grunner.

Vær forsiktig med hva er utvidet

Jeg prøvde å skrive ut noen eksempler for å demonstrere hvorfor bruker @forlenge kan være problematisk, men jeg har brukt dem så lite at jeg ikke kan lage noen skikkelige eksempler. Når jeg først lærte Sass, jeg var omgitt av lagkamerater som allerede har gått gjennom de prøvelser og trengsler. Min venn Jon Bebee skrev en svært god artikkel om hvordan @forlenge kan få deg i trøbbel. Det er en rask leser, og vel verdt tiden, så jeg vil vente.

Om de plassholdere…

Jon foreslår bruker plassholdere som en løsning på problemet han skisserer: Plassholdere ikke ut en hvilken som helst kode før de er vant med @utvide.

// % betegner en utvidet blokken
%item {
display: block;
bredde: 50%;
margin: 0 auto;
}

.MyComponent {
@utvide %elementet.
farge: blå;
}

// Kompileres til
.MyComponent {
display: block;
bredde: 50%;
margin: 0 auto;
}

.MyComponent {
farge: blå;
}

OK, vent. Så det utgang .MyComponent to ganger? Hvorfor ikke det bare kombinere velgere?

Dette er spørsmål jeg hadde når jeg først begynte å bruke plassholdere (og deretter stoppet). Clue er navnet i seg selv. Plassholdere bare holde en referanse til stedet i stilsettet de ble erklært. Mens en mixin kopier egenskapene til plasseringen der det er nødvendig, plassholdere kopi velgeren til det sted hvor plassholder ble definert. Som et resultat, den kopierer .MyComponent selector og plasserer den der %elementet er erklært. Tenk deg følgende eksempel:

%ha bøyelige {
skjerm: flex;
}

.En {
farge: blå;
}

.B {
@utvid: %ha bøyelige;
farge: grønn;
}

.C {
@utvid: %ha bøyelige;
farge: rød;
}

// Kompileres til
.B, .C {
skjerm: flex;
}

.En {
farge: blå;
}

.B {
farge: grønn;
}

.C {
farge: rød;
}

Selv om B og C er erklært lenger ned i stilsettet, plassholderen steder den utvidede egenskaper høye veien opp til der det opprinnelig ble vedtatt. Det er ikke en stor avtale i dette eksemplet fordi det er virkelig nær til kilden hvor det er brukt. Men, hvis vi er å forholde seg til noe som 7-1 Mønsteret vi dekket tidligere, så plassholdere ville være definert i en delvis i den abstracts-mappen, som er en av de første importerte filer. Som legger mye av stil mellom der de er ment å utvide og hvor det faktisk er brukt. Det kan være vanskelig å opprettholde så vel som vanskelige å feilsøke.

Sass Retningslinjer (selvfølgelig) gjør en god jobb som dekker plassholdere og utvide og jeg anbefaler å lese den. Det er ikke bare forklarer utvide funksjonen, men på slutten, og kjemper mot å bruke det:

Meninger synes å være svært delt om fordeler og problemer fra @utvide til et punkt der mange utviklere inkludert meg selv har vært taler mot det, […]

Det er mange andre funksjoner av Sass jeg ikke har dekning her, som looper og lister, men jeg har ærlig talt ikke lettelse opp på for de har så mye som vi gjorde dekke i denne artikkelen. Ta en titt gjennom Sass dokumentasjon, hvis ikke noe annet, for å se hva ting gjøre. Kan du ikke finne en bruk for alt med en gang, men en situasjon kan komme opp og at kunnskap i ryggen er uvurderlig.

La meg vite om jeg har gått glipp av noe eller fått noe galt! Jeg er alltid åpen for nye ideer og ville elske å diskutere det med deg!

Videre Lesning

  • Sass Style Guide – Tanker og anbefalinger for å holde Sass rengjøre og vedlikeholde.
  • Hva en CSS-Kode Gjennomgang Kan Se ut Som – Hovedsakelig ser på CSS, men inneholder tips for å kode gjennomgang Sass-filer.
  • Definere og Håndtere Teknisk Gjeld – Vi snakket mye om å TØRRE metoder og effektivitet i denne artikkelen. Dette innlegget snakker om ulike konsekvenser av detaljert eller ineffektiv kode.
  • Looper i CSS Preprocessors – Vi hadde ikke dekke loops her, men Miriam Suzanne går i dybden i denne artikkelen.
  • Sass Tekstutdrag – En samling av praktiske Sass mixins og andre Sass mønstre.