Atomic Design — alapok, atomok, molekulák és organizmusok a UI-ban

Mi az Atomic Design?

Atomic Design — hierarchikus felületrendszerek létrehozásának módszertana, amelyben minden UI-elem az öt szint egyikéhez tartozik: atomok (alapelemek), molekulák (atomok kombinációi), organizmusok (összetett blokkok), sablonok (oldalvázak) és oldalak (konkrét adatokkal rendelkező képernyők). Az analógia a kémiából származik: az atomok molekulákká, a molekulák organizmusokká, az organizmusok sablonokká egyesülnek, a sablonok tartalommal töltődnek fel és oldalakká válnak.

A módszertant Brad Frost webtervező javasolta 2013-ban, válaszul az "oldal-alapú gondolkodás" problémájára — amikor minden új képernyőt a semmiből terveznek, figyelmen kívül hagyva a meglévő komponenseket. Az "Atomic Design" (2016) című könyvében Frost leírja a módszertan bevezetését nagyvállalati projektekben: IBM, GE, Starbucks. A Nielsen Norman Group (2022) szerint az Atomic Design 30–50%-kal csökkenti az új képernyők tervezési idejét a kész komponensek újrafelhasználásának köszönhetően.

Az Atomic Design — nem annyira technológia, mint inkább a UI-szervezés filozófiája. Nem kötődik egy adott keretrendszerhez, és alkalmazható mind a weben (React, Vue), mind a mobilfejlesztésben (Jetpack Compose, SwiftUI). Az IT Sectr-nél az Atomic Design-t használjuk az ügyfelek tervezési rendszereinek felépítéséhez: az atomi komponenseket a tervezési szakaszban azonosítjuk, és átültetjük őket Compose/SwiftUI kódkomponensekbe.

Öt szint: atomok, molekulák, organizmusok, sablonok, oldalak

Az Atomic Design minden szintje megoldja a saját feladatát, és szigorú felelősségi körrel rendelkezik. Atomok — a felület legkisebb építőkövei, amelyek nem bonthatók tovább jelentésvesztés nélkül: gomb, szövegmező, ikon, címke, jelölőnégyzet. Az atomok nem tartalmaznak üzleti logikát, és nem függnek a kontextustól. Meghatározzák az alapvető vizuális jellemzőket: szín, méret, margók, tipográfia.

Molekulák — két vagy több atom kombinációi, amelyek egyszerű funkcionális egységeket alkotnak. A beviteli mező címkével és hibaüzenettel — molekula. A termékkártya képpel, névvel és árral — molekula. A molekulák tartalmazhatnak alapvető logikát (hiba megjelenítése/elrejtése), de nem tartalmaznak üzleti folyamatokat. A molekulák az első szint, ahol a komponensek újrafelhasználhatóvá válnak a különböző képernyők között.

Organizmusok — összetett felületi blokkok, amelyek molekulákból és atomokból állnak, és az alkalmazás egy konkrét funkcióját valósítják meg. A bejelentkezési űrlap (e-mail mező, jelszó mező, küldés gomb, "elfelejtett jelszó" link) — organizmus. A fejléc logóval, kereséssel és navigációval — organizmus. Az organizmusok tartalmazhatnak üzleti logikát és hozzáférhetnek az API-hoz, de csak a saját funkciójuk keretein belül.

Sablonok — oldalvázak, amelyek meghatározzák az organizmusok elhelyezkedését a képernyőn konkrét tartalom nélkül. A sablon meghatározza a rácsot, oszlopokat, tartalomzónákat — wireframe kód szinten. A sablonok nem tartalmaznak adatokat, csak helykitöltőket. Lehetővé teszik az oldal szerkezetének értékelését a tartalommal való feltöltés előtt.

Oldalak — az alkalmazás konkrét képernyői, ahol a sablon valós adatokkal van feltöltve. Ezen a szinten ellenőrzik, hogy a komponensek hogyan néznek ki valódi tartalommal (hosszú sorok, adatok hiánya, hibák). Az oldalak az egyetlen szint, amelyet a végfelhasználó lát. Az oldalak szintjén végzett változtatások nem érinthetik az atomokat, molekulákat és organizmusokat — ha egy komponenst módosítani kell, a változtatást annak szintjén kell elvégezni, és az oldal automatikusan átveszi azt.

Az Atomic Design előnyei és korlátai

