Sådan skriver du bedre CSS i hold med ACSS - Et dynamisk Atomic CSS-bibliotek

At skrive gode Cascading Style Sheets (CSS) er svært, og det bliver sværere 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 får se) CSS. Denne tilgang løser næsten alle de problemer, man står over for i dag med dårligt skrevet CSS i teams.

Men lad mig først opstille nogle grundlæggende betingelser, som min artikel gælder for.

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 findes automatiske værktøjer.
  3. Designere er gratis fugle. Gendesign sker.

Under disse forhold vil jeg præsentere en sølvkugle-løsning, der løser næsten alle de problemer, vi står over for på grund af dårlig CSS (Husk, CSS er ikke dårlig. 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 ønsker at dele med andre udviklere, mine tanker om, hvordan man kan overvinde det. Denne artikel lyder muligvis som salgsfremmende, men det er bare fordi jeg er meget begejstret for at bringe dette frem alle.

Problem nr. 1: Det er svært at navngive klasser

Udvikler 1 (mens kodning) : Ser ud som et overskrift for mig, lad mig bruge .headervælgeren til det.

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

At komme med navne, og det er også meningsfulde navne, er det sværeste problem at løse. Det er også den sværeste 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 skal også sikre, at de ikke kommer i konflikt med andre klassenavne i fremtiden, da en ny udvikler muligvis bruger det samme eller lignende navn til sin klasse.

Løsninger til rådighed:

  • BEM - navngivningskonventioner 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 let det er at følge retningslinjerne). BEM forhindrer muligvis dig i at gå helt ad hoc, men du skal stadig komme med et første klassenavn til dine komponenter.
  • Atomklasser - en anden almindelig fremgangsmåde i disse dage for at gå helt atomare med atomklasser. Små klasser, der kun gør en ting. F.eks. 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 hvis der i fremtiden ikke findes nogen klasse for en bestemt ting? Hvordan tilpasser jeg eksisterende atomklasser efter mit design? Indlæser alle klasser altid på min side, uanset om jeg bruger dem eller ej? Vi har brug for noget mere.

Problem nr.2: Selektorstyrker

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

Løsninger til rådighed:

Den bedste løsning på dette problem er simpelthen at begrænse dine vælgere til en klasse. Ingen sammenkædning, ingen indlejring, ingen id'er. Ovennævnte BEM-navngivning og atomklasser resulterer begge i enkeltklassevælgere i din CSS og dermed hjælp til at løse dette problem.

Problem nr.3: Hvad med ubrugt CSS?

CSS gengiver blokering, derfor er det 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.

Løsninger til rådighed:

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

Problem nr.4: Refactoring

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

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

Udvikler 1 : Åh forbandet! Du har ret ... Jeg savnede det. Denne side X er for kritisk til at røre ved. Ved du, hvorfor udvikleren brugte den samme klasse på begge sider?

Udvikler 2 : Ingen idé. Han forlod virksomheden. Lad os bare lade CSS være, 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 muligt at skrive en god (skalerbar, læsbar, vedligeholdelig) CSS. Imidlertid er det ekstremt vanskeligt at gøre det i et stort hold. Selv hvis du prøver at gøre det rigtigt i et hold, vil det kræve en konstant indsats fra nogen for at håndhæve alle de bedste fremgangsmåder.

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 til noget.

Alt-i-en-løsningen - ACSS (Atomizer)

ACSS (afledt af Atomic CSS) er en komponentbaseret ramme til styling gennem atomklasser udviklet på 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 laver styling i ACSS.

For at følge med kodeeksemplerne 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) på Chrome-browseren.

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

 I am a button

Et forslag - lav ikke nogen vurdering ved det første kig på denne syntaks. Bliv ved med at læse, giv det tid, diskuter og beslut derefter. Klasser på buttontaggen ser muligvis anderledes ud, men du er enig i, at de i vid udstrækning kan antages, hvad de laver. Det er en knap med blå , hvid , 10 pixel , inline-blok , markør og ændret til rød, når den svæver.background-colorcolorpaddingdisplaycursorbackground-color

