### **배경** 1. 한 프로젝트 내에서 두 가지 버전의 헤더 컴포넌트 디자인이 요구되는 상황이 발생하였다. 2. 기존 디자인을 자유롭게 변경할 수 없는 상황에서, 완전히 새로운 헤더 컴포넌트를 만드는 것은 **미래의 변경 가능성에 대비**하기 어렵다는 고민이 들었다. 3. 이러한 문제를 해결하기 위해 헤더 컴포넌트를 **합성 컴포넌트로 재설계**하여, 사용처에서 필요에 따라 다양하게 조합하여 사용할 수 있도록 하는 방향으로 변경하기로 하였다. 4. 다양한 타입의 헤더가 존재할 때, **필요한 props만을 선택적으로 받으면서도 인텔리센스를 통해 필수 props를 명확하게 지정함으로써 개발자의 실수를 방지**하고자 하였다. 5. 이 과정에서 **조건부 타입을 도입**하여, 이러한 구조의 컴포넌트를 구현하게 되었다. ### **결과 미리보기** 완벽한 코드라고는 할 수 없겠지만, 적어도 최소한 여러가지 조합을 활용해 디자인 변경에 대처하기는 전보다 쉬워졌다고 생각한다. 메인 레이아웃 내에서 헤더 컴포넌트를 불러오기 위해 조합한 Header 컴포넌트를 props로 전달한다. ```tsx ... } footer > ... ``` 기존에는 MainLayout 내에 Header 가 함께 위치하고 있어서, 두 컴포넌트간의 의존성 분리가 필요한 상황이었다. MainLayout의 children으로 Header 컴포넌트를 전달하고, MainLayout 내에서 포지션을 잡는 것도 가능하긴 하지만, props로 전달하면 더 명시적이고 MainLayout 내에서도 조금 더 간단하게 위치를 잡아줄 수 있을 것 같아 이런 형태로 결정을 내렸다. 아래는 Header 의 `type` 속성에 따라 props 를 지정하고, 이에 따른 인텔리센스가 활성화 된 모습이다. ![조건부타입](https://evalog.s3.ap-northeast-2.amazonaws.com/2024-03-27/image.png) 만약 `type='LOGO'` 라면 아무런 추가 props가 필요하지 않지만, `type='MENU_BTN'` 인 경우, `onClick` 을 전달하도록 인텔리센스가 동작한다. 예전부터 어떨 땐 필요하고, 어떨 땐 필요하지 않은 props 에 대해 위와 같은 기능을 활성화 하고 싶었는데, 이번에 처음 도입한 조건부 타입을 활용해 비교적 어렵지 않게 구현할 수 있었다.(?) ### **의사결정 과정 1. 어떤 형태로 추상화 할 것인가?** 예전에 **디자인 컨셉은 공유하지만 세부 구현 사항이 다른 여러가지 리스트 아이템**에 대해 합성 컴포넌트를 처음 도입한 이후로, 비슷한 상황에서 되도록이면 여러 컴포넌트를 구현하기 보단 합성 컴포넌트로 조합해서 사용하는 것을 선호하게 되었다. 이를 도입하기에 앞서 중요한 것은, 컴포넌트를 호출하는 곳에서 어떤 방식으로 호출을 해야 사용하기 편할지, 코드가 보기 깔끔할지, 이해가 편할지 이런 관점을 고려해야 한다는 점이다. 그래서 아래와 같은 두 가지 방식으로 고민을 하게 되었다. ```tsx // 방식 1

``` 1번 방식은 Logo, Title, MenuButton, BackButton 등 헤더에 필요한 모든 컴포넌트를 다 하위 컴포넌트로 묶고 이를 각각 조합해서 사용하는 방식으로 생각했다. 그런데 이렇게하면 컴포넌트의 중첩이 너무 많아져서 사용할 때 오히려 불편하다는 느낌을 받을 것 같았다. 벌써부터 로고랑 타이틀만 들어가 있는 주제에 길다... 그래서 아래와 같은 방식을 생각해봤다. ```tsx // 방식 2

