Sådan skrives bedre CSS i teams med ACSS - Et dynamisk Atomic CSS-bibliotek

Foto af Štefan Štefančík på Unsplash

At skrive gode Cascading Style Sheets (CSS) er vanskeligt, og det bliver vanskeligere i et team, hvor flere udviklere skriver CSS.

Gennem denne artikel forsøger jeg at introducere dig til en tilgang til at skrive (eller ikke skrive ... vi ser) CSS. Denne tilgang løser næsten alle de problemer, man står overfor i dag med dårligt skrevet CSS i teams.

Men først skal jeg sætte nogle basebetingelser, som min artikel gælder.

Nogle få betingelser forudsætter denne artikel:

  1. Du arbejder i et team, hvor flere udviklere skriver CSS.
  2. Retningslinjer er svære at håndhæve, medmindre der er automatiserede værktøjer.
  3. Designere er frie fugle. Gendesign sker.

Under disse forhold vil jeg præsentere en sølvkugleløsning, der løser næsten alle de problemer, vi står overfor på grund af dårlig CSS (Husk, CSS er ikke dårligt. Dårligt skrevet CSS er). Lad os gennemgå disse problemer til at begynde med.

Ansvarsfraskrivelse: Jeg er på ingen måde tilknyttet løsningen beskrevet i denne artikel. Jeg er bare en udvikler, der har følt smerten ved dårlig CSS i et team og vil dele med medudviklere, mine tanker om, hvordan jeg kan overvinde det. Denne artikel lyder muligvis salgsfremmende, men det er bare fordi jeg er meget begejstret over at få alle frem.

Problem nr. 1: Det er vanskeligt at navngive klasser

Udvikler 1 (mens kodning): Ser ud som en header for mig, lad mig bruge .headerselector til det.

Udvikler 2 (i pull-anmodningen): Dette er ikke en header. Det ligner en titel for mig. Desuden kan vi ikke kalde det bare 'header', da dette element ikke er generisk nok. Lad os kalde det .panel-header eller bedre .panel-title.

At komme op med navne, og det er også meningsfulde navne, er det vanskeligste at løse. Det er også den vanskeligste apsekt at lære, fordi du ikke kan have retningslinjer for, hvad der er et "meningsfuldt" navn. Du kan kun give eksempler på, hvad der ikke er meningsfuldt, og det kan kun hjælpe indtil videre. Derudover handler det ikke kun om at "være meningsfuld". Klasser i CSS er også nødt til at sikre, at de ikke kommer i konflikt med andre klassenavne i fremtiden, da en ny udvikler kan bruge det samme eller lignende navn til sin klasse.

Tilgængelige løsninger:

  • BEM - navnekonventioner som BEM findes for at løse dette problem til en vis grad. Men i sidste ende er det en retningslinje (vi ved alle, hvor nemt det er at følge retningslinjerne). BEM forhindrer muligvis dig i at gå fuldstændigt ad-hoc, men du har stadig brug for at komme med et oprindeligt klassens navn til dine komponenter.
  • Atomklasser - en anden almindelig tilgang i disse dage til at gå helt atomisk med atomklasser. Små klasser, der kun gør en ting. For eksempel. Tachyoner. Bland og match dem for at få det, du har brug for. Dette er et godt skridt i retning af at ”springe over navngivning” helt, men hvad nu hvis der i fremtiden ikke findes nogen klasse for en bestemt ting? Hvordan tilpasser jeg eksisterende atomklasser i henhold til mit design? Indlæses alle klasser altid på min side, uanset om jeg bruger dem eller ej? Vi har brug for noget mere.

Problem # 2: Valgstyrker

En anden ting, CSS-udviklere skal være konstant opmærksomme på, er, at specificiteten i deres CSS ikke går på højen. Hvis du har lange komplekse vælgere, bliver din CSS uforudsigelig og vanskelig at vedligeholde og fejlsøge. Harry Roberts har skrevet en masse artikler om, hvorfor det er dårligt, og hvad du kan gøre for at ordne det.

Tilgængelige løsninger:

Den bedste løsning på dette problem er blot at begrænse dine vælgere til en klasse. Ingen kæde, ingen rede, ingen id'er. Ovennævnte BEM-navngivning og atomklasser resulterer begge i enkeltklassevælgere i dit CSS og dermed hjælper med at løse dette problem.

Problem nr. 3: Hvad med ubrugt CSS?

CSS er gengivelsesblokerende, og det er derfor meget vigtigt at indlæse kun den kritiske CSS på en side synkront og resten asynkront. Af samme grund bliver det også vigtigt at forhindre din CSS i at skabe oppustethed ved at strippe ubrugt CSS.

Tilgængelige løsninger:

Mange værktøjer kan prale af at udtrække brugt CSS på en side. Men med apps på en side, der er kommet ind, er dette blevet vanskeligere end nogensinde. Jeg er ikke sikker på, hvor pålidelige eller effektive de er, men der er stadig brug for en ekstra efterbehandling over dit CSS.

Problem # 4: Refactoring

