팀의 타입스크립트 컨벤션을 공유합니다.
type alias만을 사용한다.
type alias는 최신 타입스크립트 버전에서 interface하는 거의 모든 일을 수행할 수 있다. 실제로 이를 반영해 타입스크립트 공식 문서의 type alias와 interface 비교 섹션도 변경되었다.
과거
인터페이스는 확장에 개방되어 JavaScript 객체의 작동 방식을 보다 밀접하게 매핑하므로 가능한 경우 유형 별칭보다 인터페이스를 사용하는 것이 좋습니다. 반면에 인터페이스로 어떤 모양을 표현할 수 없고 공용체 또는 튜플 유형을 사용해야 하는 경우 일반적으로 유형 별칭을 사용합니다.
최근
대부분의 경우 개인 취향에 따라 선택할 수 있으며 TypeScript는 다른 종류의 선언이 필요한지 여부를 알려줍니다. 휴리스틱을 원하면 유형의 기능을 사용해야 할 때까지 인터페이스를 사용하십시오.
체크메이트 팀은 타입스크립트의 모든 기능을 사용할 정도로 숙련되지 않았기 때문에 한가지 방법에 더 익숙해지기 위해 type alias를 사용하고 있다.
네이밍 컨벤션
Props 타입은 같은 파일 상단에 {컴포넌트이름}Props로 선언한다.
컴포넌트 타이핑
함수 컴포넌트는 명시적으로 인자와 반환타입을 지정한다.
타입스크립트에서 함수의 타입을 지정하는 방법은 두가지로, 첫번째는 인자와 반환 타입을 직접 지정하는 것, 두번째는 함수 리터럴의 좌변에 타입을 지정해 추론하는 문맥적 타이핑이다. 체크메이트는 함수 컴포넌트로 컴포넌트를 정의하고 있다. 이 때 직접 지정과 문맥적 타이핑을 이용할 수 있는데, 리액트가 제공하는 FC(혹은 FunctionComponent) 타입은 문맥적 타이핑으로 함수 컴포넌트를 기술한다. 함수 리터럴의 좌변에 컴포넌트의 타입을 할당하면 타입스크립트는 우변에서 인자와 반환 타입을 추론한다. 예를 들어 왼쪽과 같이 정의된 Foo 컴포넌트의 props는 FC의 제네릭으로 정의된 label 속성을 가지는 타입으로, 반환 타입은 ReactElement<any, any> | null로 추론된다. 이 때의 문제점은 반환타입이 강제된다는 것이다. 특정 컴포넌트의 경우에 반환 타입이 좁혀질 필요가 있다. 예를 들어 컴파운드 패턴을 사용한 컴포넌트의 children으로 특정 형태의 리액트 엘리먼트만 받는 경우에는 FC의 반환타입이 너무 넓어 할당할 수 없다. 다음으로는 인자를 할당하고 반환타입을 명시하지 않는 방법으로 함수 컴포넌트의 반환 타입을 추론하는 경우가 있다. 이때는 어떤 타입을 반환하는지 함수의 본문을 살펴봐야한다.
FC가 제공하는 static properties는 불필요하다.
FC는 displayName, propTypes, defaultProps와 같은 static 속성에 대한 타입 검사와 자동완성을 지원한다. 하지만 런타임 타입 검사가 과연 필요할까라는 궁금증이 생긴다. 타입은 문서로서의 역할도 한다. 타입스크립트와 propTypes를 함께 사용하면 역할이 중복되고 타입을 관리하는 부분이 분산된다. 이 때의 문제점은:
- 휴먼 에러가 발생할 가능성이 커진다.
- 코드 베이스 볼륨이 증가한다.
문서로서의 역할을 제외하면 propTypes가 가지는 장점은 런타임에 타입 검사를 한다는 점인데 타입스크립트가 컴파일 타임에 대부분의 타입 검사를 하여 실질적으로 런타임 타입 검사가 필요한 부분은 DOM, API와 같이 타입이 불확실한 데이터를 참조하는 경우로 한정된다.
그렇다면 런타임 검사가 필요한 경우에는 어떤 방법이 있을까?
zod, superstruct와 같은 schema validation 라이브러리로 컴파일 타임과 런타임 타입 검사를 동시에 관리하기도 한다.
Children
Props의 타입의 속성으로 children을 명시하고, 상황에 따라서 ReactNode와 ReactElement를 병행하여 사용한다.
React.PropsWithChildren을 사용하지 않고 children을 직접 명시하는 이유는 ReactNode와 ReactElement를 사용하여 children의 타입을 좁히기 위함이다. children에 특정한 형태를 전달받는 일반적으로 상황이라면 React.ReactNode를 사용한다.
ReactNode와 ReactElement만 사용하고 JSX.Element를 사용하지 않는 이유?
JSX.Element는 ReactElement<any, any>와 같다. 컴포넌트 추가 혹은 유지보수 시 어떤 타이핑을 할지 고민하는 시간을 줄이기 위해 사용하는 타입의 가짓수를 줄였다.
Event Type
리액트에서 제공하는 EventHandler 타입을 사용한다.
이벤트 핸들러의 경우에는 void를 반환하기 때문에 반환 타입을 좁히거나, 명시적으로 지정할 필요가 없다. 또한 리액트 컴포넌트의 핸들러 프로퍼티들이 모두 리액트가 제공하는 이벤트 핸들러 타입을 이용하고 있기 때문에 같은 타입으로 지정하면 휴먼 에러가 발생할 가능성이 줄어든다. typescript cheatsheet에서는 이 두가지 동일한 방법에 대해 사람들이 의견을 공유하는 PR을 소개하고 있다.
인라인으로 선언하지 않는다.
핸들러 함수를 인라인으로 선언하지 않으면 재사용이 용이하고 네이밍이 가능해져 어떤 일을 하는 핸들러 함수인지 파악이 쉬워진다. (반면 typescript cheatsheet는 인라인으로 선언하는 방법을 추천한다.)
babel vs tsc
다른 라이브러리들과의 조합을 고려한다.
emotion 라이브러리는 babel 플러그인 사용을 권장하고 있다. 대부분의 트러블슈팅 문서에서 babel 플러그인을 사용한다.
이와 관련된 체크메이트 emotion 이슈 트러블 슈팅: https://github.com/woowacourse-teams/2022-moragora/issues/325
babel을 사용하여 빌드 환경마다 다른 파이프라인을 설정한다.
타입스크립트 공식문서는 다음과 같은 휴리스틱을 추천한다.
Is your build output mostly the same as your source input files? Use tsc
Do you need a build pipeline with multiple potential outputs? Use babel for transpiling and tsc for type checking
체크메이트는 스토리북에서 별도의 트랜스파일 환경을 정의하고 있기 때문에 빌드 파이프라인마다 로컬 babelrc 설정 파일을 사용해 각각의 환경마다 다른 설정을 했다.
웹 어플리케이션은 d.ts 파일을 생성하지 않아도 된다.
라이브러리는 빌드 후 다른 프로젝트에서 import 되기 때문에 타입을 지원할 필요가 있어 타입을 완전히 지워버리는 babel은 적합하지 않다. 하지만 체크메이트와 같은 웹 어플리케이션은 빌드 후 코드의 타입을 다른 코드에서 알 필요가 없어 d.ts 파일을 생성할 필요가 없다.