``` Left, Ceter, Right 와 같은 포지션을 정해두고, 그 하위에 type 을 props로 받아서 렌더링해주는 방식이다. 헤더라는 컴포넌트가 어느정도 정해진 모습 즉, 메뉴 버튼, 타이틀, 뒤로가기 버튼 등 예측 가능한 타입을 가질 수 있다고 생각해 이런 방식을 생각했다. 그래서 아래와 같은 컴포넌트 구현 로직이 탄생했다. ```tsx Header.Left = (props: HeaderProps) => { const { onClick, children, type } = props as HeaderDefaultProps; return (

{type === 'LOGO' && } {children ? ( {children} ) : ( <> )}

); }; ``` 다양한 상황에 대응할 수 있도록 하기 위해 children을 받아오는 경우도 추가해주었고... 공통적으로 사용되는 버튼의 경우 다시 type props를 받아서 조건부로 렌더링 해줄 수 있도록 했다. ### **의사결정 과정 2. type에 따라 다른 props를 받아오고 싶어!** 위와 같이 type을 props로 가져올 때, 특정 type에서만 필요한 props를 가져오도록 인텔리센스를 활성화 시키고 싶었다. 모든 props를 옵셔널로 가져오면 어떤 prop를 전달해야하는지 일일히 들어가서 확인을 한다던지, 그런 과정에서 자잘한 휴먼 에러가 발생할 수도 있을 것 같아서... 방법을 찾다보니 타입스크립트의 기능 중 **`조건부 타입`** 을 발견하게 되어서 적용하게 되었다. 코드로 살펴보면 아래와 같다. ```ts // 각 컴포넌트에서 타입 여부에 따라 받아올 수 있는 옵셔널한 props 들을 해당 타입으로 정의 export interface HeaderDefaultProps extends ComponentDefaultProps { content?: string; onClick?: () => void; } // type의 기본적인 속성들을 정의 export interface BaseHeaderProps extends ComponentDefaultProps { type: 'LOGO' | 'TITLE' | 'MENU_BTN' | 'BACK_BTN'; } // 각 type에 따른 Props 정의 export interface LogoProps extends BaseHeaderProps { type: 'LOGO'; } // 만약 type 이 TITLE 이라는 유니온 타입에 해당한다면, content 라는 추가 props가 필요함 export interface TitleProps extends BaseHeaderProps { type: 'TITLE'; content: string; } export interface MenuBtnProps extends BaseHeaderProps { type: 'MENU_BTN' | 'BACK_BTN'; onClick: () => void; } // 아래 컴포넌트 선언부에서 제네릭으로 BaseHeaderProps의 type 중 한 가지 값을 넘겨 줄 것임 // 그러면 여기서는 T의 값을 확인해서 특정한 type 값이면 어떻나 것을 리턴하여 타입을 선언하겠다고 조건을 걸어준 것! export type HeaderPropsWip = T extends 'LOGO' ? LogoProps : T extends 'TITLE' ? TitleProps : T extends 'MENU_BTN' | 'BACK_BTN' ? MenuBtnProps : never; ``` 그러면 아래와 같이 컴포넌트를 선언할 때 type 을 제네릭으로 넘겨줄 수 있도록 만들어준다. ```ts // 컴포넌트의 Props 타입을 지정, // 제네릭으로 BaseHeaderProps 에 존재하는 type 값 중 하나를 넘길 것임을 알려준다. HeaderWip.Right = ( props: HeaderPropsWip, ) => { const { onClick, content, children } = props as HeaderDefaultProps; return (

{content && content} {children && children}

); }; ``` 이번에 조건부 타입을 적용하면서 extends 가 단순히 상속의 의미가 아니라, 제네릭에서 사용되었을 땐 **`제약조건`**의 의미를 갖는다는 것을 알게 되었다. 위 코드에서는, 들어오는 제네릭 T의 타입을 BaseHeaderProps 에 속하는 `type` 의 타입으로 제한한다는 의미이다! 원래같으면 어떤 값이 들어올지 전혀 알 수 없는 T 이지만 제약조건을 걸어줌으로써 어느정도 강제성을 가질 수 있는 것이다.