Styling beste praksis ved bruk av React

Foto av Pankaj Patel på Unsplash

En av de mest morsomme delene av å jobbe på nettet er at du kommer til å jobbe i et slikt visuelt medium. Jeg er en stor del av det visuelle aspektet slik det ser ut. Styling av en webside har kommet langs fra de tidlige røttene til å legge til markering og attributter for å endre ting som skrifter og farger, til Cascading Style Sheets i dag. Nå i vår verden av webapplikasjoner og JS Frameworks, har nettet utviklet seg og det har også god praksis. Dette gjelder spesielt når du jobber i et rammeverk som React.

Hvordan "styler" du websiden din ved hjelp av reaksjon?

Reager, på egen hånd og uten noe annet verktøy, støtter to måter å style elementer på: stilstøtten, stilkoden og CSS stilarkene. Style-rekvisitten tar et JS-objekt med CSS-egenskaper og verdier og oversetter det til slutt for å inline stiler av et element, som dette:

// JSX
   Rød tekst   // DOM
   Rød tekst

Siden det bare er inline-stiler, får du fremdeles den høyeste spesifisiteten, men du er begrenset av hva du har tilgang til stil.

Stilkoden og CSS stilarkene fungerer på samme måte som å jobbe med ren HTML-merking. Den største forskjellen er at du må bruke theclassName prop i stedet for klasse. Både id-prop og className-prop bruker enten en streng eller et uttrykk som evalueres til en streng, slik:

// jsx
// DOM

Å opprettholde CSS i skala kan bli veldig utfordrende, slik at React-samfunnet har bygget verktøy som forbedrer utvikleropplevelsen i å opprettholde CSS i skala. Det er flere som er opprettet, men de to største er sannsynligvis CSS-moduler og CSS-in-JS (og mer spesifikt stylede komponenter / følelser).

CSS-moduler lar deg behandle en CSS-fil som en JS-modul. Du importerer en CSS-fil, og klassene i CSS-filen blir behandlet som egenskaper på et JS-objekt, som dette:

importer css fra './index.css';
// DOM

Du vil legge merke til at klassen som til slutt ble brukt, var navnet på klassen pluss en hasj. Denne hasjen er lagt til klassen for å sikre at den er unik i appen vår.

Dette gjør at utvikleren ikke trenger å vite hele omfanget av appen, og hvordan CSS som vi skriver kommer til å påvirke resten av Cascade. Det er faktisk typisk for hver komponent å ha sin egen CSS-fil tilknyttet den når du bruker CSS-moduler. CSS-moduler må aktiveres som en del av en byggeprosess, for eksempel i Webpack for å kunne dra nytte av verktøyet.

Stylet-komponent og følelser er to veldig populære biblioteker som oppfyller samme mål som CSS-moduler, men som går ut på det på en annen måte. Begge bibliotekene drar nytte av den taggede mal letteral syntax, introdusert i ES6. Enkelt sagt er taggede malformater funksjoner som påberopes med malmalstrenger. Funksjonen analyserer malmalene og kan fungere deretter.

Hvordan disse bibliotekene fungerer er at du skriver CSS som en malstreng, funksjonen analyserer malstrengen, sprøyter den inn i en stilkode i dokumentet, og returnerer en komponent med den aktuelle klassen som allerede er injisert i den. Her er et eksempel på hvordan det fungerer (eksemplet bruker stylede komponenter, men følelser bruker et nesten identisk API):

import stylet fra 'stylede komponenter';
const Layout = styled.div`
   skjerm: rutenett;
`;
// DOM

Som du ser, når det samme mål som CSS-modul, men i stedet for å opprette scoped-klassen på byggetid, bygger den CSS-enheten på kjøretid. Dette tillater mange kule funksjoner som er utenfor omfanget av dette innlegget, men jeg vil oppfordre deg til å sjekke dem ut i dokumentene for stylede komponenter og følelser.

Med alle disse måtene å style, hva er den beste måten å style? Mye er subjektivt og avhenger virkelig av utvikleren eller utviklerteamets preferanser. Når det er sagt, er det noen gode fremgangsmåter som har dukket opp.

Inline Styles er ikke lenger "Dårlig"

Noe av det første jeg lærte da jeg lærte CSS, var at inline-stiler var dårlige, ikke skalerte godt og bør unngås for enhver pris. Men det er viktig å forstå grunnene til at de blir ansett som “dårlige”.

Innlagte stiler anses som dårlige fordi inline-stiler bare gjelder det bestemte elementet. Hvis du trenger å reprodusere den samme stilen, for eksempel en primærknapp, må du kopiere og lime inn fra en del av appen til en annen. Når du tar del i feiende stilendringer og stiler som bare er delvis de samme på tvers av to elementer, har du et mareritt å opprettholde.

