26P by xguru 26일전 | favorite | 댓글 6개

#1 {집합(Set)}이라고 생각하기
#2 선언된 타입과 좁혀진(narrowed) 타입의 이해
#3 옵셔널 필드 대신에 구분된 유니온 사용
#4 타입 단언을 피하기 위한 타입 명제 사용
#5 유니온 타입 분배 제어
#6 철저한 검사를 통한 컴파일시 처리되지 않은 케이스 체크
#7 interface보다 type을 사용
#8 적절한 상황에는 배열보다는 튜플을 사용
#9 추론된 타입이 일반적이거나 구체적이도록 제어
#10 추가 제네릭 타입 매개 변수를 만들기 위해 infer를 사용
#11 타입 조작으로 창의성을 발휘하여 DRY 상태를 유지
마무리

7번은 React 관점에서 쓴 것 같아 보이네요.
저는 Type보다 Interface를 선호합니다. 다른 언어에도 있는 구문이기도 하구요.

저도요. 예전에 타입스크립트 핸드북에서도 인터페이스를 되도록 우선 사용하라는 조언도 있던걸로 기억합니다.

다 좋은데 7 interface보다 type을 사용 은 굳이? 팁이라고 할수 없네요 표현력이 interface 가 더 좋은게 있어서 예) interface Foo {(b: number): A; (): B}

Type을 옹호하는건 아닌데, 표현력이 더 좋은 예가 잘 이해가 안됩니다. 해당 예문도 Types로 동일하게 표현할 수 있는거 아닌가요?

interface Foo {(b: number): A; (): B}
type Foo = {(b: number): A; (): B}

이펙티브 타입스크립트 책에서 타입과 인터페이스 중에 어느것을 사용해야 할지 정리해둔 부분이 있어 인용해봅니다.

타입과 인터페이스 중 어느것을 사용해야 할지 결론을 내려 보겠습니다. 복잡한 타입이라면 고민할 것도 없이 타입 별칭을 사용하면 됩니다. 그러나 타입과 인터페이스, 두 가지 방법으로 모두 표현할 수 있는 간단한 객체 타입이라면 일관성과 보강의 관점에서 고려해 봐야 합니다. 일관되게 인터페이스를 사용하는 코드베이스에서 작업하고 있다면 인터페이스를 사용하고, 일관되게 타입을 사용 중이라면 타입을 사용하면 됩니다.

아직 스타일이 확립되지 않은 프로젝트라면, 향후에 보강의 가능성이 있을지 생각해 봐야 합니다. 어떤 API에 대한 타입 선언을 작성해야 한다면 인터페이스를 사용하는 게 좋습니다. API가 변경될 때 사용자가 인터페이스를 통해 새로운 필드를 병합할 수 있어 유용하기 때문입니다. 그러나 프로젝트 내부적으로 사용되는 타입에 선언 병합이 발생하는 것은 잘못된 설계입니다. 따라서 이럴 때는 타입을 사용해야 합니다.