Suurte CSS-projektide haldamine ITCSS-iga

Harry Roberts esineb Loo Bangalore 2. detsembril. Ära maga maha tema juttu CSS-i ümbertegemine ilma meelt kaotamata , milles ta jagab oma näpunäiteid ja tehnikaid CSS-i käsitlemiseks. Broneeri kohe saada asutajaliikmeks ja saada 50% soodsamalt kõigilt tulevastelt konverentside genereerimisele kogu maailmas!

CSS-i arhitektuur näib olevat praegu mõnevõrra moes. See on asi, mida olete kahtlemata viimase aasta jooksul mitu korda maininud ja millel on hea põhjus: kasutajaliidesed (ja neid loovad meeskonnad) muutuvad suuremaks ja keerulisemaks kui kunagi varem.

CSS-il on mitmeid aspekte, mis muudavad selle tülikaks. See on deklaratiivne, st puudub loogika ega juhtimisvoog, mis räägiks teistele arendajatele palju projekti olekust või ehitusest. See töötab globaalses nimeruumis, mis tähendab, et saame kokku põrkumisi, lekitavaid stiile ja tahtmatuid taandarenguid. See kasutab pärandit, muutes kõik mõnevõrra üksteisest sõltuvaks ja rabedaks. Lõpuks võib paratamatu spetsiifilisuse mudel põhjustada probleeme, kui valijad võitlevad üksteisega silmapaistvuse nimel.

Need on kõik iseenesest probleemid, kuid mis tahes mõistlikus mahus töötades saavad need kas otseselt ilmsemaks või on selliste probleemide tekkimise tõenäosus statistiliselt palju suurem. Sisestage CSS-i arhitektuur: viis oma CSS-i kavandamiseks ja struktureerimiseks suurte ja pikaajaliste projektide jaoks.

Tutvustame ITCSS-i

Arhitektuuri, mida täna vaatame, nimetatakse ITCSS - 'Inverted Triangle CSS'. See on metoodika, mis hõlmab kogu CSS-projekti visualiseerimist kihilise, tagurpidi kolmnurgana. See hierarhiline kuju tähistab mudelit, mis aitab teil oma CSS-i tellida kõige tõhusamal ja vähem raiskaval viisil. Süveneme!

ITCSS on asi, millega olen ühel või teisel kujul tegelenud juba umbes neli aastat. Pole juhus, et ka viimased neli aastat olen töötanud eranditult digitaalsete toodete kallal: suured, pikaajalised projektid, kus terved inseneride meeskonnad töötavad kuude kaupa samal koodibaasil.

Just sellises keskkonnas (pärand, uued funktsioonid, arvukad kaastöötajad, suur kiirus, kogunenud tehnovõlg, sidusrühmade vastuolulised mured) on meie kirjutatud koodiga vaja palju rohkem hoolsust ja ülesehitust. Sellepärast leiutasingi ITCSSi; aidata nende suurte projektidega tegelevatel arendajatel oma CSS-i paremini korraldada, laiendada ja hallata.

Mida ITCSS soovib teha, on pakkuda formaalsuse ja struktuuri taset oma CSS-i kirjutamise viisile. See ei ole suur kõrvalekalle normist, mis tähendab, et üleminek ITCSS-ile ei tohiks osutuda liiga keeruliseks. Pealegi, kui enamik arhitektuure ja lähenemisviise püüab vältida CSS-i ärritavaid aspekte, võtab ITCSS need omaks ja taltsutab neid ning paneb need meie kasuks tööle. ITCSS määratleb projekti ühised aspektid loogiliselt ja mõistlikult, pakkudes samas kindla kapseldamise ja lahtisidumise taseme, mis kaitseb jagamata aspekte üksteise sekkumise eest.