I et komponentbasert rammeverk, som React, er dette ikke en faktor lenger. Hvis du har behov for et stylet element mer enn ett sted, bruker du den samme komponenten begge steder. Hvis stilen endres for begge elementene, har du fremdeles bare en komponent å oppdatere, så den har ikke de samme skaleringsproblemene som når du jobber med HTML direkte.

Inline stiler gjør det også mulig å konfigurere stiler via rekvisitter. Du kan eksponere visse elementer via rekvisitter som skal konfigureres av brukeren av komponenten din. Hvis du har stilkonstanter som brukes universelt på nettstedet ditt, kan disse opprettholdes i en mappe med stilkonstanter og importeres i. Her er et eksempel på hvordan alt som kan gjøres:

Denne metoden er ikke perfekt. Linjestiler gir for eksempel ikke tilgang til pseudovelgere eller mediesøk. Men det er ikke verst å bruke inline-stiler lenger og bør absolutt være en del av en utviklers verktøykasse.

Komponenter skal ikke plassere seg selv

I et komponentbasert rammeverk, som React, skiller vi bekymringene våre på et komponentnivå, dette inkluderer stilene. En komponent vet ikke hvor det blir gjengitt, og heller ikke hvem det er søsken hvis det er noen. Den vet heller ikke hvordan den blir plassert. Foreldrene bruker for eksempel flex-box, css-rutenett, flytere eller absolutt posisjon. Så det er ingen måte for deg å angi verdier som margin, posisjon, flex-self eller noen annen egenskap som den.

Dilemmaet er at CSS ikke er designet rundt et komponentbasert rammeverk, og at mange av disse egenskapene må stilles på barnetrinnet, noe som betyr at barnet trenger å "vite" om omgivelsene til tross for at det ikke vet .

Hvordan kommer vi oss rundt dette? Det er 3 måter vi kan gjøre dette på. En måte er å eksponere klassenavn og / eller stilutstyr for å tillate stiler å bli injisert i, som dette:

const Widget = ({className = '', ... rekvisitter}) =>
         
//eller
const Widget = ({style = {}, ... rekvisitter}) =>
        

Den potensielle ulempen med dette er at det åpner opp for andre stiler for å bli overskrevet, noe som ofte er uønsket, spesielt når du arbeider i et designsystem. For å beskytte mot dette, kan du legge stilene dine, som du ikke vil bli overskrevet, sist. Du kan gjøre det slik:

const Widget = ({className = '', ... rekvisitter}) =>
         
//eller
const Widget = ({style = {}, ... rekvisitter}) =>
        

En annen måte å gjøre dette på er å eksplisitte eksponere spesifikke verdier, for eksempel margin eller posisjon. Komponenten din kan da gjøre logikk for å sikre at rekvisitten er riktig og bruke den. Dette gir deg mer kontroll, men tvinger deg som komponentforfatter til å håndtere hver eneste propell du velger å eksponere.

En tredje måte er å komponere komponenten din i "innpakninger" som har den posisjoneringen innebygd, slik:

const Layout = () => (
   
     
        
     
   
);

Dette gir mer kontroll uten å måtte eksponere spesifikke felt. Men det kan føre til mye indireksjon når du har mye av disse innpakningene over alt. Den beste måten å bekjempe wrapper helvete ville være å komponere dem til sin egen komponent, for eksempel å bruke en Higher Order-komponent.

Stiler bør abstraheres bort

Jeg gikk inn på dette en gang allerede i innlegget mitt om å prøve å gjøre for mye i React Components. Det er mange verktøy du kan bruke til å legge til stiler i komponenten, og hvordan disse stilene brukes er ikke vanligvis viktig når du skal komponere elementene dine sammen. Komponentene våre skal se mindre slik ut:

const SideBar = ({title}) => (
   
     

        {tittel}            
                   ):

Og mer som dette:

const SideBar = ({title}) => (
   
     
        {tittel}
     
     
        
     
   
):

Det andre eksemplet er riktig abstraksjonsnivå når du komponerer SideBar-komponenten. Når jeg komponerer SideBar-komponenten bryr jeg meg ikke hvordan stilen legges til, bare at stilen ble lagt til. Det første eksemplet er mye støyere og bremser evnen til å forstå hva komponenten gjør.

Styling av en webside er veldig viktig for en webside. Slik vår webside ser ut kan lage eller ødelegge et nettsted. Heldigvis har vi mange verktøy og beste praksis som kan hjelpe oss med å levere et fantastisk nettsted som brukeren vår elsker å bruke.