[ JS ] 아토믹 컴포넌트 디자인 개발 패턴

# Reference

 

Brunch - 아토믹(Atomic) 컴포넌트 디자인 개발 패턴; 대형 프로젝트를 위한 코드 재사용 최적화 컴포넌트 관리법 by 한상훈

https://brunch.co.kr/@skykamja24/580

아토믹(Atomic) 컴포넌트 디자인 개발 패턴

 

Github - Do-IT-Page 컴포넌트 구성방식 by Coreight98

https://github.com/Coreight98/Do-IT-Page/

GitHub - Coreight98/Do-IT-Page: 아주대학교 개발 중앙동아리 Do-IT 웹 페이지 프로젝트

 

0) 학습개요

 

아대밀맵 프로젝트를 진행하며 불만족했던 부분중 하나가 유지보수하기 어려운 코드구조 였습니다.

정리하기위해 주석기입, 블럭 스타일링 등의 방법을 사용했으나 한눈에 파악하기 어려웠고, 이로 인해 컴포넌트의 재사용률이 저하되었습니다.

최근에 소속된 동아리 내에서 선배님의 코드 스타일링 방법과 컴포넌트 구조에 대한 조언을 받아 Atomic 코드 디자인과 CSS-In-JS에 대한 내용을 알아볼 기회가 생기게 되었고, 이에 대한 학습내용을 정리했습니다.

 

1) 아토믹 디자인 패턴: 정의

 

디자인하는 방법론입니다.

디자인 방법론이기 때문에 코딩에 국한되는 방법론이 아니며, 여러곳에서 사용될 수 있는 디자인 방법론입니다.

 

아토믹 디자인 패턴이란 활용되기 가장 쉬운 요소들을 원자(Atoms)단위로 쪼개고,

그 원자 단위의 요소들을 조합하여 큰 단위들로 확장해 나가는 디자인 패턴입니다.

 

개발에서 적용되는 아토믹 디자인 패턴은 컴포넌트 단위의 원자를 설계 및 개발하고, 이를 바탕으로

분자(Molecules), 유기체(Organisms), 템플릿(Templates)으로 확장한 뒤 이를 통해 페이지를 관리하는 패턴을 의미합니다.

 

1) 아토믹 디자인 패턴: 구성요소

 

1. 원자 (Atoms)

디자인과 기능의 최소 단위입니다.

확장하기 위한 가장 기본 단위이므로 거의 모든 입력에 대하여 포괄적으로 대응할 수 있도록 설계해야 합니다.

 

예시: 서비스 공통버튼, 아이콘 등

 

2. 분자 (Molecules)

원자들을 모으거나 일부 확장한 컴포넌트 입니다.

일반적으로 프로젝트 내에서 반복적으로 사용되는 블럭이나 서비스카드 등의 디자인을 분자단위로 보고 설계합니다.

따라서 원자와 같이 분자 컴포넌트 또한 활용하여 사용할 수 있습니다.

 

원자 컴포넌트와는 달리 분자 컴포넌트 부터는 활용되는 위치가 비교적 한정적으로 제한됩니다.

따라서 입력값이나 데이터는 분자 단위에서 관리하는 것이 유지보수에 좋다고 합니다.

 

예시: 서비스 카드, 리스트블럭 등

 

3. 유기체 (Organisms)

분자나 단일 원자로 사용된 여러 컴포넌트들을 묶은 컴포넌트입니다.

분자들을 모아 관리하는 역할을 주로 담당합니다.

 

예시: 서비스 카드 섹션, 블럭 리스트 등

 

4. 템플릿 (Templates)

유기체를 묶어 페이지 직전 레이아웃을 구성하는 컴포넌트입니다. (다시말해, 이미 위치가 정해진 레이아웃 템플릿을 말합니다.)

데이터가 들어가기 직전의 레이아웃을 담당하며, 페이지의 모든 구조는 템플릿단에서 완성됩니다.

따라서 유기체의 배치 및 설계구조를 전반적으로 볼 수 있습니다.

 

예시: 티스토리 템플릿 디자인

 

5. 페이지 (Pages)

아토믹 디자인 패턴의 마지막 단계로, 템플릿에 이미지와 텍스트, 데이터 등을 제공하는 단계입니다.

이전 템플릿 단계를 통해 이미 완성된 레이아웃 템플릿 컴포넌트를 가져와 정해진 형식에 맞춰 인자로 삽입할 데이터의 정보를 제공합니다.

 

이미지, 텍스트 데이터 등 정적인 데이터의 경우 이 위치에서 대부분 관리하는 것이 좋다고 합니다.

 

 

2) 아토믹 디자인 패턴: 장단점

 

장점

• 컴포넌트의 활용도가 다른 디자인 패턴에 비해향상될 수 있음
• 어플리케이션단과 분리하여 (=어플리케이션을 모두 완성한 상태가 아니더라도) 컴포넌트를 개발 및 테스트가 가능함
  • => 기타 서드파티 도구 등을 통해 테스트 가능
• 통합 개발 시 백엔드 어플리케이션의 로직에 의존적이지 않음
• 설계 변경이 필요할 경우 더 빠르고 유연성있게 빌드 프로세스를 구성/수행할 수 있음
• 일관적인 디자인 패턴 적용이 비교적 쉬움 (완벽히 같은 컴포넌트를 재활용하기 때문)
• CSS 관리가 훨씬 쉽게 가능함 (단, 컴포넌트에 대응되는 CSS만 렌더링되도록 해야 함)

 

단점

• 컴포넌트 간 의존성 및 복잡도가 까다로울 수 있음
  
  • 상위 컴포넌트 사이즈를 결정할 수 없을 경우 css media query의 사용이 어려움
  • 새로운 기능이 원자나 분자단에서 추가될 때 컴포넌트의 파편화 및 복잡도 증가의 위험성 존재
    • => 개별 컴포넌트의 목적성 구분이 모호해짐
• 하위 컴포넌트에서의 오류 발생 시 모든 상위 컴포넌트의 오류로 파생될 가능성이 존재함

 

단점: 해결방법

• 최하단 컴포넌트 (=원자)의 경우 보수적으로 관리
• 이벤트 핸들링 및 데이터 입출력 관리 등은 분자 컴포넌트에서 관리