ITCSS on ka uskumatult paindlik. See ühildub teiste metoodikate, nagu SMACSS, OOCSS ja isegi BEM, aspektidega. Seda saab vastavalt vajadusele pikendada või tagasi lükata, vastavalt projektile. See töötab eelprotsessoriga või ilma ja see ei kehtesta mingeid konkreetseid nimetamisviise (kuigi ma soovitaksin teil seda alati kasutada). See paindlikkus tähendab, et ITCSS-i saab kasutada igas suuruses või stiilis projektis.

Eeldused

Enne spetsiifikatesse süvenemist on ITCSS-iga töötamisel mõned eeldused. Kõik need on muutumas iga kaasaegse kasutajaliidese arendaja tavapraktikaks. Esiteks pole CSS-is ID-sid. ID-d on spetsiifilised raskekaallased ja nende kasutamine ajab meie spetsiifika täielikult liigestest välja.

Teiseks peate töötama komponeeritud kasutajaliidese arhitektuuriga. Te ei lähtu enam mudelist 'lehed', vaid vidinate / moodulite / komponentide mustrist (ITCSS nimetab neid 'komponentideks'). Ehitate korduvkasutatavate komponentidena eraldiseisvaid, iseseisvaid kasutajaliidese tükke.

Lõpuks nõuab ITCSS, et pooldate klassipõhist arhitektuuri. Te ei karda oma HTML-ile klasside lisamist; te ei usu, et 'vähem märgistamist' ja 'puhast märgistust' on sama asi; ja saate aru, et klassidele sidumine paljaste HTML-elementide asemel annab kindla ja skaleeritava arhitektuuri.

Lugege, kuidas CSS-i ümber kujundada, ilma et meelt kaotaksite, lehelt Generate Bangalore

Lugege, kuidas CSS-i ümber kujundada, ilma et meelt kaotaksite, lehelt Generate Bangalore

Peamised mõõdikud

ITCSS on täielikult hallatud arhitektuur, mis tähendab, et see ütleb teile, kuidas kogu oma CSS-projekti koostada. See ei ütle teile lihtsalt, kuidas näiteks oma komponente ehitada, vaid aitab teil hallata kõike alates Sassi arhitektuurist kuni algallikate järjekorrani, madalat tüüpi tüpograafiliste stiilideni kuni teemade kujundamiseni ja palju muud.

ITCSS töötab tellides kogu CSS-projekti kolme peamise mõõdiku järgi. Vaatame neid nüüd.

Ebatavaline või läbimõtlemata allikakord võib viia stiilide ebakorrapärase ja hüpliku rakendamiseni

Ebatavaline või läbimõtlemata allikakord võib viia stiilide ebakorrapärase ja hüpliku rakendamiseni

01. Üldine selgesõnaliseks

Alustame kõige üldisemate, madalama taseme, kõikehõlmavate, tähelepanuväärimatute stiilidega ja jõuame projekti käigus edasi liikudes selgemate ja konkreetsemate reegliteni. Alustame lähtestamisest ja seejärel liikume veidi ulatuslikumate reeglite, nagu h1–6 {} juurde, kuni ülimalt selgesõnaliste reegliteni, näiteks .text-center {}.

02. Madal spetsiifilisus kõrge spetsiifilisusega

Kõige madalama spetsiifilisusega selektorid ilmuvad alguse poole, mille spetsiifilisus projekti edenedes pidevalt suureneb. Tahame tagada, et välditaksime võimalikult palju spetsiifilistest sõdadest, seega püüame hoiduda kõrgema spetsiifilisusega selektorite kirjutamisest enne madalama spetsiifilisusega valijaid. Lisame alati spetsiifilisuse samas suunas, vältides seeläbi konflikte.

03. Kaugeleulatuv lokaliseeritud

Projekti alguse valijad mõjutavad paljusid DOM-i, kusjuures koodibaasi läbimisel väheneb see ulatus järk-järgult. Tahame DOM-ist läbi minna, kirjutades reegleid, mis seda järk-järgult vähem ja vähem mõjutavad.

