지금까지 개발을 해오며 어떤 식으로 컴포넌트를 작성하는 것이 좋을까를 계속 고민해왔는데, 실은 아직 답을 찾지는 못했다. 중간중간 컴포넌트를 만드는 것과 관련해서 주변 React 개발자 분들께 여쭤보며 그들의 기준을 알아보려도 해봤고, 구글링이나 다른 분들 코드를 많이 살펴보고도 했는데 정답은 없는 것 같다.

이번에 회사에서 디자인 시스템 팀에 들어가게 되면서 다시 한 번 제대로 파봐야겠다는 생각이 들어서 마음 잡고 다시 공부를 해봤다. 컴파운드 컴포넌트 패턴부터, 직접 컴포넌트도 만들며 스토리북도 적용해보았다.

🧩 Good Component ?

지금까지 회사에서나, 집에서 컴포넌트를 만들다보면 불만족 스러운 부분이 꽤 많았는데, 그런 점들을 정리해보면 아래와 같은 것들이었다.

재사용 가능한 컴포넌트를 만들다보니 props 가 비대해지고 조건문이 많아진다.
컴포넌트 내에서 로직이 지나치게 많아진다.
프로젝트 내에서 비슷한 UI가 있는 것 같은데, 어디있는지 잘 알지 못한다.
컴포넌트의 단위가 독립적이지 못하다.

공부를 시작해보자.

🤕 아쉬움만 쌓이게 그냥 둘건가.

더이상은 아쉽기만 해서는 안된다는 생각에 위의 아쉬움들을 해소시킨 컴포넌트 작성을 위해 공부할 것들을 추려봤다.

Data Binding
Design Pattern
- Data 관점에서의 Design Pattern
  - MVC
  - MVVM
  - MVP
  - Flux
- UI 관점에서의 Design Pattern
  - Presentation Component & Container Component
  - Custom Hooks
  - Atomic design
  - Compound Component Pattern
Story Book

Data Binding

Data Binding 이란 화면상에 보여지는 데이터(View) 와 Browser Memory에 있는 데이터(Model)을 묶어서 동기화하는 것을 의미한다. HTML 에서 server 또는 script 에서 받아온 데이터를 화면에 그려준다고 했을 때, 이 값이 변경 된 경우 다시 HTML 에 변경된 값을 맞추어 그려주는 동작을 Data Binding 이라 한다.

양방향 바인딩

Component 에서 단방향 Data Binding 은 Model(JavaScript) 과 View(HTML) 사이에 ViewModel 이 존재해서 하나로 묶여있기 때문에 둘 중 하나라도 변경되면 모두 함께 변경이 일어난다.

Component 사이에서는 부모 컴포넌트에서 자식 컴포넌트로 Props 를 통해 데이터 전달이 가능하며, 자식에서 부모로는 Emit Event 를 통해 데이터가 전달된다.

양방향 Data Binding 은 데이터의 변경을 프레임워크에서 감지하고 있다가, 데이터 변경 시점에 DOM 객체에 렌더링을 해주거나, 페이지 내에서 Model 의 변경을 감지해 JavaScript 실행부에서 변경해준다. 입력 값이나 변경 값에 따라 내용이 바로 바뀌므로 따로 체크를 해줄 필요는 없다.

이 바인딩 방식은, 개발에서 사용되는 코드량을 크게 줄여주고 유지보수나 코드 관리가 쉬워 웹 애플리케이션의 복잡도가 증가할 수록 그 장점이 커진다. 다만 변화에 따라 DOM 객체 전체를 렌더링하거나 데이터를 바꿔주기에 그 성능이 감소되는 단점이 있다.

단방향 바인딩

Component 에서 단방향 Data Binding 은 Model(JavaScript) 에서 View(HTML) 를 향해서만 data 동기화가 일어나는 것을 의미한다. 그렇기 때문에 View 에서 Model 로의 직접적인 data 변경은 불가하다.

Component 사이에서도 Data Binding 은 부모 컴포넌트에서 자식 컴포넌트 방향으로만 데이터가 전달되는 단방향으로 이뤄진다.