Hvis du allerede har installeret Web Maker, skal du åbne den ved at klikke på Web Maker-ikonet i din Chrome-browsers øverste højre side. Indsæt ovenstående HTML i HTML-kodepanelet, og vælg Atomic CSS som tilstand i CSS-kodepanelet. Så snart du gør dette, vil du se noget automatisk CSS genereret i CSS-kodepanelet, som sådan:

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

Nu hvor vi ved, hvordan du laver styling i ACSS, 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 det, jeg mente med inline styling. Men forveksl det ikke med "inline-stilarter" . I modsætning til inline-stilarter oversættes vores inline-klasser til faktiske CSS-klasser i et cache, der kan caches. Så dybest set får vi den samme styrke som inline-stilarter (skriver ting hurtigt), men får stadig helt gyldig atomisk CSS som output.

Ikke mere navngivning! ?

Min absolutte favoritfordel. Du bliver aldrig nogensinde nødt til at tænke et godt, semantisk og ikke-modstridende navn til en klasse.

Et meget berømt ordsprog lyder:

Der er kun to hårde ting i datalogi: cache ugyldiggørelse 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 bryde noget andetsteds.

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 vanvittige præstation, som vi alle har ledt efter? Der er også et værktøj, hvor du kan kontrollere, hvor meget et websted kan drage fordel af ACSS - //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 klassereferencelink - //acss.io/reference. Dette er en side, hvor du nemt kan søge i ACSS-klassen efter enhver egenskab: værdi. Selv denne konvention er indlejret i din hukommelse, når du fortsætter med at bruge den.

Der er også en smidig lille Visual Code-udvidelse af Pankaj Parashar, der 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 generelt de samme gamle ejendom / værdipar på tværs af en app. Således stopper det genererede stilark i det væsentlige med at vokse efter et bestemt tidspunkt . Fordi hvert unikke egenskab / værdipar kommer en gang i det endelige typografiark.
  • På grund af ovenstående punkt kunne du faktisk bruge det samme typografiark på tværs af din pakke med flere produkter, da det aldrig ville være så stort. Samme cachelagrede CSS-stilark for 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 flere kontrolklasser for meningsfuldhed eller specificitetskonflikter . Fordi du ved, at korrekt atomisk CSS, som skulle være til stede, ville blive genereret. Vil det ikke være et vidunderland?

Myte sprænger

Der er udviklet mange myter vedrørende ACSS over internettet. Dette skyldes en lav evaluering af rammen og dommen 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 lige 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 skabeloner hver af dine komponenter og allerede duplikerer HTML, skal du sige 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 skal samles til noget som:

Hello World

Klasserne giver slet ikke mening

Jeg er enig i, at de er forskellige og måske ser frastødende ud ved første øjekast. Men hver atomklasseramme har sin egen konvention om at navngive ting. Og tro mig, ACSS har det bedste fra navngivningskonventionen. Læs mere om, hvorfor de valgte en 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 viger væk fra kode, der udelukkende er baseret på dens udseende, mangler du ofte pointen. Medmindre koden bliver unødigt vanskeligt at opretholde, eller virkelig sværere at læse, så måske du behøver behøver at tænke to gange, før du bruger det, men hvis det bare ser mærkeligt ", men har en gyldig formål, så det bør absolut være fuldt overvejes før afskrive det. - Harry Roberts

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

Jeg kan ikke 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 hedder det. Og det stævne, de kom med for at gøre alle disse ting, er simpelthen strålende! Selvom der muligvis er visse ting, der endnu ikke er mulige 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 styre CSS i et team. Og husk, at bruge 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, at almindelig CSS ville være mere passende for, bør du helt sikkert bruge det.

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

Hvis du har spørgsmål vedrørende ACSS, kan du pinge Thierry Koblentz, manden selv fra ACSS-teamet, på Twitter. Stil et spørgsmål i den FAQ-samling, som han vedligeholder, eller tilmeld dig Atomizer-gruppen på Gitter. Eller sæt i kommentarerne til denne artikel.

Endelig vil jeg gerne takke Thierry Koblentz og Jitendra Vyas for at have gennemgået 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 mine sideprojekter.

Mere at læse

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