Share
Atomisk design er en metodikk som beskriver fornuftig kodestruktur for stilark. Den har et stort følgende, men jeg finner at navngivningskonvensjonene noen ganger kan være tvetydige. Hva er et molekyl? Hva er en organisme? Hvordan vet vi hvor du skal tegne linjen mellom de to? Disse spesielle spørsmålene synes å være den største hindringen for å tolke en atomarkitektur.
Atomer, molekyler, organismer, maler og siderI dag skal vi diskutere hva jeg bruker, bestemte fasetter av atomkonstruksjonens konvensjoner som jeg sliter med, hva jeg har gjort for å løse mine problemer, og hvordan jeg for tiden organiserer Sass ved hjelp av for eksempel 7-1-mønsteret.
Brad Frost, forfatter av Atomic Design, har siden klarert det faktum at metodene faktisk ikke dikterer noen CSS-struktur. I stedet tilbyr den en mental modell for å tenke på å konstruere brukergrensesnitt. Beklager Brad!
"Vi designer ikke sider, vi designer systemer av komponenter." - Stephen Hay
Jeg elsker atomdesign og ideologier, men jeg har funnet at de kan kollapse når de jobber med teammedlemmer som ikke er godt kjent med hvordan alt fungerer. Tidligere brukte jeg følgende mappestruktur:
Mapporganisasjon: rot / css / src /
- vars - funksjoner - mixins - base - plugins - typografi - atomer - molekyler - organismer - maler - sider - stater - utility style.scss
Innenfor style.scss Sass partials importeres ved hjelp av gulp-sass-glob-import:
Sass Import Index-fil: rot / css / src / style.scss
// Config @ import "vars / *"; @import "funksjoner / *"; @import "mixins / *"; // Bower Components @ import "... / bower_components / normalize-scss / _normalize"; // Generelt DOM velg stiler @import "base / *"; // Fonts & General Type Styling @ import "typografi / *"; // 3rd Party Addons @ import "plugins / *"; // Atomic Design @import "atomer / ** / *"; @import "molekyler / ** / *"; @import "organismer / ** / *"; @import "maler / ** / *"; @import "sider / ** / *"; // Variasjoner gjennom hendelser @ import "stater / *"; // General UI Helpers @ import "utility / *";
Ordren med dette oppsettet virker ganske mye. Hvis et "atom", "molekyl" eller "organisme" må justeres, vil deklarasjoner i maler eller sider tilsidesette de nevnte delene, sammen med alle andre delvise forrige.
Ordren tillater også overstyringer til et plugins styling, hvis det måtte oppstå (og vanligvis gjør det i min erfaring).
Mye av innholdet for hver atomkatalog (atomer, molekyler, organismer, maler, sider) vil inneholde deler som i teorien er enkle å finne og lett å håndtere når det trengs.
- atomer - _buttons.scss - _links.scss - _inputs.scss - molekyler - _navigation.scss - _search-form.scss - _contact-form.scss - organismer - _header.scss - _footer.scss - _content.scss - maler - _sticky- footer.scss - _grid-2column.scss - _grid-3column.scss - sider - _home.scss - _about.scss - _contact.scss
Organisasjonen virker fornuftig hvis du er klok til Atomic Design, men faller for noen som ikke er kjent med tilnærmingen og nomenklaturen. En utvikler uvitende om Atomic Design vil ikke gi mening om at et søkeskjema ligger innenfor molekyler katalog, og kan sette av søk i andre områder for å gjøre endringer, eller bare bli frustrert og lage en ny fil; Jeg har sett det skje.
Fra tidspunktet for denne skrivingen tar jeg en tilnærming som viser elementer som komponenter, som lego-blokker, og dermed skaper en brukervennlighet for alle som er involvert i kodebase. Ta en titt på følgende katalogstruktur:
- vars - funksjoner - mixins - base - typografi - plugins - verktøykasse - komponenter - layout - sider - stater - utility style.scss
Forhåpentligvis kan du se ved dette eksempel at det er ganske intuitivt å samle formålet med hver mappe (med unntak av verktøykasse). "Verktøykasse" er et sted å lagre hjelpere som ikke er relatert til verktøy, for eksempel egendefinerte klasser for layout og objektmønstre, egendefinerte keyframe-animasjoner og så videre. Disse verktøybokselementene, for meg, opphører vanligvis som deler jeg kan overstyre eller kanskje vil i fremtiden, og hvorfor de blir importert før komponentkatalogen.
På dette stadiet lastes partialer inn i stilenes indeks slik:
// Config @ import "vars / ** / **"; @import "funksjoner / *"; @import "mixins / *"; // UI @import "... / bower_components / normalize-scss / _normalize"; @import "base / *"; // generell styling ved hjelp av DOM element selectors @ import "typografi / *"; @import "plugins / ** / *"; // tredjepart add-ons @import "verktøykasse / ** / *"; // Non-Utility Helpers @ import "komponenter / ** / *"; // lego blokker @import "layout / ** / *"; @import "sider / ** / *"; @import "states / ** / *"; @import "verktøy / ** / *";
"Komponenter" vil inneholde deler av brukergrensesnittet, for eksempel knapper, innganger, logoer, avatarer, header, bunntekst, skjemaer og til og med moduler som navigasjon. Komponenter kan være alt, så lenge de gjør en ting og bare en ting, gjenbrukbar, gjenbrukes over prosjektet og viktigst uavhengig. Ikke en dårlig definisjon for å bli universelt forstått hvis du spør meg. Denne spesielle tilnærmingen implementerer også ulike ideer fra SMACSS (stater) og atomdesign (maler-kalt layout i dette eksemplet og sider).
I form av måte å finne det er mye lettere å finne komponentkatalogen og finne det korrelerende grensesnittet, kan en utvikler spore ned; for eksempel:
- komponenter - _buttons.scss - _navigation.scss - _masthead.scss - _footer.scss - _logo.scss - _avatar.scss - _contact-form.scss - _sales-calculator.scss
I hovedsak er komponenter en one-stop-butikk. Atomdesign kan virke perfekt for et lag av en, eller til og med et lag som er nært kjent, men i en større lagstilling kan frustrasjonen føltes.
Atomdesign kan absolutt brukes til å holde minimal styling på elementer for å skape meningsfulle og gjenbrukbare grensesnittkomponenter. Men du kan finne visse aspekter forvirrende. Bestem deg selv hva som fungerer best for deg og trekk konklusjoner fra det. Som med alt, er dette bare min erfaring og andre kan ha en annen holdning.
Jeg vil gjerne høre hvordan du nærmer deg dette scenariet selv så la meg få vite det i kommentarene. Glad å kode alle sammen!
Accentsconagua