Udvikler 1: Denne CSS er blevet ret rodet. Jeg synes, vi skal refactor det.

Udvikler 2: Tror du, at denne vælger, du ændrer, muligvis også bliver brugt på side X? Har du tjekket?

Udvikler 1: Oh damn! Du har ret ... Det gik jeg glip af. Denne side X er for kritisk til at røre ved. Ved du hvorfor den udvikler brugte den samme klasse på begge sider?

Udvikler 2: Ingen idé. Han forlod firmaet. Lad os bare forlade CSS, som det er :(

Jeg har ikke mere at sige her. Denne dialog forklarer det hele.

Hvis jeg skal opsummere ovenstående problemer, vil jeg sige, at det er absolut muligt at skrive god (skalerbar, læsbar, vedligeholdelig) CSS. Det er dog ekstremt vanskeligt at gøre det i et kæmpehold. Selv hvis du prøver at gøre det rigtigt i et team, kræver det en konstant indsats fra nogen for at håndhæve al den bedste praksis.

I et team ville den mest ikke-indlysende, men perfekte løsning være - at stoppe med at skrive CSS!

”Vent, hvad siger du? Det er ikke muligt! ”. Du tænker måske på det, men lad mig introducere dig for noget.

Den alt-i-én-løsning - ACSS (Atomizer)

ACSS (afledt af Atomic CSS) er en komponentbaseret ramme for styling gennem atomklasser udviklet hos Yahoo! Og Atomizer er et værktøj, der faktisk letter det. Jeg forklarer mere. Men før det, lad mig vise dig, hvordan du gør styling i ACSS.

For at følge sammen med kodeprøverne i denne artikel foreslår jeg, at du installerer Web Maker (en front-end legeplads, der understøtter skrivning af ACSS uden nogen build-opsætning) i Chrome browser.

Sig nu, at du har en knap, der skal styles med sædvanlige polstring, baggrund, farve osv. Egenskaber. Sådan ser det ud i ACSS:


 Jeg er en knap

Et forslag - træff ikke nogen dom ved det første kig på denne syntaks. Fortsæt med at læse, give det tid, diskutere og derefter beslutte. Klasserne på knapmærket ser måske anderledes ud, men du er enig i, at de i vid udstrækning er gætte om, hvad de gør. Det er en knap med blå baggrundsfarve, hvidfarve, 10px polstring, inline-block display, markørmarkør og ændret til redbackground-farve på hover.

Hvis du allerede har installeret Web Maker, skal du åbne det ved at klikke på Web Maker-ikonet i din Chrome-browsers øverste højre side. Indsæt ovennævnte HTML i HTML-kodruden, og vælg Atomic CSS som tilstanden i CSS-koderuden. Så snart du gør dette, vil du se nogle automatiske CSS, der er genereret i CSS-kodepanelet, sådan:

Den CSS, du ser, genereres af Atomizer-værktøjet, som jeg nævnte ovenfor. Grundlæggende læser den HTML (eller en hvilken som helst fil), registrerer ACSS-klasser fra dem og genererer CSS til de registrerede klasser. Så du skriver bare HTML med passende klasser, du vil bruge, og CSS genereres automatisk!

Nu hvor vi ved, hvordan du gør styling i ACSS, så lad os se, hvordan det er den bedste CSS-metode, dit team kan have.

Inline, men ikke inline

Som du kan se skriver vi altid klasser inline på tags. Det var hvad jeg mente med inline styling. Men vær venlig ikke at forveksle det med "inline-stilarter". I modsætning til inline-stilarter oversætter vores inline-klasser til faktiske CSS-klasser i et cachbart typografiark. Så dybest set får vi den samme magt som inline-stilarter (skriver ting hurtigt) men får stadig fuldstændig gyldig atomisk CSS som output.

Ikke mere navngivning!

Min absolutte yndlingsfordel. Du behøver aldrig nogensinde at tænke et dejligt, semantisk og ikke-modstridende navn for en klasse.

Et meget berømt ordsprog siger:

Der er kun to hårde ting i Computer Science: cache-ugyldighed og navngivning af ting. - Phil Karlton

Super nemme opdateringer og refactoring

Gå til HTML og skift klasser for at opdatere noget styling. Fjern enhver klasse hvor som helst uden frygt for at ødelægge noget andet sted.

Ikke en byte af ubrugt CSS

Da Atomizer genererer CSS fra de klasser, du faktisk har brugt, har du aldrig ubrugt CSS i dit typografiark. Er det ikke den skøre præstation, vi alle har været på udkig efter? Der er også et værktøj, hvor du kan kontrollere, hvor meget et websted kan drage fordel af ACSS - https://atomize-io.herokuapp.com/

Ingen retningslinjer for nye udviklere

Alt hvad du behøver for at give en ny udvikler som en del af din CSS-onboarding er en syntaksvejledning til ACSS og et klassehenvisningslink - https://acss.io/reference. Dette er en side, hvor du nemt kan søge i ACSS-klassen efter enhver egenskab: værdi. Selv denne konvention integreres i din hukommelse, mens du fortsætter med at bruge den.

Der er også en smuk lille Visual Code-udvidelse af Pankaj Parashar, som automatisk foreslår disse klasser lige i redaktøren. Så selv referencen er ikke påkrævet med denne udvidelse. Onboarding af udviklere er færdig!

Bortset fra disse fordele er der flere flere godbidder, som ACSS kommer med.

  • Vi bruger normalt de samme gamle egenskab / værdipar på tværs af en app. Således stopper det genererede stilark væsentligt med at vokse efter et bestemt punkt. Fordi hvert unikt egenskab / værdipar kommer en gang i det endelige typografiark.
  • På grund af ovenstående punkt kan du faktisk bruge det samme stilark på tværs af din pakke med flere produkter, da det aldrig ville være så stort. Samme cache cd-stilark til alle produkter!
  • Træk anmodning, der føles som en drøm. Forestil dig pull-anmodninger, hvor du ikke kan se nogen .css-filer. Ikke mere at kontrollere klasser for meningsfuldhed eller specificitetskonflikter. Fordi du ved, at korrekt atomisk CSS, som skulle være til stede, ville blive genereret. Var det ikke et vidunderland?

Myte busting

Der er udviklet en masse myter om ACSS på tværs af Internettet. Dette skyldes en lav vurdering af rammerne og vurderingen ved første øjekast.

Det er det samme som inline-styling. Det er dårligt!

Nej det er ikke. Vi har allerede set ovenfor. Det er bestemt så kraftfuldt som inline-styling, men arver ingen ulemper ved det.

Det er svært at skrive alle de samme sæt klasser igen og igen.

Ja det er. ACSS siger, at det er en komponentbaseret ramme. Hvis du ikke templerer hver af dine komponenter og allerede duplikerer HTML, siger du at oprette en knap hver gang, ACSS er ikke noget for dig.

For eksempel skal du oprette knapper ved hjælp af en abstrakt knapkomponent som sådan:

 Hello World 

som skulle samles til noget som:

 Hello World 

Klasserne giver overhovedet ingen mening

Jeg er enig i, at de er forskellige og kan se frastødende ud ved første øjekast. Men alle atomklasserammer har sin egen konvention om at navngive ting. Og tro mig, ACSS har det bedste fra navnekonventionen. Læs mere om, hvorfor de valgte sådan navngivning.

Jeg vil gerne citere et afsnit fra en af ​​Harry Roberts artikel:

Et almindeligt argument mod BEM er, at det er grimt; Jeg tør sige, at hvis du holder sig væk fra kode, der udelukkende er baseret på dens udseende, mangler du ofte pointen. Medmindre koden bliver unødvendig vanskelig at vedligeholde eller virkelig vanskeligere at læse, er du måske nødt til at tænke to gange, før du bruger den, men hvis den 'bare ser mærkelig' ud, men har et gyldigt formål, skal det bestemt overvejes fuldt ud før afskrive det. - Harry Roberts

Men her er vi ved at bruge BEM til at gøre vores kodebaser sane.

Jeg vil ikke være i stand til at gøre X-ting i ACSS

Du vil blive forbløffet over at se, hvad alt er muligt ved blot klasser, der leveres i ACSS. Pseudo-elementer, flexbox, medieforespørgsler, du navngive det. Og den konvention, de kom med til at gøre alle disse ting, er simpelthen genial! Selvom der måske er visse ting, som endnu ikke er muligt i ACSS, som CSS Grids, kan du altid åbne et problem eller bidrage til Atomizer.

Til sidst

Jeg vil bede dig om at prøve ACSS, hvis du forstår smerten ved at skrive og administrere CSS i et team. Og husk, at brug af ACSS betyder ikke, at du ikke kan skrive almindelig CSS. Værktøjer skal bruges, hvor de fungerer bedst. Hvis der er noget, du føler almindelig CSS ville være mere passende til, skal du bestemt bruge det.

ACSS er ikke alene om denne tilgang. Der er lignende alternativer som Blowdry CSS, Cell CSS osv., Der hver bringer deres egen stil for at opnå den samme ting.

Hvis du har spørgsmål angående ACSS, kan du pinge Thierry Koblentz, manden selv fra ACSS-teamet, på Twitter. Stil et spørgsmål ved den FAQ-kompilering, som han vedligeholder eller slutter sig til Atomizer-gruppen på Gitter. Eller skriv kommentarerne til denne artikel.

Til sidst vil jeg gerne takke Thierry Koblentz og Jitendra Vyas for gennemgangen af ​​denne artikel.

Hvis du kan lide denne artikel, skal du vise din kærlighed ved at klappe på artiklen. Følg mig også på Twitter, hvor jeg deler flere frontend-artikler og sideprojekter af mine.

Mere at læse

  • https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach/ - af Thierry Koblentz
  • Atomizer GitHub repo - https://github.com/acss-io/atomizer
  • ACSS-dokumentation - https://acss.io/quick-start.html
  • Ofte stillede spørgsmål om ACSS udarbejdet af Thierry - https://github.com/thierryk/ACSS-QA
  • ACSS legeplads - https://webmakerapp.com