단방향 Data Binding 은 사용자의 입력에 따라 데이터를 갱신하고 화면이 업데이트 되어야하기 때문에, 데이터의 변화를 감지하고 화면을 업데이트 하는 코드를 매번 작성해줘야하지만, 데이터 흐름이 단방향이기 때문에 코드 이해가 쉽고 디버깅이 쉽다. 또한 데이터 변화에 따른 성능 저하 없이 DOM 객체의 갱신이 가능한 것도 큰 장점이다.

Data Binding에서의 변화 감지

DOM event (Mouse Click, Keyboard Press, Mouse Move … etc)
Timer 함수 (setTimeout, setInterval)
비동기 통신, Promise

🗄 Data 관점에서의 Design Pattern

1️⃣ MVC , ModelViewController

Model : data 의 모임 (state or store)
View : JSX
Controller : 컴포넌트 내의 로직

View 는 State 를 바탕으로 화면에 그쳐지고, 유저는 View 를 바라보며 상호작용을 한다. 만약 JSX 에 이벤트가 binding 되어있다면 Controller 실행이 되고, state 가 변경되며 JSX의 리렌더링이 일어난다. 즉, Contoller 는 Model 의 데이터를 생성 / 조회 / 수정 / 삭제 (CRUD) 하고 해당하는 Model의 데이터는 View 에반영되어 나타난다.

MVC 패턴은 주로 Server-Side에서 사용되며 주로 사용되는 프레임워크는 아래와 같다.

Spring Framework
Python Django
PHP Laravel
.NEW Framework
Ruby On Rails

React 공식 문서와 벨로퍼트님의 글을 보면 아래와 같이 나와있다. 아래를 보면 느낌이 오듯 React 보다는 SSR(Server Side Rendering) 방식의 웹에 더 적합한듯 하다.

리액트는 자바스크립트 라이브러리로 사용자 인터페이스를 만드는 데 사용합니다. 구조가 MVC, MVW 등인 프레인워크와 달리, 오직 V(View) 만 신경쓰는 라이브러리 입니다.

2️⃣ MVVM , ModelViewViewModel

Model, View : MVC 에서 동일
ViewModel : Controller 에서 조금 더 UI 측면으로 발전한 것으로, Model 에 데이터를 요청하고 가공

MVVM 은 프로그램의 비지니스 로직과, 프레젠테이션 로직을 UI 로 명확하게 분리하는 패턴이다. 데이터를 관리하는 로직과 UI 로직을 깔끔하게 분리했을 때, 애플리케이션을 보다 쉽게 테스트하고 유지보수 할 수 있다.

코드의 재사용성도 크게 개선이 가능하며 개발자와 UI 디자이너가 애플리케이션의 각 부분을 개발할 때 보다 쉽게 협업할 수 있는 디자인 패턴이 된다.

3️⃣ MVP , ModelViewPresenter

React의 Class형 컴포넌트에 주로 사용되는 패턴인 것 같다.

데이터 관리
- Model : data 의 모임 (server를 담당)
- Selection : Model 데이터의 여러 하위 세트를 지정하기 위한 추상화를 함
- Command : Model 의 Selection 에서 수행할 수 있는 작업을 나타내는 추상화를 함
사용자 인터페이스
- View : 데이터를 표시
- Interactor : 이벤트에 따른 데이터의 변경 사항을 요청함
- Presenter : Interactor 에 따른 적절한 Command 를 매핑

Flux

대형 MVC 애플리케이션에서 나타나는 데이터 간의 의존성과 연쇄적인 갱신에서 발생되는 예측하기 힘든 데이터 흐름을 올바르게 다루기 위해 제작된 패턴이다. 기존의 MVC 패턴은 Model 의 데이터를 View 에 반영하고, View의 입력과 변화가 Model 을 변경하는 양방향 데이터 흐름이었지만 Flux 패턴은 단방향 데이터 흐름을 가진다. Flux 패턴에서는 Store 에서 데이터를 가져와 View 를 갱신한다.

Action : 데이터의 상태를 변경할 수 있는 명령어 쪽지와 같은 역할
Dispatcher : Store 를 변경하는 역할
Store : 데이터와 비즈니스 로직을 담당하고 Views가 변경 감시를 할 수 있도록 제공