Előnyei az Atomic Design-nak a felületek skálázásakor mutatkoznak meg. Az egységes komponenskönyvtár vizuális konzisztenciát garantál: a gomb minden képernyőn ugyanúgy néz ki, mert ugyanaz az atom. Brad Frost (2016) szerint az Atomic Design-t bevezető vállalatok 30–50%-kal csökkentik az új képernyők fejlesztési idejét a kész molekulák és organizmusok újrafelhasználásának köszönhetően.

Korlátai — az Atomic Design nem írja le, hogyan kell kezelni az alkalmazás állapotát. A módszertan csak arra a kérdésre válaszol, hogy "hogyan szervezzük a UI-komponenseket", de nem érinti az üzleti logikát, az útválasztást vagy az adatkezelést. Második korlát — a határok meghatározásának nehézsége: hol végződik a molekula és hol kezdődik az organizmus? A gyakorlatban a határok elmosódottak, és különböző csapatok eltérően osztályozhatják ugyanazt a komponenst. Javasolt a szabályok rögzítése a tervezési tokenekben és a komponenskatalógusban (Storybook, Jetpack Compose Preview).

Harmadik korlát — túlzott absztrakció kis projektek esetén. Ha az alkalmazás 5 képernyőből áll, az atomok és molekulák hierarchiájának létrehozása felesleges munka. Az Atomic Design akkor válik előnyössé, ha a képernyők száma meghaladja a 20-at, és a komponensek több oldalon is újrafelhasználásra kerülnek.

Atomic Design kontra Feature-Sliced Design

Atomic Design és Feature-Sliced Design (FSD) különböző feladatokat oldanak meg, és együtt is használhatók. Az Atomic Design a UI-komponensek szervezésének módszertana, az FSD — az üzleti rétegek és a teljes alkalmazás szervezésének módszertana. Az Atomic Design arra a kérdésre válaszol, hogy "hogyan osszuk fel a UI-t újrafelhasználható részekre", az FSD — "hogyan szervezzük a kódot az üzleti funkciók köré". Nem versenyeznek: lehet FSD-struktúrája features és entities rétegekkel, és minden rétegen belül használni az Atomic Design-t a UI-komponensek szervezésére.

Tipikus kombináció: az FSD meghatározza az alkalmazás moduláris szerkezetét (rétegek, szeletek), az Atomic Design — a UI-komponensek belső szerkezetét az egyes szeleteken belül. Például a feature.auth szelet molekulákat (LoginForm, PasswordInput) és organizmusokat (AuthPage) tartalmaz, amelyek az Atomic Design szabályai szerint épülnek fel. A shared réteg atomokat (Button, Input, Label) tartalmaz, amelyek minden funkcióban újrafelhasználhatók.

Atomic Design mobilalkalmazásokban: Compose és SwiftUI

A Jetpack Compose és a SwiftUI természetes módon támogatja az Atomic Design hierarchiát a komponenskompozíción keresztül. Atomok a Compose-ban — alapvető @Composable függvények: AppButton, AppTextField, AppCheckbox. Minden függvény testreszabási paramétereket fogad (szín, méret, állapot), és nem tartalmaz üzleti logikát. Az atomok a shared rétegben vannak meghatározva és UI-kitként exportálva.

Molekulák — @Composable függvények, amelyek több atomot kombinálnak: LabeledTextField (címke + beviteli mező + hibaüzenet), ProductCard (kép + név + ár). A molekulák tartalmazhatnak alapvető állapotot (mező érvényessége), de nem férnek hozzá az API-hoz vagy a ViewModel-hez. Különböző organizmusokban használhatók újra.

Organizmusok — @Composable függvények funkció szinten: LoginForm (LabeledTextField e-mailhez + LabeledTextField jelszóhoz + AppButton küldés + helyreállítási link). Az organizmusok Intent függvényeken keresztül dolgoznak a ViewModel-lel, és tartalmazhatnak üzleti logikát. A SwiftUI-ban hasonló hierarchia építhető @ViewBuilder és egyedi View struktúrák segítségével.

A SwiftUI-ban az atom — egyedi View struktúra AppButton, a molekula — beviteli mező címkével HStack-ben, az organizmus — bejelentkezési űrlap. Ez a struktúra lehetővé teszi a komponensek újrafelhasználását minden képernyőn — egy atom módosítása (gomb színe) automatikusan alkalmazódik az összes képernyőre. Az Atomic Design és a tervezési rendszer kombinációja garantálja a felület konzisztenciáját minden képernyő kézi ellenőrzése nélkül.