Effective Component (toss slash)

Do Ho Kim·2022년 6월 20일

Toss Slash Effective Component(한재엽님) 세미나를 들으면서 정리한 내용입니다.

개요

제품이 변경되지 않는다는 것은 사용자가 제품을 잘 사용하고 있다는 것이다. 그렇기에 제품이 변경된다는 것은 사용자가 더 제품을 잘 사용하게 하기 위해 변화를 하는 것이다. 우리는 이러한 제품의 변화를 유연하게 대처할 필요가 있다.

우리는 보통 어떻게 제품을 만드는가?

작은 컴포넌트가 큰 컴포넌트가 되고 커지면 "적당히" 분리한다.
우리는 "적당히"에 주목할 필요가 있다.
어떤 기준을 가지고 분리를 하는 것이 컴포넌트 재사용성을 높일 수 있을까?

변경에 유연한 컴포넌트를 만들기 위한 3가지 원칙

Headless 기반의 추상화

변경하는 것과 변하지 않는 것을 추상화한다

보통의 컴포넌트의 구조

데이터 관리 : 외부에서 주입받은 데이터를 관리, 내부 데이터 관리, state
UI : 어떻게 사용자에게 보여줄 지 관리
상호작용 : 사용자와 어떻게 상호작용할 지 관리 (보통의 event)

자세한 내용은 아래 내용을 더 알아보자.

한 가지 역할만 하기

또는 한 가지 역할만 하는 컴포넌트의 조합으로 구성

데이터 추상화

한가지 문제에만 집중해 컴포넌트 로직을 추상화한다.
- 데이터 로직
- UI 로직
- 상호작용 로직
여기서 데이터만 집중(UI와 상호작용 로직 제외)해서 모듈화가 가능한 데 이러한 패턴을 Headless라고 한다.
event관련한 부분도 hook으로 추상화할 수 있다.

예시

isOpen > Dropdown
Trigger > Dropdown.trigger
Menu > Dropdown.Menu / Dropdown.Modal
Item > Dropdown.Item

도메인 분리하기

도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트 분리

컴포넌트의 인터페이스는 일반적일수록 이해하기 쉽다.
예상이 가능한 props의 디자인을 설계해보자.
- 예를 들어 우리는 Button 컴포넌트를 사용할 때 onClick props를 전달해 사용한다.

액션 아이템

인터페이스를 고려해 만들기 (먼저 정의하기)
Divide and Conquer
- 컴포넌트를 실제로 분리하면 복잡도가 낮아지는가?
Don't reinvent the wheel
- 컴포넌트로 분리하면 재사용 가능한 컴포넌트인가?

우리는 이와 같이 복잡도, 재사용 등의 측면에서 꼭 분리를 해야하는 지 고민해볼 필요가 있다.

회고

컴포넌트를 설계하는 좋은 방법론인 것 같다. 지금까지의 나의 기준은 "적당히"에 맞춰져있던 것 같다. 그 점이 너무 공감이 되었고 앞으로의 프로젝트에서 나의 컴포넌트 설계의 하나의 기준이 될 것 같다. 하지만 여전히 복잡도, 재사용 측면에서의 고민은 계속되어야하는 것 같다.