Atomic Design a gyakorlatban

Gyors munkával minőséget. Sokunkban megfogalmazódik e cél. De vajon lehetséges? Ha időt szeretnénk megspórolni, akkor az újra felhasználható (egymásra épülő) elemek buildelése és a kódolás hatékonysága az elsődleges a fejlesztés fázisában. Korábban túl sok egyedi komponenst gyártottuk a moduláris elgondolás ebben is segített, hogy ezeket átgondoljuk és felülbíráljuk, összevonjuk.

Moduláris fejlesztés: Atomic Design

A Brad Frost féle Atomic Design elvet követve, kisebb komponensekből építünk egyre nagyobbakat (Atoms > Molecules > Organisms > Templates), míg végül eljutunk a kész oldalig (Pages).

Brad Frost: Atomic Design

S hogy ez minél gyorsabban, vagyis minél kevesebb kód írásával megtörténhessen HTML és CSS preprocesszort használunk. Hosszan lehetne sorolni az érveket pro és kontra, hogy melyik miért jobb, de ez szubjektív döntés. A Jade (most már Pug) és a Stylus mellett tettük le a voksunk. Könnyen használhatók, az alapok pedig gyorsan elsajátíthatók. Nem mellékesen a fejlesztőink többsége a döntés meghozásakor ezekben már nagy tapasztalattal rendelkezett :) A mixinek használatával pedig lehetővé válik a visszafelé származtatás. Vagyis előre megírunk olyan modulokat, melyeket nagyobb egységeknél használhatunk.

A rendszer kidolgozása során több kihívással is szembe kellett néznünk, melyekre nincs mindig egyértelmű válasz, az adott helyzet dönt.

  • Hová soroljuk azon elemeket, melyeket önmagukban ill. egy másik elem részeként is használunk egy oldalon. Biztos, hogy az egyik molekula, a másik pedig organizmus?
  • Egy komponens mennyire legyen általános felhasználású, és mikortól specifikusabb?
  • Ez utóbbiból következik, hogy milyen elnevezést is használjunk? (pl. box-expert -> box-person).
  • Vajon melyik a gyorsabb, ha egy következő projektnél egy az egyben átvehetők a modulok, de a paraméterezhetőség miatt sok feltételt vizsgálni kell, vagy legyen egy alap, és utána több egyedi kialakítású komponens?

Build tool

Bár végeredményként statikus HTML fájlok keletkeztek, azonban az ezen az elven fejlesztett weboldalak többsége mögött egy saját fejlesztésű CMS található.

Újabb kihívással találtuk szembe magunkat: CMS integrálása a Jade kódba. Mivel az előfeldolgozókat fordítani kell, megoldást kellett találnunk arra a problémára, ha olyan kódrészlet kerül a többi közé, amivel vagy nem tud mit kezdeni, vagy rosszul értelmezi. Szükségünk lett egy eszközre, mely a Jade-ből PHP-, a Stylus-ból CSS file-t generál. A CMS tagek egy részét mixinként használjuk, ha pedig erre nincs lehetőség, akkor javascript segít a fordításban.

Ez lett a Build tool, mely egy gulp task futtató rendszerbe helyezett automata eszköz. Mivel node.js-ben írtuk, bármilyen platformon könnyen telepíthető és használata is egyszerű. A gulp taskok moduláris felépítése miatt, könnyen karbantartható a rendszer. Az Atomic Design lényege, hogy az egyes komponenseket külön-külön építjük fel, ezért nehéz lenne a változásokat minden modulban nyomon követni. Ebben segít a build tool, amely figyeli a file-okat és amint változás történik, frissíti az adott felületet. Emellett az összes modulhoz tartozó stylus kódot egy file-ba másolja, lefordítja majd minify-olja. A javascript kódokat egy config alapján megkeresi és szintén az előbbi módszert követve jár el.

Újabb kihívás elé kerültünk: optimalizálni kellett a build-elés sebességét. Egyre több és több modul megírása, majd azok egymásba ágyazása következményeként egyre több időbe telt a fordítás. (Érdekesség: OSX-en még így is látványosan gyorsabb volt Win10-hez képest.) A megoldás az lett, hogy egy Jade file-ban történő mentés esetén figyeljük, hogy mely másik helyen hivatkozunk az adott mixin-re, s csak azok esetében történék build-elés.

Viszont az eszköz még mindig nem olyan gyors, mintha csak egy CSS szabályt, vagy HTML kódrészletet módosítanánk. Mentéskor a futási idő, egy sok modult tartalmazó projekt esetén elérheti a 10–15 mp-et is.

Styleguide generator

Több ügyfél esetén is megfogalmazódott az igény, hogy szeretnének egy Stílus leírást kapni, melyben láthatják, hogy az oldaluk milyen komponensekből épül fel, milyen színeket, font stílust vagy éppen ikonokat használ. Ezért a Build tool mellett írtunk egy másik eszközt a Styleguide generatort. A meglévő modulokat lefordítja, majd összegyűjti és csoportosítja, s végül egy általa létrehozott oldalon megjeleníti egymástól elkülönítve az Atomokat, Molekulákat, Organizmusokat és Template-eket. Ezen a felületen azonban már tartalmat is meg kell jeleníteni ahhoz, hogy teljes képet kaphassunk egy modulról, vagy akár egy teljes oldalról.

Újabb kihívás: mit és hogyan jelenítsünk meg a CMS tag-ek helyén. Hogy ne kelljen sok-sok sort újra megírni, ezért az eddigi kódot példákkal egészítettük ki. A leghasznosabb az lenne, ha a véglegesnek szánt tartalommal dolgozhatnánk, de erre általában nincs lehetőség. Így egy file-ból valójában két különbözőt fordítunk, attól függően, hogy CMS sablont, vagy Styleguide-ot szeretnénk generálni. Bár ezzel növeltük a file méretét, mégis csökkentettük ezáltal a fejlesztésre fordított időt.

Konklúzió

Tapasztalatunk szerint nem az első projektnél érződik e rendszer haszna. Sőt, első alkalommal tovább is tartott, mintha a hagyományos módszert követtük volna. De minél több atomic elemet “gyártunk”, később annál nagyobb a paletta, amiből újra választhatunk. Természetesen nem minden alkalommal lehet egy az egyben átvenni más projektekből a kódot, kisebb-nagyobb változtatásra szinte mindig szükség lesz.

Azonban mi minden partnerünknél hosszú távon gondolkodunk, így számunkra az Atomic Design használata elkerülhetetlen. Ugyanakkor ezt minden egyes projektnél érdemes átgondolni, mert például egy egyedi kampány oldal esetében nem célszerű ezt a módszert alkalmazni, míg egy meglévő márkánál, ahol folyamatosan szükség van újabb és újabb érkeztető oldalakra, már nagy hasznát vehetjük az előre definiált elemeknek.

Az Atomic Design-nak több vetülete is van: UX, UI. Erről egy előadást is tartottunk: Atomic Design a gyakorlatban címmel.