Atomic Design — основи, атоми, молекули и организми в UI

Какво е Atomic Design?

Atomic Design — методология за създаване на йерархични интерфейсни системи, в която всеки UI елемент принадлежи към едно от петте нива: атоми (основни елементи), молекули (комбинации от атоми), организми (сложни блокове), шаблони (скелети на страници) и страници (конкретни екрани с данни). Аналогията е заимствана от химията: атомите се свързват в молекули, молекулите — в организми, организмите — в шаблони, шаблоните се запълват със съдържание и стават страници.

Методологията е предложена от уеб дизайнера Брад Фрост през 2013 г. като отговор на проблема със „страничното мислене" — когато всеки нов екран се проектира от нулата, без да се вземат предвид съществуващите компоненти. В книгата „Atomic Design" (2016) Фрост описва внедряването на методологията в проекти на големи компании: IBM, GE, Starbucks. Според Nielsen Norman Group (2022), Atomic Design намалява времето за проектиране на нови екрани с 30–50% благодарение на повторното използване на готови компоненти.

Atomic Design — не е толкова технология, колкото философия за организация на UI. Тя не е обвързана с конкретна рамка и е приложима както в уеб (React, Vue), така и в мобилното разработване (Jetpack Compose, SwiftUI). В IT Sectr използваме Atomic Design за изграждане на дизайн системи на клиенти: идентифицираме атомарни компоненти на етапа на проектиране и ги прехвърляме в кодови компоненти на Compose/SwiftUI.

Пет нива: атоми, молекули, организми, шаблони, страници

Всяко ниво на Atomic Design решава своя задача и има строга област на отговорност. Атоми — най-малките градивни блокове на интерфейса, които не могат да бъдат разделени допълнително без загуба на смисъл: бутон, текстово поле, икона, етикет, квадратче за отметка. Атомите не съдържат бизнес логика и не зависят от контекста. Те определят основните визуални характеристики: цвят, размер, полета, типография.

Молекули — комбинации от два или повече атома, образуващи прости функционални единици. Поле за въвеждане с етикет и съобщение за грешка — молекула. Карта на продукт с изображение, име и цена — молекула. Молекулите могат да съдържат основна логика (показване/скриване на грешка), но не съдържат бизнес процеси. Молекулите са първото ниво, на което компонентите стават многократно използваеми между различни екрани.

Организми — сложни интерфейсни блокове, съставени от молекули и атоми, които реализират конкретна функция на приложението. Формата за вход (поле за имейл, поле за парола, бутон за изпращане, връзка „забравена парола") — организъм. Хедърът с лого, търсене и навигация — организъм. Организмите могат да съдържат бизнес логика и да имат достъп до API, но само в рамките на своята функция.

Шаблони — скелети на страници, които определят разположението на организмите на екрана без конкретно съдържание. Шаблонът задава мрежата, колоните, зоните за съдържание — wireframe на ниво код. Шаблоните не съдържат данни, само placeholder-и. Те позволяват оценка на структурата на страницата преди запълване със съдържание.

Страници — конкретни екрани на приложението, където шаблонът е запълнен с реални данни. На това ниво се проверява как компонентите изглеждат с реално съдържание (дълги редове, липса на данни, грешки). Страниците са единственото ниво, което крайният потребител вижда. Промените на ниво страници не трябва да засягат атомите, молекулите и организмите — ако компонент трябва да бъде променен, промяната се прави на неговото ниво, а страницата я поема автоматично.

Предимства и ограничения на Atomic Design

Предимства на Atomic Design се проявяват при мащабиране на интерфейси. Единната библиотека от компоненти гарантира визуална консистентност: бутонът изглежда еднакво на всички екрани, защото е същият атом. Според Брад Фрост (2016), компаниите, внедрили Atomic Design, намаляват времето за разработка на нови екрани с 30–50% благодарение на повторното използване на готови молекули и организми.

Ограничения — Atomic Design не описва как да се управлява състоянието на приложението. Методологията отговаря само на въпроса „как да организираме UI компонентите", но не засяга бизнес логиката, маршрутизирането, работата с данни. Второ ограничение — трудност при определяне на границите: къде свършва молекулата и къде започва организмът? На практика границите са размити и различни екипи могат да класифицират един и същ компонент различно. Препоръчва се фиксиране на правилата в дизайн токени и каталог с компоненти (Storybook, Jetpack Compose Preview).

Трето ограничение — прекомерна абстракция за малки проекти. Ако приложението се състои от 5 екрана, създаването на йерархия от атоми и молекули е излишна работа. Atomic Design става изгоден, когато броят на екраните надхвърли 20, а компонентите се използват повторно на различни страници.

Atomic Design срещу Feature-Sliced Design

Atomic Design и Feature-Sliced Design (FSD) решават различни задачи и могат да се използват заедно. Atomic Design е методология за организиране на UI компоненти, FSD — методология за организиране на бизнес слоеве и цялото приложение. Atomic Design отговаря на въпроса „как да разделим UI на многократно използваеми части", FSD — „как да организираме кода около бизнес функциите". Те не се конкурират: може да има FSD структура със слоеве features и entities, а във всеки слой да се използва Atomic Design за организиране на UI компоненти.

Типична комбинация: FSD определя модулната структура на приложението (слоеве, филийки), Atomic Design — вътрешната структура на UI компонентите във всяка филийка. Например, филийката feature.auth съдържа молекули (LoginForm, PasswordInput) и организми (AuthPage), сглобени по правилата на Atomic Design. Слоят shared съдържа атоми (Button, Input, Label), многократно използваеми във всички функции.

Atomic Design в мобилни приложения: Compose и SwiftUI

Jetpack Compose и SwiftUI естествено поддържат йерархията на Atomic Design чрез композиция на компоненти. Атоми в Compose — основни @Composable функции: AppButton, AppTextField, AppCheckbox. Всяка функция приема параметри за персонализиране (цвят, размер, състояние) и не съдържа бизнес логика. Атомите се дефинират в слоя shared и се експортират като UI-kit.

Молекули — @Composable функции, комбиниращи няколко атома: LabeledTextField (етикет + поле за въвеждане + съобщение за грешка), ProductCard (изображение + име + цена). Молекулите могат да съдържат основно състояние (валидност на полето), но не осъществяват достъп до API или ViewModel. Те се използват повторно в различни организми.

Организми — @Composable функции на ниво функция: LoginForm (LabeledTextField за имейл + LabeledTextField за парола + AppButton за изпращане + връзка за възстановяване). Организмите работят с ViewModel чрез Intent функции и могат да съдържат бизнес логика. В SwiftUI подобна йерархия се изгражда чрез @ViewBuilder и персонализирани View структури.

В SwiftUI атомът — персонализирана View структура AppButton, молекулата — поле за въвеждане с етикет на HStack, организмът — форма за вход. Такава структура позволява многократно използване на компоненти на всички екрани — промяна на атом (цвят на бутон) автоматично се прилага към всички екрани. Комбинацията на Atomic Design с дизайн система гарантира консистентност на интерфейса без ръчен контрол на всеки екран.