🖼️ UI 관점에서의 Design Pattern

1️⃣ Presentation Component - Container Component

리액트와 리덕스를 사용하는 프로젝트에서 자주 사용되는 디자인 패턴이다. Dumb 컴포넌트와 Smart 컴포넌트로도 알려져있다.

Container Component
- Presentation Component 들과 Container Component 들을 관리하는 것을 담당한다.
- 주로 내부에 DOM element 가 직접적으로 사용되는 경우는 없다.
  - 사용되는 경우라면 감싸는 용도일 때만 사용된다.
- 스타일을 가지고 있지 않아야 한다.
- 상태를 가지고 있을 때가 많으며, 리덕스에 직접적으로 접근 가능하다. 즉, 데이터 처리를 담당한다.
Presentation Component
- 오직 뷰만을 담당하는, 스타일들을 가지고 있는 컴포넌트이다.
- 상태를 갖고 있지 않으며, 가지고 있다하더라도 데이터와 관련한 것이 아닌 UI 에 관련된 것이어야 한다.

src
  |- components
  |- containers

이 패턴을 사용할 경우 폴더 구조는 주로 위와 같이 구성된다. UI 와 Data 가 분리되어있기 때문에 프로젝트 이해가 쉬우며 컴포넌트의 재사용성도 높아진다. 하지만, 지금은 거의 사용되지 않는 패턴이다. (Custom Hooks가 나왔기 때문!)

2️⃣ Custom hooks

기존 Presentation Component - Container Component의 Container의 로직만 hooks로 관리하는 방법이다. 그러므로 메인 로직이 Container Component가 아닌, Custom Hooks 로 전달되며 사용자가 Hook에 접근해서 메인 로직을 사용하게 된다.

이 패턴의 장점은 Hook은 UI와 로직으로 구분되기 때문에 UI, 로직 모두 재사용하기 유용하다는 점이다. 또한, 여러 내부 로직 (state, handlers) 를 포함해 Component의 제어가 쉬우며, 사용자에게 더 많은 통제권을 준다. 폴더구조는 아래와 같다.

src
  |- components
  |- hooks

하지만 이 패턴도 단점은 있다. 대표적으로 “구현의 복잡성”을 들 수 있는데 로직과 렌더링에 대한 부분이 분리되어 있기 때문에, 사용자가 직접 이 둘 사이를 연결해줘야 한다. 그러므로, 컴포넌트에 대한 올바른 구현을 위해서는 컴포넌트 동작 방식에 대한 깊은 이해가 필요하다.

3️⃣ Atomic Pattern

기존의 Component 조각을 를 조금 더 세부적으로 나누어 사용하는 패턴이다. 화학을 떠올리면 더 이해가 쉬울 것 같다. Atomic 패턴은 UI의 재사용성이 압도적으로 뛰어나 협업 프로젝트에서 빠르게 UI를 개발할 수 있는 방식이다.

Atoms : 가장 작은 단위의 컴포넌트 (button, p, input, … etc)
Molecule : Atom을 여러 개 조합한 컴포넌트
Oraganisms : Molecule과 Atom들을 조합하여 만든 컴포넌트
Templates : Molecule과 Atom들을 조합해 넣을 레이아웃 컴포넌트
Pages : Templates에 Oraganisms, Molecule, Atom들을 조합한 컴포넌트

그러나 이 패턴도 결국은 단점은 있다. 초기에 Atoms 단위의 컴포넌트부터 작성해나가는 시간이 필요하므로 프로젝트의 초기 셋팅 시간이 많이 소요된다.

또한, page 단위에서 state을 props로 내려줘야 되기 때문에 props drilling 이 일어날 수 있으며 디자인이 자주 변경되는 경우이거나 정해진 패턴이 없는 경우라면 조건이 너무 많아져서 오히려 컴포넌트가 무거워지고 비효율적이게 될 수 있다.

공부를 해도 만족스럽지가 않다.

