lucas0530 / design-system-for-me

📁 Component Architecture

본 프로젝트의 컴포넌트 아키텍쳐는 CDD(컴포넌트 개발 주도 방법론)을 지향하고 있습니다. 모든 페이지는 컴포넌트의 Atom 단위부터 시작해 Bottom-Up 방식의 구조로 작성되었습니다.

-------> Atom -------> Molecule -------> Organism -------> Page

왜 세 가지로 나누었나요?

• Organisms의 Section 컴포넌트는 스토리북 작성에 용이합니다. Page 컴포넌트에서 기존의 원자 단위의 컴포넌트를 조합해 작성하였다면, 특정 섹션 별로 스토리북에 문서화가 불가능한 문제가 발생합니다.

• 컴포넌트를 단위 별로 나눈다는 의미는 컨텍스트 자원들을 나누어 관리할 수 있다는 의미가 됩니다. 예를 들어 비동기 요청, 연산에 시간이 필요한 데이터가 페이지 컴포넌트에서 한꺼번에 렌더링된다면, UX 상 문제가 발생할 염려가 큽니다. 본 컴포넌트 아키텍쳐의 Layout과 Section 컴포넌트를 함께 사용한다면, Layout을 통해 도메인에 대한 컨텍스트 자원을 한정해 관리할 수 있고, 한정된 자원에서 특정 섹션에 필요한 데이터만 constate를 활용한 훅으로서 가져와 관리할 수 있게 됩니다. 이는, React 18의 Suspense(React-Query를 포함한) 및 Fallback 전략에도 유리합니다.

components
ㄴ Atoms
- 더이상 쪼개질 수 없는 최소단위의 공통 컴포넌트가 이 곳에 위치합니다. 아토믹 디자인 패턴의 Atoms와 유사합니다.
ㄴ Molecules
- 각 도메인에서 재사용 가능한 UI 컴포넌트가 이 곳에 위치합니다. Atoms는 전역에서 재사용이 가능하다면, Molecules에 위치한 컴포넌트는 해당 도메인 내에서만 사용 가능합니다.
ㄴ Organisms
- 하나의 컨텍스트 자원을 공유하는 레이아웃 컴포넌트와 해당 자원을 사용하는 여러 개의 Molecule UI 컴포넌트가 유기적으로 배치된 Section 컴포넌트가 이 곳에 위치합니다.

QnA

Section에서 훅을 사용하는 경우와 Layout에서 훅을 사용하는 경우는 어떠한 차이가 있나요?

Layout은 Section을 이루는 부모 컴포넌트입니다. 따라서 부모 컴포넌트에서 하위 Section들이 사용할 공통 컨텍스트에 대해 자원을 공유 시킬 목적이 있다면, Layout 컴포넌트에서 훅을 선언해 constate를 통해 공유합니다. Section에서 따로 훅을 가져다 쓰는 경우는 동일한 Layout 컴포넌트 레이어에 있는 다른 Section에게 컨텍스트 자원을 공유시킬 목적이 없을 때입니다.

그렇다면 왜 Layout에서 공유 컨텍스트를 만드나요? 기존에 사용하던 다른 방식으로는 해결할 수 없는 과제가 있었나요?

이를 설명드리기 위해서는 제가 Layout-Section 구조로 프로젝트를 수행하기 전 기존에 겪었던 기술 부채에 대해 Trade-Off를 극복한 사례를 설명드려야할 것 같습니다.

과거 Layout 컴포넌트를 사용하지 않고 페이지를 구성한 결과 다음과 같은 문제점이 발생하였습니다.

• 레이어로 나누어져 있지 않아 페이지 내에서 어디에 위치하는 컴포넌트인지 단번에 파악이 어려움
• Section 컴포넌트 없이 구성되다 보니 추상화 레벨을 제한하기 어려워지므로 가독성이 저하됨
• 페이지에서 상태를 처리하다보니 Top-Down 방식의 리액트 컴포넌트 렌더링 전략에 있어 불리함

이러한 기술 부채를 해결하기 위해 Layout-Section 구조를 도입하였으며, 방향성은 다음과 같았습니다.

• 페이지에서 레이어를 다룰 수 있게 Layout 컴포넌트는 Compound 컴포넌트로 작성하도록 합니다.
• 추상화 레벨을 코드에서 제한할 수 있도록 Atomic-design 패턴을 사용하고 문서를 통해 각 단계가 가지는 의미를 제한합니다.
• 경우에 따라 Section 컴포넌트와 Layout 컴포넌트 컨텍스트 내에서 상태를 처리할 수 있도록 하여, 리렌더링되는 범위를 구분합니다.

하지만 모든 것이 완벽하지만은 않습니다. 하기에 대한 부분은 기존의 Atomic-design 패턴의 단점과 동일합니다.

• 코드 상의 규율을 문서로서 제공하므로 개발자가 코드를 작성할 때 어느정도의 학습 비용이 발생할 수 있습니다.
• 컴포넌트가 페이지에 제공되기까지 각 과정이 존재하기 때문에 관리해야하는 파일의 수가 많아질 수 있습니다.

Using RXJS (ReactiveX)

RXJS을 통해 옵저버블 패턴으로 스트림을 구성하도록 처리하였습니다.

옵저버블은 다음과 같은 변수 네이밍을 가집니다. ${변수명}$ - 변수명 끝에 '$' 기호가 붙습니다.