[번역] React Atomic하게 바라보기

Atomic Design, by Brad Frost

 

Brad Frost의 아토믹 디자인 원칙에 익숙하지 않다면 잠시 멈추고 그의 블로그 혹은 그의 책을 읽어보세요. 근사한 디자인 시스템이고 적절히 수행되었을때 여러분 어플리케이션의 화면 구성요소들이 아름답고 간편하게 구성될 수 있습니다.

---

 

아토믹 디자인이 간단하게 말해서 무엇인가요?

아토믹 디자인은 사용자 인터페이스를 더 작고 단순한 요소들로 분리하는 개념입니다. 아토믹 디자인에는 다섯개의 각기 다른 레벨이 존재합니다. atoms, molecules, organism, templates, pages.

하나의 atom은 input 필드 혹은 버튼이 될 수 있습니다. 이러한 atom들은 검색 molecule을 만들기 위해 로고 atom들과 결합되어 질 수 있고 navbar organism을 만들기 위한 네비게이션 molecule을 구성할 수 있습니다.

 

atom, molecule, organism들을 사용하여 page를 위한 template을 구성할 수 있고 디자인 process를 더 빠르게 만들 수 있습니다

---

 

이게 어떻게 React와 잘 맞을 수 있을까?

1년 반정도 React를 빡세게 다뤄왔습니다. 그 당시 나는 아키텍쳐 실수들을 공유해왔고 다른 사람들의 실수를 보면서 배워왔습니다.

React는 KISS(Keep it simple, stupid)를 정말 추구하고 '한 가지 일만 잘하게 해라'와 같은 것들을 배웠습니다.

React 어플리케이션을 architecting할때 아토믹 디자인 패턴을 따르는 이러한 방법론을 따르는 것을 보장합니다.

 

Atom으로서의 단순한 컴포넌트들

컴포넌트들은 가능하면 바보여야 합니다. 어플리케이션의 비즈니스 로직에 대해서는 알지 못해야 하고 그들이 의미하는 것은 단순히 보여주는 것이어야 합니다.

Three distinct atoms, that when combined, can make a search molecule

 

우리가 Button 컴포넌트를 만들고 있다고 해봅시다. Button은 label을 가져야 하고 type, onClick 핸들러도 가져야 할 겁니다.

버튼은 디자인 된대로 보여지게 지게 되고 onClick을 다루게 됩니다.

onClick이 발생했을 때 API 호출을 다루지 않아야 합니다. 그게 이 container의 역할 이빈다.

 

This is what makes it an atom. It’s a small, contained, and simple component of our application.

 

React에서의 Molecules 

TextInput 컴포넌트와 Button 컴포넌트로 검색 모듈을 만들어야 한다고 해보겠습니다. 두개의 컴포넌트들을 결합할때 molecule로서 동작하는 검색 컴포넌트를 만들 수 있습니다. 만약 가능하다면 atom과 같이 molecule에서도 비즈니스 로직에 대해 몰라야 합니다. 버튼 컴포넌트가 눌러졌을때 onSearchClick 핸들러를 가질 수 있지만 TextInput 컴포넌트에 어떤게 입력되었는지에 따라 어떠한 결과라도 fetch하지 않아야 합니다. 이것이 컨테이너의 역할 입니다.

 

Search Molecule

 

Organimsms, Everywhere

Organism은 page들을 그룹핑하기 위해 사용되는 복잡한 Ui 구성요소들과 더 유사합니다. 그들이 molecule과 atom보다 더 복잡하기 때문에 organism들을 비즈니스 로직들을 처리해야 할 수 있습니다.

 

이커머스 웹사이트와 상품 페이지가 있다고 가정해볼게요. Navbar organism과 상품 molecule를 가지고 있는 ProductGrid organism으로 만들어졌습니다. 아래의 Navbar organism을 보시죠

Navbar Organism

 

 

Navbar Organism은 이전에 만든 Search molecule, Navigation molecule, Logo atom으로 만들어졌습니다. 이러한 경우 organism은 비즈니스 로직을 처리할 필요가 없습니다. Organism이 구성될 때 template과 page들에서 비즈니스 로직들을 다룰 수 있도록 만들 수 있습니다

 

컨테이너들은 Template/Page들과 같아야 하나요?

맞습니다. Container는 organism, molecule, atom들을 가지고 있고 복잡한 로직들을 다룹니다. Template과 Page는 또한 organism, molecule, atom들을 가집니다. 작은 컴포넌트 요소들을 결합하면 어플리케이션의 interface를 만들수 있습니다.

 

A template, which can be turned into a page

 

그래서 어느 Atomic 단계에서 비즈니스 로직을 다뤄야 하는데?

organism을 가지게 되면 상황은 조금 더 복잡해 집니다. 위에서 언급한 이커머스 상품 페이지에서 Navbar organism은 비즈니스 로직을 수행할 필요가 없지만 ProductGrid organism은 만약 우리가 paginate를 해야한다면 상품 fetch역할을 요구받게 됩니다. 상품에 대해 구체적인 파라미터들을 추가할 수있고 추가한 파라미터들을 가지고 API호출을 하는 Filter organism도 있을 수 있습니다.

 

사용자 interface를 더 작은 atom, molecule, organism으로 쪼개면 비즈니스 로직을 가지지 않게 할 수 있습니다. Hoc는 atomic 단계에서 필요한 데이터를 내려주고 api 호출들을 다룰 수 있습니다

 

가끔, orgnism, molecule에서 api 혹은 비즈니스 로직에 접근해야 할 수 있습니다. 당연한 일입니다. 하지만 컴포넌트 내부의 코드가 너무나도 복잡해진다면 무엇인가 잘못된 것입니다

---

결론

React 에서 Atomic 디자인을 따르는 것은 본질적으로 개발자들에게 컴포넌트를 단순하고 작게 쪼갤 수 있게 해줍니다.

이러한 단순성으로부터 우리는 더 복잡한 컴포넌트드로가 사용자 인터페이스를 구성하는 컨테이너 컴포넌트들을 만들 수 있습니다.

이러한 패턴을 따르는 것은 React 어플리케이션들을 다루기 쉽게 해줍니디ㅏ.

 

보너스: 파일들을 Atomic Design에 맞게 구성하세요

위의 방법론을 atoms/, molecules/, organisms/, templates/, pages/와 같이 파일을 구성하는데도 사용할 수 있습니다. 

start kit 중 Atomic React 는 좋은 예시입니다. Personally, I like a little bit of a mix of things and have written an article about folder structure in React, but its definitely an option for you 

 

 

 

 

 

출처 : https://medium.com/@wheeler.katia/thinking-about-react-atomically-608c865d2262

Thinking About React, Atomically ⚛