Share
Noen gang lurt på hvordan et stort nettsted som Tuts + holder sin CSS, HTML og JavaScript i orden for fortsatt utvikling og iterasjon? Jeg skal vise deg prosessen vi har implementert for å holde det helt ryddig og vedlikeholdsdyktig.
Det første trinnet i denne prosessen var å finne en måte å bygge den store mengden CSS vi trenger som ikke uunngåelig vil ende i kaos.
Tradisjonelt med CSS, bygger du opp stiler som du trenger dem, og streber etter å gjøre selektorer bredt anvendelige slik at de kan gjenbrukes på hele nettstedet. For eksempel, her er noen enkle CSS-regler som ikke ville føle seg ute av sted i de fleste stilark:
h1 skriftstørrelse: 22px; .subtitle font-size: 18px;
Hvis du må overstyre disse velgerne i en bestemt del av en side, kan du bruke nestede regler til å konstruere selektorer som retter seg mot flere spesifikke elementer:
.site-header h1 font-size: 40px; .site-header .subtitle font-size: 28px; .site-header a.navigation color: # 136FD2 ...
Denne tilnærmingen føles intuitivt riktig, men det kan ha noen betydelige problemer når du kommer til et nettsted som har mer enn noen få sider, og som flere enn en utvikler jobber med.
Hva skjer når vi endrer stylingen av h1 eller .undertittel på et globalt nivå? skriftstørrelse Overstyres allerede av en mer spesifikk stil, men hvis vi legger til en font-vekt eller linjehøyde det blir det ikke. Eventuelle endringer som gjøres i de globale stilene kan ripple ut og påvirke mer spesifikke stiler på måter som ikke er forutsigbare uten en intim kjennskap til alle stiler på nettstedet..
Jo flere stiler som er bygget på denne måten, desto mer uttalt «bivirkninger» av interaksjonelle CSS-stiler vil være, noe som krever kjedelig prøve og feil å sette riktig, og til slutt fører til tap av produktivitet og flere bugs som kryper gjennom til produksjon.
For å forhindre dette problemet vedtok vi en tilnærming til CSS basert på BEM-metoden. I stedet for å definere stiler som gjelder globalt, sies alle stiler inn i selvforsynte "blokker" ved hjelp av en navngivningskonvensjon. En "blokk" er mer eller mindre definert som en enkelt frittstående innholdsenhet som kan gjenbrukes (selv om det ikke er obligatorisk at det faktisk blir gjenbrukt).
For eksempel, la oss ta en titt på "featured-sections" -blokken:
Ifølge vår navngivningskonvensjon har denne blokken en rot div element med klassenavnet kjennetegnet profiler. Den inneholder elementer med klassenavn som verdig-sections__title og verdig-sections__section-link.
Vi bruker en tilsvarende navngivningskonvensjon for kildekoden, som alle stilene for dette verdig-seksjonen blokk er lagret i moduler / featured_section.sass:
.Utvalgte-seksjoner: 0 0 $ Gutter-bredde 0 polstring-topp: 8px border-top: 4px solid # dae1e5 .featured-sections__title color: # 8fa6b3 font: fet 14px / 1.2em $ font
Denne navngivningskonvensjonen sikrer at stilarter ikke lenger konflikter og blander seg. Så lenge vår navngivningskonvensjon blir fulgt, med blokknavnet ved starten av hvert klassenavn, er det umulig for en stil å påvirke noe utenfor egen blokk.
Det gjør det også veldig enkelt å finne ut hvor du skal se i kodebase for stiler som svarer til et element. Du kan bare se på elementets klassenavn, og du vil kjenne navnet på stilarket for å åpne.
Vi har valgt å gå videre og bruke denne navngivningskonvensjonen til våre synspunkter også. Hver blokk har en visning delvis med samme navn, lagret under visninger / moduler. For eksempel HTML-visningen for vår kjennetegnet profiler blokkere liv i visninger / moduler / _featured_sections.html.slim:
På samme måte som det å ha en navngivningskonvensjon for våre CSS-filer, gjør det enkelt å finne en CSS-stil. Å ha denne navngivningskonvensjonen for våre synspunkter gjør det enkelt å finne visningskode. Dette kommer til nytte når du ser på en side i en nettleser og legger merke til en bestemt del som trenger noen endringer gjort. Du kan bare gjøre et "Inspect Element" og bruke blokknavnet klart synlig i et elements CSS-klasse for å hjelpe deg å hoppe rett til den aktuelle visningsfilen.
Vi har også gått videre og vedtatt de samme navngivningskonvensjonene for JavaScript-koden vår, med litt hjelp fra Backbone.js.
Hver blokk som trenger JavaScript-adferd som brukes, får et ryggradsbildeobjekt ved hjelp av dette samme blokknavnet:
Accentsconagua
klassen window.AccountHeader utvider Backbone.View events: 'endre .account-header__mobile-menu-select': 'mobileMenuChange' mobileMenuChange: -> document.location = @_selectedOption () .data ('url') _selectedOption: -> @ $ 'alternativ: valgt'Vi har skrevet noen visningsladingskode som blir brukt på sidebelastning, slik at riktig Backbone-visning automatisk lastes for hvert element med en CSS-klasse som samsvarer med en liste over blokker med tilhørende JS.
Vi bruker samme filnavngivningskonvensjon for vår JavaScript-kode også, noe som resulterer i strukturen for en fullverdig blokk som ser slik ut:
Jeg vil anbefale denne tilnærmingen til et hvilket som helst prosjekt. Jeg tror det er uvurderlig når du jobber med et stort prosjekt, og selv om du jobber på et mye mindre område, er det egentlig ingen ulempe å strukturere front-end-koden din på en modulær måte.
Når det er sagt, kan du støte på problemer som prøver å bruke denne strategien hvis du allerede har en betydelig mengde globale CSS-stiler, eller hvis du stole på CSS-biblioteker som Twitter Bootstrap. Siden BEM-stiler bruker et enkelt klassenavn som selector, har de en svært lav CSS-spesifisitet, og har en tendens til å bli trukket på av globale CSS-stiler som ofte har flere nivåer av nestede selektorer, samt tagnavn og ID-er.
Det er definitivt fortsatt mulig å flytte fra en global CSS-stil til en mer modulær BEM-stil, og jeg vil argumentere sterkt verdt det på lang sikt. Men forvent å ha litt sværere tid å bygge BEM-stilene på en stund, og vær forberedt på å leve med å legge til minst et par midlertidige !viktig erklæringer gjennom hele ditt CSS, til du er i stand til å fullstendig bli kvitt dine globale stiler.