여러가지 디자인 패턴을 공부하다보면 조금 만족스러울만한 답을 얻을 것이라 생각했는데, 실은 아직은 답답한 것이 많다. 몇 달 전까지만 해도 ‘커스텀 훅과 아토믹 패턴을 적절히 잘 사용하면 아주 베스트일 것 같다!’라고 생각을 했었지만 실은 이것도 단점이 많고 특히나 내가 개발하고 있는 지금의 환경에서 아주 적합하기는 힘들다는 생각도 들었기 때문이다.

회사는 아직 안정된 단계가 아니기 때문에 실험적인 디자인을 많이 시도중이시기도 하고, 아직 디자인시스템도 갖춰지지 않았다. 오히려 지금 이렇게 작업을 하는 것이 추후 유지보수에 있어서 독이될 수도 있겠다는 불길한 느낌도 들고..?

하지만 그럼에도 불구하고 이상적인 패턴을 찾아가고 싶다. 더 나은 컴포넌트 구조를 만들어가고 싶고 전반적으로 리팩토링이 필요한 것을 알기 때문에!

🍱 Compound Component Pattern

회사에서 몇 달 전, SUPER SEXY 한 Componet 구조를 만들어보겠다는 생각으로, 팝업 모달에 대한 컴포넌트를 작성한 적이 있다. 작성을 하면서 힘들었던 점은 완전히 통일된 디자인은 없기 때문에, 약간 다른 Oraganisms 들이 존재할 수 밖에 없었던 것이다. 그렇기 때문에 내가 아무리 “잘” 만들었다고 하더라도, 모든 예외 케이스를 잡는 것은 어려웠다.

이런 잔잔바리 예외 케이스를 모두 잡으려면 결국은 props 는 비대해질 것이고, JSX 내에서 수많은 삼항연산자들이 와글와글 거리게 될 것이다… (끔찍) 이런 케이스에 대해 어떻게 해결해나갈 수 있을까 고민을 했고 Compound Component 패턴을 적절하게 사용해 해결해봐야겠다는 생각을 해봤다. (해결이 안되는 케이스라면 굳이 재사용하지 않고 새롭게 컴포넌트를 만드는 것도 방법이 아닐까?)

*사진출처 : https://patterns-dev-kr.github.io/

서론이 길었고.. 쨋든 컴파운드 컴포넌트 패턴이란 하나의 컴포넌트를 구성하는 암시적 상태 공유 컴포넌트 API 집합을 제공하는 방법이며, 유연하고 확장성이 뛰어나다. 이 패턴을 사용하면 props drilling 없이 선언적이고 표현적인 컴포넌트를 만들 수 있다.

장점

Comound Component 패턴의 가장 큰 장점은 “API의 복잡성 감소”이다. 하나의 부모 컴포넌트에 props 를 이용해 하위로 내려보내는 대신, 각각의 props는 가장 적합한 SubComponent 에 연결되도록 구성된다.

또한 UI 가 유연성이 뛰어나므로 하나의 컴포넌트로부터 다양한 케이스 생성이 가능하다. 사용자는 SubComponent 의 순서를 변경하거나 이 중에서 어떤 것을 표시할 지를 정할 수 있게 된다.

“관심사의 분리”적인 부분도 이 패턴의 큰 장점 중 하나이다. 대부분의 로직은 부모 컴포넌트에 포함되며, React.Context 는 모든 자식 컴포넌트의 states 와 handlers 를 공유하는 데 사용이 된다. 그렇기 때문에 책임소재가 명확히 분리가 된다.

단점

UI 가 유연했으면 좋겠는 마음에 만들었지만, 유연성이 너무 높아지는 케이스가 발생할 수 있는 단점이 발생했고 이는 예기치 않은 동작을 유발시킬 수 있게 되었다. 또한 이 패턴을 적용했을 때 JSX 행 수가 증가하여 너무 무거워질 수 있다.

Compound Component 패턴에 대한 설명이나 구현 방법에 대한 내용은 카카오 엔터 기술 블로그를 참고하면 좋을 것 같다. 나는 디자인 패턴을 활용한 컴포넌트 작성은 이어지는 포스팅에서 작성해볼 생각이라, 소스코드를 따로 작성하지는 않겠다.

ETC

