Varför ska man använda SCSS istället för Styled Components?

Efter att ha jämfört populära lösningar som vanlig CSS, Emotion, SCSS och Stylade komponentervalde jag till slut den sista. Allt verkade vara bra. Det har ett mycket populärt bibliotek nuförtiden, vilket innebär
det finns redan ett stort samhälle så om jag skulle möta några problem, hittar jag förmodligen en lösning någonstans på Stack Overflow eller GitHub. Förutom det, Stylade komponenter har vissa optimeringsfunktioner som innebär att de bara renderar när de behövs. De projekt förväntades byggas med hjälp av React och Typescript. Det här biblioteket har bra stöd för båda teknikerna. Låter fantastiskt, eller hur?

Jag började koda då. Efter en månad, när appen har vuxit, har frontend Team och jag fokuserade på att leverera funktioner, upptäckte vi att den fantastiska Stylade komponenter biblioteket hade sitt eget mål och jag ska berätta varför.

Först av allt, namnkonventionen. För att särskilja Stylade komponenter från React-komponenter var jag tvungen att använda Stylad prefix som minskade kod läsbarhet. Sedan (vilket kanske är konstigt), stöd för Typescript. Stylade komponenterär, som du kanske vet, baserade på CSS-in-JS-metoden. Detta innebär att du kan skicka vilken prop som helst till dem och ändra stilen på, dvs. inmatningen baserat på denna prop och jag tycker personligen att den här funktionen är fantastisk. I Typescript bör du också implementera typen av denna prop gör det kod längre någon Stylad komponent. "Men det skulle ju ta 5 sekunder till, så vad är problemet", kanske du säger. Du har rätt, även om när appen skalas upp snabbt och antalet komponenter är
ökar, kan dessa 5 sekunder lätt multipliceras med hundratals gånger. Ett annat problem är placeringen av Stylade komponenter.

Några JS-utvecklare placerar dem i samma fil som den komponent de tillhör, medan andra skapar separata filer för dem. Båda tillvägagångssätten är bra av många skäl. Det beror mest på hur komplex komponenten är. Att följa en av dessa tekniker kan upprätthålla sammanhållningen men att slå samman dem ger precis motsatsen. Vi övergav CSS-in-JS-metoden och migrerade till SCSS. Det var inte lätt och snabbt men med lite hjälp så klarade vi det. Vi började styla html-taggar enligt BEM-metoden och lade naturligtvis stilarna i separata filer, en per komponent. Jag sa att passera JS props till Stylade komponenter är en fantastisk funktion, men i SCSS det är omöjligt. Jag tror också att vi alla är överens om att den syntax som React vill använda för att koda villkorliga klasser är hemsk.

Det finns en ganska intressant lösning. Om du kopplar ihop BEM-metoden med clsx bibliotek, får du något liknande detta (stort tack till min vän Przemek Adamczyk för att du visade mig detta bibliotek)

Ser mycket renare ut, tycker du inte?

Det bästa är att du bara behöver skriva in villkorsvariabeln på komponentnivå och
inte på stylingnivå. Det sparar verkligen tid. Tyvärr har en sådan lösning sina nackdelar.
SCSS är enkelt och användarvänligt, men var försiktig när du använder det med Next.js. Detta ramverk gör inte
gör det möjligt att importera stilfiler direkt till komponentfilen (endast CSS-moduler).

Om du föredrar en fil per komponent måste du skapa index.scss som innehåller alla dina SCSS filer och
importera den till _app.tsx fil. Det enda problemet är att du manuellt måste importera varje SCSS fil som du har skapat. I React finns dock inte detta problem och du kan importera SCSS filer var du vill. Missförstå mig inte. Stylade komponenter är riktigt bra. Som jag sa tidigare är passering av JS-variabler samt det globala temat fantastiska funktioner. När du bygger en stor app där optimering är avgörande kommer det här biblioteket förmodligen att uppfylla dina behov. I vårt fall skulle dock migreringen till SCSS slå jackpotten.

Sammanfattningsvis

Sammanfattningsvis, även om det finns giltiga argument för både SCSS och Styled Components i webbutveckling Det slutgiltiga beslutet beror på flera olika faktorer. SCSS erbjuder en mer välbekant syntax för erfarna utvecklare i traditionell CSS och ger en sömlös integration med befintliga kodbaser och komponentbibliotek .

Å andra sidan.., Stylade komponenter erbjuda förbättrad erfarenhet som utvecklare med sin förmåga att kapsla in stilar i komponenter och förenkla stylingprocessen. Det främjar också kodmodularitet och återanvändbarhet, vilket gör det möjligt för frontend-ingenjörer att effektivt hantera komponentkatalog och skapa ett konsekvent användargränssnitt i hela webbapp . Med tanke på betydelsen av Användardata säkerhet och prestanda är det viktigt att bedöma hur de båda metoderna påverkar den slutliga paketstorleken och laddningstiderna. I slutändan är valet mellan SCSS och Styled Components bör baseras på de specifika behoven i projektet, kompetensen hos de personer som utvecklingsteam och de övergripande målen för webbapplikation . Det är tillrådligt för utvecklare att utvärdera alla faktorer, hålla sig uppdaterade genom Blogginlägg och branschdiskussioner, och fatta ett välgrundat beslut som överensstämmer med deras projektkrav och förbättrar den övergripande utvecklingsprocess för front-end .