O co chodzi z Atomic Design?

Agata Kucharska
3 min readMar 16, 2017

--

Kilka lat temu, gdy tworzyło się strony internetowe w html’u i css’ach, powtórzenia kodu były naturalne. Obecnie liczba framework’ów js’owych powala, a aplikacje tworzy się modułowo m.in. aby zredukować ilość kodu i łatwiej nim zarządzać. Jednak nadal powielamy te same elementy. Za najprostszy przykład posłużą nam przyciski. Załóżmy, że występują one w wielu miejscach na stronie, a więc wielokrotnie umieszczamy je w kodzie. Przyciski te nie są identyczne, różnią się treścią oraz akcją wywoływaną na kliknięciu.

<button onClick="sth()">Przycisk 1</button>
...
<button onClick="sth2()">Przycisk 2</button>

Nagle jednak pojawia się konieczność wprowadzenia zmian dla wszystkich przycisków na stronie. Wcześniej nie pomyśleliśmy o dodaniu dla każdego z nich klasy styli i musimy to zrobić teraz. W tym momencie nie możemy sobie ułatwić zadania. Po prostu trzeba przekopać się przez cały kod i dla każdego przycisku dokonać te same modyfikacja.

<button style="commonButton" onClick="sth()">Przycisk 1</button>
...
<button style="commonButton" onClick="sth2()">Przycisk 2</button>

Może nam w tym pomóc właśnie atomic design. Jest to metodologia używana do tworzenia interfejsów użytkownika. Na pierwszym miejscu stawia tworzenie komponentów łatwych do ponownego użycia, a nie konkretnych stron. Można powiedzieć, że zmusza nas do patrzenia z punktu widzenia projektanta systemu, a nie jego odbiorcy. Gdy mamy przygotowane poszczególne moduły, łatwo poskładać z nich cały serwis. Zdecydowanie szybciej wprowadza się też zmiany w jednym miejscu, niż w wielu rozsianych po całym kodzie. Co więcej strona zyskuje na spójności, bo nie musimy wciąż od nowa definiować tego samego.

A więc o co chodzi?

Zamiast tworzyć stronę, która wyświetla konkretne elementy (nagłówek, odnośniki, treści), tworzymy zbiór komponentów, które będziemy mogli ponownie użyć.

Jeden z twórców atomic design, Brad Frost, porównał tworzenie aplikacji internatowych, do zasad według których zbudowane jest wszystko w przyrodzie. Zaczynamy od atomów, które są podstawowymi elementami i nie można ich rozbić na mniejsze bez utraty funkcjonalności. Za przykład posłużą przycisk, etykieta i pole formularza (input). Z nich możemy tworzyć bardziej złożone struktury tzn. molekuły. Dla przykładu, z wymienionych wcześniej trzech atomów, można poskładać wyszukiwarkę. Molekuły i atomy łączą się w bardziej skomplikowane struktury tj. organizmy. Jeśli obok wyszukiwarki umieścimy logo oraz nawigację, otrzymamy nagłówek.

W tej hierarchii istnieją jeszcze dwa kolejne obiekty: szablony i strony. Szablony od stron różnią się tym, że wykorzystuje się je wielokrotnie. Często też operują na umownych treściach np. lorem ipsum. Mają zaprezentować wygląd interfejsu bez wdawania się w szczegóły. Strony zaś są finalnymi widokami. To właśnie je zobaczy użytkownik naszej aplikacji. I to właśnie na tym poziomie twórca dowie się jak zachowa się jego aplikacja w różnych okolicznościach np. przy bardzo długim tytule.

Podsumowując:

  • Atomy — podstawowe elementy interface’u użytkownika,
  • Molekuły — kolekcje atomów tworzące proste struktury UI,
  • Organizmy — skomplikowane struktury UI,
  • Szablony — layout’y stron pozbawione konkretnych treści ,
  • Strony — gotowe widoki stron, wypełnione prawdziwymi treściami.

Po co mi to?

Zastanawiacie się po co właściwie zajmować się atomic design? Zacznę od tego, że prawdopodobnie już stosujecie podobne podejście, dzieląc swoje aplikacje na mniejsze części. Wiele framework’ów działa w ten sposób, definiując mniejsze elementy, z których buduje się większe i bardziej skomplikowane. Atomic design pomaga stworzyć wasz własny projekt. Nie narzuca konkretnej struktury elementów, lecz pomaga usystematyzować pracę.

Strona zyskuje na spójności, bo nie musimy za każdym razem definiować wyglądu poszczególnych elementów, gdyż korzystamy z już stworzonych.

Jak to się ma do projektu bloga w react’cie?

W ramach pracy nad blogiem postanowiłam wykorzystywać wskazówki atomowego dizajnu. Dzięki temu poruszanie się po źródłach będzie proste, a lokalizowanie konkretnych elementów intuicyjne.

Zresztą wspominałam o tym w poprzednim wpisie, tutaj tylko naświetliłam dokładniej zasady :)

Do następnego razu!

Projekt robiony w ramach konkursu “Daj Się Poznać”. Aktualny kod źródłowy możecie znaleźć na github’ie.

--

--