Cell on kirjasto, jonka olen kehittänyt auttamaan käyttöliittymäkomponenttien muotoilussa Sassin avulla. Tämä artikkeli on lyhyt johdatus pariin käsitteeseen, joiden (jos Sass on sinulle tuttu) pitäisi tuntua tutuilta. Näitä käsitteitä kutsutaan nimillä Cell Atoms ja Cell Molecules.
Cell Atom on yksittäinen CSS-ominaisuus, joka tulostaa kaksi erilaista arvoa, joita sovelletaan elementtiin jonkun välitetyn asiayhteyden perusteella. Tässä tapauksessa konteksti voi tarkoittaa esimerkiksi tiettyjen modifikaattoreiden/seudotilojen läsnäoloa tai sitä, onko elementti/jokin vanhemman elementin elementti leijutettu vai ei jne. Tämä on useimmiten hyödyllistä, kun ominaisuuksia vaihdetaan jonkin tapahtuman tai vuorovaikutuksen perusteella.
Esimerkkinä voidaan käyttää display-ominaisuutta elementin piilottamiseen/näyttämiseen. Se, onko display-ominaisuuden arvo none vai jotain block, riippuu kyseisestä asiayhteydestä tai ehdosta. Tavallisessa Sassissa tämä voisi näyttää jotakuinkin seuraavalta:
…mikä näyttäisi elementin, kun sillä on active-luokka. Jos haluaisimme näyttää elementin, kun tietyllä vanhemmalla on sen sijaan active-luokka, tämä voisi näyttää jotakuinkin seuraavalta:
Voidaan esittää tämä esimerkki jonkin CSS-in-JS API:n avulla, joka voisi näyttää jotakuinkin seuraavalta:
…tässä näemme, kuinka JavaScript-esimerkissä määritellään vain yksi display-ominaisuus, jonka arvo on dynaaminen. Tämä arvo arvioitaisiin uudelleen joka kerta, kun context-objekti muuttuu, ja elementti maalattaisiin uudelleen sen mukaisesti.
Sass-esimerkissä, ottaen huomioon CSS:n kaskadoituvan luonteen (ja dynaamisuuden puutteen), määrittelemme useita display-ominaisuuksia kaskadoituvalla tavalla ja annamme spesifisyyskamppailun määrittää loput. Koska Sassissa on funktioita, voisimme ajatella kiertää tämän luomalla mukautetun context-funktion jäljittelemään CSS-in-JS:ssä tapahtuvaa käyttäytymistä, jotakuinkin näin:
Mutta tämä ei voisi koskaan toimia – tämä voisi aina kääntyä vain yhdeksi ainoaksi CSS-säännökseksi (käyttäen mitä tahansa arvoa, joka on arvioitu kääntämisaikana). Sass voisi arvioida context('.someParent.active', block, none) vain kerran, ennen kuin se lähetetään asiakkaalle, ja siten luoda vain yhden CSS-säännön, kun taas JavaScript voisi arvioida context.someParent.active ? 'block' : 'none' lennossa.
Parasta, mitä voisimme tehdä, olisi erilliset Mixinit jokaiselle kiinnostavalle ominaisuudelle. Tätä Mixiniä kutsuttaisiin Cell Atomiksi. Jos käytettäisiin Cellin käyttöä ja display Atomia, yllä oleva esimerkki voitaisiin pelkistää muotoon:
…joka, kuten huomaat, on nyt hyvin samankaltainen kuin CSS-in-JS-versio, ja jäljelle jää vähemmän koodia, joka on yhtä luettavaa. Tämä voisi nyt, konepellin alla, tulostaa kuinka monta CSS-ominaisuutta tahansa haluamissamme säännöissä. Yllä oleva koodi olisi syntaktista sokeria:
… ja itse asiassa jokainen Cell Atom -esimerkki esitettäisiin hupun alla samalla tavalla kuin yllä (ja Atomille välitetty konteksti välitettäisiin alaspäin context Mixiniin).
Tämä konsepti on käyttökelpoinen tietyissä tapauksissa, joissa tietyt kontekstit vaativat vain yksittäisen CSS-ominaisuuden muokkaamista, esimerkki hide/show on yleisin mieleeni tuleva käyttötapaus. Jos sinun pitäisi soveltaa useita CSS-ominaisuuksia elementtiin jonkin välitetyn kontekstin/ehdon perusteella, sinun pitäisi käyttää context Mixiniä.
Voi tietysti ajatella, että erillisten Mixinien käyttäminen jokaista ominaisuutta varten on liikaa, ja olisit oikeassa, kun otetaan huomioon, että CSS-ominaisuuksia on noin 800? Useimpia CSS-ominaisuuksia ei kuitenkaan pitäisi käyttää tällä tavalla – vain ominaisuuksia, jotka vaikuttavat ulkoasuun/toiminnallisuuteen (ja silloinkin vain silloin, kun yksittäinen ominaisuus kontrolloi yhtä käyttäytymistä, kuten hide/show). Tavoitteena on abstrahoida toistuvat mallit koostettavissa oleviksi Mixineiksi, mikä parantaa Sass-koodipohjan selkeyttä ja ylläpidettävyyttä. Cell Moleculeja käytettäessä (kutsuttaessa) ei välitetä CSS-ominaisuuksia tai -arvoja, toisin kuin Cell Atomeja kutsuttaessa.
Tämä on periaatteessa melko samanlainen kuin Bourbon Sass-kirjastossa (erona on se, että Cell Molecule ottaa vastaan kontekstin syötteen ja antaa tulosteen useista kontekstiin perustuvista säännöistä). Ottaen edellisen hide/show esimerkin, tämä voitaisiin abstrahoida Cell-molekyyliksi ja käyttää näin:
… periaatteessa kertomalla Cellille: ”Piilota tämä elementti, jollei läpäisty ehto täyty, missä tapauksessa näytä se”. Tarvittavat toiminnot (eli none– tai block-arvojen soveltaminen) hoitaisi hypoteettinen show Mixin. Yllä oleva olisi syntaktista sokeria:
… vastaa (periaatteessa) tätä aiemmin näkemäämme vanilla Sass -esimerkkiä:
Ei ole mitään varsinaista kovaa tapaa kelpuuttaa jotakin CSS-joukkoa solumolekyyliksi; se voi olla mikä tahansa abstrakti ja toistuva kuvio, joka edellyttää oletustilaa, joka muuttuu jonkun asiayhteyden perusteella.
Solumolekyylit ovat vain filosofia/käsite; tällä hetkellä ei ole olemassa Cell Molecules-kirjastoa tai mitään
Johtopäätöksinä
Niinkin, kuin Cell-atomit ja Cell-molekyylit palvelevat erilaista päämäärää, molempien perimmäinen tavoite on pitää tyylit koostettavampina. Käyttämällä Celliä ja tunnistamalla atomeja ja molekyylejä koodipohjassasi (tai ennakoimalla/ennustamalla niitä, jos luot uutta projektia/ominaisuutta) voit varmistaa, että koodipohjasi on tiiviimpi ja semanttisempi ja vähemmän täynnä erilaisia CSS-ominaisuuksia, jotka epäilemättä lätkäistään päälle ilman todellista järjestystä.
Katsomalla tämän artikkelin eri esimerkkejä vierekkäin voimme saada paremman käsityksen näiden käsitteiden taustalla olevista motiiveista (muista, että kaikilla näillä esimerkeillä saavutetaan sama asia):
Monissa tapauksissa sinun pitäisi harkita, onko tarvetta luoda Molecule jollekin asialle – yllä olevassa esimerkissä, jossa Molecule vaikuttaa vain yhteen CSS-ominaisuuteen, voi olla käytännöllisempää pitäytyä display Atomin käytössä.