Hvorfor skal du bruge SCSS i stedet for Styled Components?

Efter at have sammenlignet populære løsninger som almindelig CSS, Emotion, SCSS og Stylede komponenterTil sidst valgte jeg den sidste. Alt så ud til at være i orden. Det har et meget populært bibliotek i dag, hvilket betyder
Der er allerede et stort fællesskab, så hvis jeg får problemer, finder jeg sikkert en løsning et eller andet sted på Stack Overflow eller GitHub. Men derudover.., Stylede komponenter har nogle optimeringsfunktioner, som betyder, at de kun gengives, når der er brug for det. De projekt forventedes at blive bygget ved hjælp af React og Typescript. Dette bibliotek har god understøttelse af begge teknologier. Det lyder fantastisk, ikke?

Så begyndte jeg at kode. Efter en måned, da appen var vokset, blev frontend'en hold og jeg fokuserede på at levere funktioner, fandt vi ud af, at den fantastiske Stylede komponenter Biblioteket havde sit eget mål, og jeg skal fortælle dig hvorfor.

Først og fremmest navnekonventionen. For at skelne mellem Stylede komponenter fra React-komponenter, var jeg nødt til at bruge Stylet præfiks, som faldt Kode læsbarhed. Og så (hvad der måske er mærkeligt), understøttelse af Typescript. Stylede komponenterer, som du måske ved, baseret på CSS-in-JS-tilgangen. Det betyder, at du kan sende en hvilken som helst prop til dem og ændre stilen på, dvs. input baseret på denne prop, og jeg synes personligt, at denne funktion er fantastisk. I Typescript bør du også implementere typen af denne prop, hvilket gør koden længere, hvis du har en Stylet komponent. "Men det ville tage 5 sekunder mere, så hvad er problemet?" - siger du måske. Du har ret, men når appen skaleres hurtigt op, og antallet af komponenter er
Når tiden øges, kan disse 5 sekunder nemt ganges med hundredvis af gange. Et andet problem er placeringen af Stylede komponenter.

Nogle JS-udviklere placerer dem i samme fil som den komponent, de hører til, og andre opretter separate filer til dem. Begge tilgange er gode af mange grunde. Det afhænger mest af komponentens kompleksitet. Hvis man følger en af disse teknikker, kan man bevare sammenhængen, men hvis man fletter dem sammen, får man præcis det modsatte. Vi droppede CSS-i-JS-tilgangen og migrerede til SCSS. Det var ikke nemt og hurtigt, men med lidt hjælp klarede vi det. Vi begyndte at style html-tags i BEM-metoden og lagde selvfølgelig styles i separate filer, en pr. komponent. Jeg sagde, at det at sende JS props til Stylede komponenter er en fantastisk funktion, men i SCSS det er umuligt. Jeg tror også, at vi alle er enige om, at den syntaks, som React vil bruge til at kode betingede klasser, er forfærdelig.

Der er en ganske interessant løsning. Hvis du forbinder BEM-metoden med clsx bibliotek, får du noget i retning af dette (stor tak til min ven Przemek Adamczyk for at vise mig dette bibliotek)

Det ser meget renere ud, synes du ikke?

Det bedste er, at du kun behøver at skrive betingelsesvariablen på komponentniveau og
ikke på stylingniveau. Det sparer virkelig tid. Desværre har sådan en løsning sine ulemper.
SCSS er nem og venlig, men vær forsigtig, når du bruger den med Next.js. Denne ramme gør ikke
gør det muligt at importere stilfiler direkte i komponentfilen (kun CSS-moduler).

Hvis du foretrækker en fil pr. komponent, skal du oprette index.scss der indeholder alle dine SCSS filer og
importere det til _app.tsx fil. Det eneste problem er, at du manuelt skal importere hver enkelt SCSS fil, du har oprettet. I React findes dette problem dog ikke, og du kan importere SCSS filer, hvor du vil. Misforstå mig ikke. Stylede komponenter er virkelig gode. Som jeg sagde før, er overførsel af JS-variabler samt det globale tema fantastiske funktioner. Når du bygger en stor app, hvor optimering er afgørende, vil dette bibliotek sandsynligvis opfylde dine behov. I vores tilfælde var det dog nødvendigt at migrere til SCSS fik jackpot.

Opsummering

Konklusionen er, at selv om der er gode argumenter for begge dele SCSS og stiliserede komponenter i webudvikling Den endelige beslutning afhænger af forskellige faktorer. SCSS tilbyder en mere velkendt syntaks for erfarne udviklere i traditionel CSS og giver en problemfri integration med eksisterende Kodebaser og komponentbiblioteker .

På den anden side, Stylede komponenter tilbyde forbedret udviklererfaring med sin evne til at indkapsle stilarter i komponenter og forenkle stylingprocessen. Det fremmer også kodens modularitet og genanvendelighed, hvilket gør det muligt for frontend-ingeniører effektivt at styre komponentkatalog og skabe en ensartet brugergrænseflade på tværs af web-app . I betragtning af vigtigheden af Brugerdata sikkerhed og ydeevne, er det afgørende at vurdere begge tilganges indvirkning på den endelige pakkestørrelse og indlæsningstiden. I sidste ende er valget mellem SCSS og stiliserede komponenter bør være baseret på projektets specifikke behov, medarbejdernes færdigheder og udviklingsteam og de overordnede mål for webapplikation . Det er tilrådeligt for udviklere at evaluere alle faktorer, holde sig opdateret gennem blogindlæg og branchediskussioner, og træffe en informeret beslutning, der er i overensstemmelse med deres projektkrav og forbedrer den overordnede front-end udviklingsproces .