이외에도 정말 다양한 패턴들이 있다. 구글링 도중에 정말 좋은 사이트를 찾았는데, 디자인 패턴 뿐만 아니라 렌더링 패턴 등 다양한 것들에 대한 최신 정보가 올라오고 있다고 하니 참고하면 좋을 것 같다.

https://patterns-dev-kr.github.io/

📓 StoryBook

회사 디자인 시스템 팀에 합류하게 되어 스토리북 기본적인 개념을 공부해봤다. 그리고 서비스가 커짐에 따라 문서화가 필요하다는 생각도 많았고, 컴포넌트들에 대한 문서 정리를 스토리북으로도 할 수 있을 것 같아서 꼭 도입을 해보고 싶기도 했다.

이전에 간단하게 프로젝트로 사용하긴 했었는데, 이미 라이브 템플릿이 설정된 채로 사용했던 터라 처음부터 설정하고 들어가는 것은 잘 몰랐기에.. 이번 기회에 공식문서를 보면서 공부해봤다.

💡 StoryBook ?

StoryBook 은 컴포넌트 기반의 View 를 위한 독립적인 UI 개발환경이다. 재사용을 위한 컴포넌트들을 Story 에서 조합해 테스트를 할 수도 있으며, 각각의 컴포넌트에 대한 문서화도 가능하다.

📦 Story 의 주요 format

title : 스토리북 폴더 계층 구조
component : (optional) 스토리를 만들 컴포넌트
args : story 의 props
decorators : story 를 래핑하는 추가 렌더링 기능
parameters : story 에 대한 정적 메타 데이터 정

🖍 Story 만들기

Story 를 만드는 방법은 쉽다. 아래 기본적인 구조만 공식문서가 알려주는대로 잘 따라가면 크게 어렵지 않다. 기본적인 순서를 간단하게 정리하면 아래와 같다.

Story 를 만들 폴더와 Component에 대한 정의
Component 가 가지는 args (props) 에 대한 정의 정리
Default Story 작성 & 각 케이스에 따른 Story 작성
Component test

1. Story 를 만들 폴더와 Component에 대한 정의

// Button.stories.tsx
const meta: Meta<typeof PrimitiveButton> = {
  title: "Material/Button", 
  component: PrimitiveButton,
};

export default meta;

위와 같이, Meta 타입으로 컴포넌트에 대한 정보를 작성하고 default export 를 하면, 스토리북에서 해당 정보를 파싱해 컴포넌트를 생성해준다. 아래 사진을 보면 title 에서 정의한 폴더와 컴포넌트가 생성된 것을 확인할 수 있다.

2. Component 가 가지는 args (props) 에 대한 정의 정리

만들고자하는 컴포넌트의 props 를 정의할 시간이다. args 에는 default Button Story 가 보여줄 값들을 넣고, argTypes 에는 이 컴포넌트가 가질 props 와 그에 대한 설명이나 컨트롤 방법 등에 대해 정의해주면 된다.

type Story = StoryObj<typeof PrimitiveButton>;
export const DefaultStory: Story = {
  args: {
    theme: "primary",
  },
  argTypes: {
    theme: {
      description: "버튼 타입을 정의합니다.",
    },
  },
};

위 코드를 작성해서 Story 를 생성하면 아래와 같은 기본 스토리가 생성되며, argsTypes 에 대해서도 확인 할 수 있다. description 을 잘 작성하면 한 컴포넌트에 대해서 문서화도 쉽게 해줄 수 있다.

3. Default Story 작성 & 각 케이스에 따른 Story 작성

이제 컴포넌트에 대한 기본 셋팅은 마쳤으니 스토리를 만들어보자. 먼저 아래와 같이 기본 args 를 가지는 default Template 를 생성해준다.

/* Story Default Format */
const Template: StoryFn<ButtonProps> = (args) => <PrimitiveButton {...args} />;

그리고 추가적인 케이스를 생성하고 싶다면 아래와 같이 기본 템플릿을 바인딩해서 새로운 스토리들을 만들어주면 된다. 나는 버튼 케이스를 다양하게 생성했었기 때문에, Primary, Link, Ghost 등에 대한 스토리를 만들어봤다.