Alustuseks võiksime veerised ja padjad kõigelt maha pühkida, seejärel võiksime stiliseerida igat tüüpi elemendid, seejärel kitsendada seda kuni igat tüüpi elementideni, millele oleks rakendatud teatud klass jne. Kolmnurga kuju annab just see haarde järk-järguline kitsendamine.

Nende projektide tellimisel nende peamiste mõõdikute järgi on mitmeid eeliseid. Saame hakata globaalselt ja kaugeleulatuvaid stiile jagama palju tõhusamalt ja tõhusamalt, vähendame oluliselt spetsiifiliste probleemide tõenäosust ning kirjutame CSS-i loogilises ja progressiivses järjekorras. See tähendab suuremat laiendatavust ja vähem üleliigsust, mis omakorda tähendab vähem raiskamist ja palju väiksemaid failisuurusi.

Kihid

Pööratud kolmnurga kolm peamist mõõdikut

Pööratud kolmnurga kolm peamist mõõdikut

Nendest mõõdikutest saame kinni pidada, jagades oma CSS-i mitmeks osaks või 'kihiks'. Iga kiht tuleb viia sellisesse kohta, mis vastab kõigile kriteeriumidele. Enamik inimesi (ja arhitektuure) üritavad CSS-i projekte jagada temaatilistesse rühmadesse: siin on meie tüpograafilised stiilid, siin on meie vormistiilid, siin on meie pildigalerii stiilid. Negatiivne külg on see, et see ei ole eriti sümpaatne CSS-i toimimise suhtes ega telli CSS-i viisil, mis kaskaadi, pärandit või spetsiifikat kõige paremini ära kasutab, taltsutab või ära kasutab.

ITCSS-is on iga kiht loogiline edasiminek viimasest. Selle spetsiifilisus suureneb, see muutub selgemaks ja kavatsemaks ning kitsendab kasutatud selektorite haaret. See tähendab, et meie CSS-i on oma olemuselt hõlpsam skaleerida, kuna kirjutame selle järjestuses, mis ainult lisab varem kirjutatule. Me ei raiska aega varem arvestatud CSS-ide tagasivõtmisele ega alistamisele.

See tähendab ka seda, et igal asjal ja igat tüüpi asjadel on oma järjekindel, ennustatav koht elamiseks. See muudab nii stiilide leidmise kui lisamise palju lihtsamaks, mis on eriti kasulik, kui teil on mitu arendajat, kes panustavad koodibaasi.

ITCSS-il on vaikimisi seitse kihti. Vaatame neid kõiki nüüd järjest.

01. Seaded

Kui kasutate eeltöötlust, alustage siit. See sisaldab teie projekti mis tahes globaalseid seadeid. Tahaksin rõhutada sõna globaalne - see kiht peaks sisaldama ainult seadeid, millele tuleb juurde pääseda kõikjalt. Seaded, nagu $ title-size-1, tuleks määratleda osalises jaotises Headings. See tagab, et see kiht jääb kena ja õhuke ning tähendab, et enamiku seadetest võib leida neid kasutava koodi kõrval, mis muudab asjade leidmise palju lihtsamaks.

Globaalsete seadete näited võivad olla näiteks fondi põhisuurus, värvipaletid, config (näiteks $ environment: dev;) ja nii edasi.

02. Tööriistad

Järgmine kiht sisaldab teie globaalselt saadaolevaid tööriistu - nimelt miksiine ja funktsioone. Kõik segud või funktsioonid, millele pole vaja globaalselt juurde pääseda, peaksid kuuluma selle osasse, millega see on seotud. Tööriistakiht tuleb kihi Seaded järel, kuna mixin võib vaikeparameetrina nõuda ühte globaalsetest sätetest. Globaalsete tööriistade näideteks võivad olla gradientmiksid, fontide suuruse muutmine ja nii edasi.

03. Üldine

