CSS-in-JS är på modet. Men är det verkligen det bästa alternativet?
Lösa problem du inte behöver lösa
Missförstå mig inte, CSS-in-JS är en bra lösning, men det är för ett problem som de flesta inte har. Att underhålla dina komponenter på ett mycket tyst sätt hjälper absolut saker som:
- Oavsiktliga biverkningar av överlappande stilar
- Hjälpa team att organisera sina regler
- Att undvika att trampa varandra på tårna under utvecklingen
Men de blir egentligen bara problem med stora team med många utvecklare och ett stort bibliotek av komponenter.
Så vad vill du att jag ska använda?
För att utgå från en lite högre synvinkel kan du ta för vana med några grundläggande idéer:
- Ställ in och följ några grundläggande regler för att skriva
- Använd verktyg eller sätt standarder för organisation
- Utvecklas med metoder som BEM
Detta kommer att eliminera alla dessa problem på ett mindre projekt (eller stort) och kan faktiskt göra livet enklare.
Vad CSS-in-JS är bra på...
Hjälper stora team att bevara förståndet
En del av varför denna lösning finns är för att väldigt stora team har svårt att undvika konflikter när de har ett enormt bibliotek att hantera. Att kunna ha din komponent och allt som påverkar den i ett avdelat område hjälper människor att undvika att trampa på varandras fötter och eventuellt rulla ut justeringar som oavsiktligt faller över hela appen. Det här är bra, men mer troligt än inte är du en av få (eller ensam) som arbetar med en liten app. Om du och ditt team inte kommunicerar om vissa grundläggande regler och standarder, skulle jag hävda att ni har större problem.
Typ eliminerar behovet av att lära sig CSS (typ av)
Vissa utvecklare hånar CSS och säger att det inte är riktig kod, andra är rädda för att det är magi (var inte, omfamna den). Att bara behöva oroa sig för några få regler i en komponent hjälper människor att känna sig lugna med att veta att det bara är lite mer JS som ändrar hur det ser ut lite.
Vad kan båda göra?
Hot Module Reloading (HMR)
Även om vissa säger att en fördel med CSS-in-JS är HMR, kommer du att tycka att detta fungerar bra med stilmallar. Ibland fungerar det faktiskt lite bättre om du arbetar med en komponent som kräver en återgivning, till exempel de med en nätverksbegäran som ett beroende, där CSS-ändringarna inte tvingar fram den återgivningen.
Variabler, Globala inställningar
Om någon argumenterar för att CSS inte kan göra det, är det för att de inte har varit uppmärksamma på ett tag. Sass tillhandahåller inte bara detta, det är inbyggt i moderna webbläsare.
Inkapsling
Ja, du behöver inte JS för att göra detta. Lägg till ett klassnamn till elementet på översta nivån av komponenten eller sidan, kapsla in alla stilar och du har din inkapsling.
.page-about {
.header {
background-color: red;
}
}
.navigation {
.button {
background-color: blue;
}
}
Ludd
https://stylelint.io/
Mycket mer
Ärligt talat, det finns förmodligen mycket mer som båda gör på liknande sätt som du bara inte inser.
Vad stilmallar och SASS gör bättre...
Regeldelning och konfiguration
SASS låter dig konfigurera variabler, anpassade funktioner och mixins som tar din CSS-utveckling till nästa nivå.
Ignorera de dåliga väljarnamnen:
// settings.scss
$color-ultraviolet: #5F4B8B;
// colbys-styles.scss
@import "settings";
.colbys-text-color {
color: $color-ultraviolet
}
.colbys-background-color {
background-color: $color-ultraviolet
}
Även om syntaxen och konfigurationen av detta utan tvekan är enklare än att sätta upp ett gäng objektkonfigurationer i JS, låter detta dig i hög grad tillhandahålla konsekventa visuella upplevelser och TORKA upp din kod.
Responsiv design
En av många saker som bidrar till rollen som en bra frontend-ingenjör är att uppmärksamma hur projektet kommer att se ut på flera enheter och storlekar. Sammantaget är UX allas jobb. Att utvecklas med ett responsivt-först-tänk gör inte bara den processen lättare, det hjälper till att bygga en bättre produkt.
Att försöka göra dina komponenter responsiva i JS innebär mer Javascript och fler evenemangslyssnare. Detta ökar inte bara komplexiteten, det slår även ner på prestanda. Vi kan göra detta mycket enklare med mediefrågor inbakade direkt i CSS.
.colbys-sidebar {
width: 100%;
}
// NO EVENT LISTENERS
@media (min-width: 1024px) {
.colbys-sidebar {
width: 25%;
}
}
Istället för att behöva strypa evenemangslyssnarna, se till att dina evenemangslyssnare avregistrerar sig vid avkoppling och bara ta itu med att organisera allt på "reagerande sätt", utlöser mediefrågor på begäran och kommer att vända dina stilar efter behov på ett mer konsekvent sätt .
Mindre komplexitet för dina komponenter
Att kunna fokusera på funktionaliteten och den renderade utdata låter dig undvika att dra in bibliotek eller komplexa metoder för att i huvudsak patcha CSS i din JS, för att inte tala om JS-hacket eller två eller tre som du använder för att få det att fungera i första plats.
// This is an exaggeration
const styles = {
color: blue;
}
if ( whos_favorite === 'Colby' || whos_favorite === 'Lord Commander' ) {
styles.color = 'ultraviolet';
} else if ( whos_favorite === 'The Gary' ) {
styles.color = 'red';
} else if ( whos_favorite === 'Mooncake' ) {
styles.color = 'green';
} else if ( whos_favorite === 'HUE' ) {
styles.color = 'blue';
} else if ( whos_favorite === 'KVN' ) {
styles.color = 'yellow';
}
<MyCompnent styles={styles} />
Prestanda
Mindre Javascript är alltid en vinst. Det är mindre att din webbläsare behöver ladda, mindre att din webbläsare behöver kompilera, vilket i slutändan kommer att översättas till snabbare sidhastighet. När webbläsaren laddar en sida försöker den optimera HTML och CSS så mycket som möjligt. Ja, du laddar förmodligen mer CSS i förväg, men mer JS är mycket kostsamt och är också mer sannolikt att tvinga fram en fullständig återgivning;
Många av de små magiska bitarna du gör med Javascript kan göras med några ganska kraftfulla CSS-animeringsmetoder, bara bläddra lite i Codepen eller kolla in något som Animista.
Jag har faktiskt inga siffror om detta förutom några bra anteckningar och några CSS-i-JS-riktmärken. Har någon gjort det här?
I slutet av dagen, gör det som är effektivt
Alla har sina personliga preferenser, alla är produktiva på olika sätt. Gör det som är bäst för dig, gör det som är bäst för ditt team och undvik att behandla vad andra utvecklare säger som dogmatiska rättigheter och fel.
Om du är en ensam utvecklare på ett projekt och vill träna CSS-in-JS för att vänja dig vid det när du är i ett stort team, gör det! Om du är i ett stort, stort team på Facebook och vill använda stilmallar, kan du stöta på problem om alla inte följer samma riktlinjer, utan gör det som är bäst för dig och ditt team.
Det enda sättet du kan ta reda på det är med erfarenhet och experiment. Lek med båda lösningarna och ta reda på varför DU tycker att den ena är bättre än den andra. Du vet aldrig var du hamnar efter att ha landat den där spelningen på Google eller din nya startup i ditt garage.
Få mer innehåll direkt i inkorgen!
- 🐦 Följ mig på Twitter
- 📹 Prenumerera på min Youtube-kanal
- 🗞️ Anmäl dig till mitt nyhetsbrev
Ursprungligen publicerad den 18 juli 2019 på colbyfayock.com