/* New Types of Story - controlled by bind */
export const Primary = Template.bind({});
Primary.args = {
  theme: "primary",
  color: "black",
    ...
};

export const Link = Template.bind({});
Link.args = {
  theme: "link",
  color: "black",
    ...
};

위와 같이 스토리를 만들어주면, 사이드바에는 새롭게 생성한 스토리들이 추가되며 우측 사진과 같이 각각의 스토리에 대한 결과물들도 확인할 수 있다. 각각의 스토리를 클릭해서 들어가면 더 많은 테스트를 해볼 수도 있다.

4. Component test

Component 와 Story 를 모두 만들었다면 컴포넌트 단위에 대한 테스트를 할 수 있다. UI 적인 부분이나 동작적인 부분 모두에 대해서 테스트가 가능한데, props 에 따른 UI 변화는 Controls 탭에서 조건을 바꿔가며 테스트를 할 수 있다. 물론 위에서 했듯이 각각의 케이스에 따른 스토리를 만들어줘도 괜찮다.

컴포넌트의 동작적인 부분에 대한 테스트는 Actions 탭에 들어가면 클릭이벤트나 mouseover 또는 키보드 이벤트 까지 다양하게 테스트를 해볼 수 있다.

👩🏻‍🌾 StoryBook 찍먹 소감

Component 를 생성하고 테스트하는 과정이 워낙 편해서 당장이라도 도입하고 싶은 마음이 뿜뿜.. 하지만 제대로 쓰지 못할 것이라면 용량 차지만 하고 방치만 될 것이기 때문에 추후 도입을 위해서 제대로 공부하고 골수까지 뽑아먹을 작정하고 대비하고 있어야겠다는 생각이 든다. 이번 스토리북 공부에서는 스토리북이 가지고 있는 기능의 몇퍼센트도 사용하지 않았기 때문에!

Story 에서 작성한 args 에 따라 DOCS 가 자동 생성되며, 각각의 케이스에 따른 테스트도 즉각적으로 가능하다니... 진짜 너무 아름답다…ㅎ긓극… 중복으로 만들어내고 있는 컴포넌트들이 많아서 노션을 만들어야 하나 하고 있었는데 그럴 필요 없쥐..! 그리고 args 들이 한 눈에 보여서 불필요하게 비대해지는 props 의 생성을 경계할 수 있게될 것 같다. 정말 필요한 것들에 대해서만 연구하고 적용할 수 있도록 해봐야지.

연습했던 Source Code

https://github.com/kordobby/with-kevin/tree/main/src/components/true/material/Button

💡 마무리

대충 알고 있던 개념들에 대해 정리하는 시간을 가지면서, 앞으로 어떤 것들을 실험해보고 도입하면 좋을지에 대한 조금의 가이드를 얻은 것 같다. 개인적으로는 Compound Component 패턴을 적용해보고 싶긴한데, 회사 동료들과의 이야기도 필요할 것 같고 전반적으로 빡빡해질 수도 있겠다는 생각이 들어서… 당장의 도입은 어려울 것 같다는 생각도 든다. 나중에 회사에서 새로운 프로젝트 들어갈 때 해보자고 이야기해봐야하나 싶기도 하고…!

디자인 시스템 도입간에 공부할 것들이 더 많은 것 같은데, 우선 많이 쓰이고 있는 antd 나 radix, 부트스트랩 등 라이브러리 구현한 깃헙들 보면서 주로 많이 사용되는 props 들이나 구현 방식에 대해서도 연구를 좀 해봐야겠다. 으으으 바쁜 4월이 되겠구나

개발하면서 부딪히는 문제들은 많고… 그런데 또 이렇게 솔루션 또한 많다. 하지만 어떤 것이 지금 내 상황에 적합한지에 대해서 알기 위해서는 내가 많이 알아야한다고 생각한다. 그래서 개발자들이 공부를 평생 해야하는 것이겠쥐.. 흑흑 늘 더 나은 판단을 할 수 있는 개발자가 되기 위해 게을러지지 말아야겠다. 파이튕!

🎨 React Design Pattern and StoryBook Basic