Üldine kiht on esimene, mis tegelikult CSS-i toodab. Selles on väga kõrgetasemelised ja kaugeleulatuvad stiilid. Seda kihti muudetakse harva ja see on tavaliselt sama kõigi projektide puhul, millega töötate. See sisaldab selliseid asju nagu Normalize.css, globaalsed kastide suuruse määramise reeglid, CSS-i lähtestamised ja nii edasi. Üldine kiht mõjutab paljusid DOM-e, seega on see kolmnurga mudelis kena ja lai ning esineb väga varakult.

04. Elemendid

Need on tühjad, klassifitseerimata HTML-elemendid. Kuidas näeb h1 välja, kui sellel pole klassi? Kuidas näeb välimus välja, kui sellel pole klassi? Elementide kiht seondub ainult paljaste HTML-elementide (või 'tüüpi') valijatega. See on veidi selgem kui eelmine kiht, kuna me ütleme nüüd 'tee iga h1 sellest suureks' või 'tee igast a teatud värviks'. See on endiselt väga madala spetsiifilisusega kiht, kuid mõjutab veidi vähem DOM-i ja on veidi arvatavam, seega ka asukoht kolmnurgas.

Elementide kiht on tavaliselt viimane, kust võiksime leida paljad elemendipõhised valijad, ja seda lisatakse või muudetakse pärast esmast seadistamist väga harva. Kui oleme elemendi tasemel stiilid määratlenud, tuleks kõik täiendused ja kõrvalekalded rakendada klasside abil.

05. Objektid

OOCSS-i kasutajad tunnevad objektide mõistet. See on esimene kiht, kust leiame klassipõhised valijad. Need on seotud mittekosmeetiliste kujundusmudelite või 'esemete' kujundamisega. Objektid võivad ulatuda nii lihtsast kui .wrapper-elemendist kuni paigutussüsteemideni kuni OOCSS-i plakati lapse - meediaobjektini. See kiht mõjutab vähem DOM-i kui viimane kiht, sellel on kõrgem spetsiifilisus ja see on veidi selgem, kuna sihime nüüd DOM-i jaotisi klassidega.

06. Komponendid

Komponentide kiht on koht, kus hakkame kujundama kasutajaliidese äratuntavaid tükke. Oleme siiani klassidega seotud, nii et meie spetsiifilisus pole veel suurenenud. Kuid see kiht on selgesõnalisem kui viimane, kuna me kujundame nüüd DOM-i selged ja kujundatud tükid.

Me ei peaks sellest kihist leidma ühtegi madalama spetsiifilisusega valijat. Siin toimub suurem osa teie tööst pärast projekti esialgset seadistamist. Uute komponentide ja funktsioonide lisamine moodustab enamasti valdava osa arendusest.

07. Trumbid

See kiht võidab - või 'trumpab' - kõiki teisi kihte ja tal on võim alistada kõik, mis enne seda on olnud. See on ebaoluline ja raskekäeline ning sisaldab kasulike ja abistajate klasse, häkkeid ja alistamisi.

Paljudel selle kihi deklaratsioonidel on! Oluline (nt. Tekstikeskus {text-align: center! Oluline;}). See on kõrgeim spetsiifilisuse kiht - see hõlmab kõige kitsama fookusega reegli liike. See kiht moodustab kolmnurga punkti.

Selle kihilise, võtmemõõdikutel põhineva ITCSS-i lähtekorralduse lähenemisviisi järgimine annab meile stiilide mõistliku rakendamise kogu meie projektis

Selle kihilise, võtmemõõdikutel põhineva ITCSS-i lähtekorralduse lähenemisviisi järgimine annab meile stiilide mõistliku rakendamise kogu meie projektis

Nii et selle asemel, et rühmitada asju „tüpograafilisteks stiilideks” või „vormistiilideks”, jagame need rühmadesse, mis põhinevad spetsiifilisusel, haaretel ja seletusel. See vorming võimaldab meil oma CSS-i kirjutada järjestuses, mis ainult lisab ja pärineb varasemast.

Me kulutame asjade tühistamisele väga vähe aega, sest meie kaskaad ja spetsiifilisus on kõik ühes suunas. Me vähendame drastiliselt kokkupõrgete, lekete ja uuesti määratluste hulka.

Kui kujutame kolmnurka uuesti ette koonusena, võime selle alla vaadata, et näha iga kihi ulatust

Kui kujutame kolmnurka uuesti ette koonusena, võime selle alla vaadata, et näha iga kihi ulatust

Osalised

Iga kiht sisaldab rida osalisi. Soovitan nimetamiskorda _ .. scss (näiteks: _settings.colors.scss, _elements.headings.scss, _components.tabs.scss).

Need partiid peaksid olema võimalikult väikesed ja detailsed, kusjuures igaüks neist peaks sisaldama ainult nii palju CSS-i kui vaja oma ülesande täitmiseks. Nii et _elements.headings.scss sisaldaks ainult reegleid h1 kuni h6 ega midagi muud. Kui teil on näiteks lehe pealkirja komponent, mis paneb pealkirja (nt h1) ja alapealkirja (nt h2) teatud viisil välja nägema, loote kiht komponendid _components.page-title.scss osalise ja seotakse klassidele (nt .page-title, .page-title-sub), mitte HTML-elementidele.

Nii toimib ITCSS: me ei paiguta kõiki oma rubriikidega seotud stiile. Selle asemel paigutame kõik oma elemendipõhised reeglid ja kõik klassipõhised reeglid kokku. Tellime projekti nüüd kasulike CSS-mõõdikute põhjal ega loo ebamugavaid spetsiifilisusi ja kaskaadgruppe, tellides projekti temaatiliste tükkidena.

Tulemus

Kui see kõik kokku saab, võib see välja näha umbes selline:

@import 'settings.global'; @import 'settings.colors'; @import 'tools.functions'; @import 'tools.mixins'; @import 'generic.box-sizing'; @import 'generic.normalize'; @import 'elements.headings'; @import 'elements.links'; @import 'objects.wrappers'; @import 'objects.grid'; @import 'components.site-nav'; @import 'components.buttons'; @import 'components.carousel'; @import 'trumps.clearfix'; @import 'trumps.utilities'; @import 'trumps.ie8';

Isegi selles väikeses näites näete, kuidas iga kiht võib sisaldada suvalist arvu osalisi ja need osalised võivad teoreetiliselt istuda mis tahes @import-järjekorras, mida soovite. Ainus nõue on, et kihid ise püsiksid alati selles moodustises.

Tagame, et iga kiht sisaldab CSS-i järgmistest osadest:

  • Sarnane eripära: kõik elemendipõhised selektorid või kõik klassipõhised valijad või kasuliku klassid!
  • Sarnane selgitus: kõigi oma paljaste HTML-elementide või kasutajaliidese komponentide kujundamine või spetsiifiliste abiklasside kujundamine
  • Sarnane haare: võime mõjutada kogu DOM-i (nt * {}), DOM-i alamhulka (nt {}), DOM-i osa (nt. Karussell {}) või konkreetset DOM-sõlme (nt. parandus {})

Selline põhjalik lähenemine annab meile palju hallatavama CSS-i arhitektuuri. Nüüd teame, et kõik, mis lisame, peaks olema täiendus sellele, mis on enne seda käinud. Me teame, kus iga reegli tüüp hakkab elama ja kuhu uusi stiile panna, ning oleme kindlad, et kõik meie erinevad valijad mängivad kenasti üksteise kõrval.

Kui soovite ITCSSi lähemalt uurida, vaadake Harry Robertsi sissejuhatavat juttu DaFEDis ...

Kas vihkate pärand CSS-iga töötamist? Ära igatse Harry Robertsit Loo Bangalore edasi rääkima CSS-i ümbertegemine ilma meelt kaotamata . Broneeri kohe nautida seda ja teisi juhtivate veebinimede, sealhulgas Jonathan Snooki, Stephanie Riegeri ja Shikhar Kapoori kõnelusi.

See artikkel ilmus algselt väljaande 267 väljaandes netiajakiri .