- 타입스크립트에서 명명된 타입(named type)을 정의하는 방법은 두가지
- 타입 사용
type TState = { name: string; capital: string; }
- 인터페이스 사용
+) 인터페이스 대신 클래스를 사용할 수 있지만, 클래스는 값으로도 쓰일 수 있는 자바스크립트 런타임 개념interface IState { name: string; capital: string; }
- 대부분의 경우 타입과 인터페이스 모두 사용 가능
- 같은 상황에서는 동일한 방법으로 명명된 타입을 정의해 일관성을 유지해야
- 인터페이스 선언과 타입선언의 비슷한 점
- 명명된 타입은 둘 다 상태에는 차이가 X
- 추가 속성과 함께 할당한다면 동일한 오류가 발생할 것
const wyoming: TState = { name: "wyoming"; capital: "Cheyenne"; population: 500_000; /// 에러 발생 }
- 인덱스 시그니처는 인터페이스와 타입에서 모두 사용 가능
type TDict = { [key: string]: string }; interface IDict { [key: string]: string; }
- 함수 타입도 인터페이스나 타입으로 정의 가능
type TFn = (x: number) => string; interface IFn { (x: number): string; }
- 단순 함수 타입에는 타입 별칭이 더 낫지만, 함수 타입에 추가적인 속성이 있다면 차이 X
- 타입 별칭
// string 타입을 사용할 때 const name: string = 'capt'; // 타입 별칭을 사용할 때 type MyName = string; const name: MyName = 'capt';
- 타입 별칭과 인터페이스 모두 제너릭 가능
type TPair<T> = { first: T; second: T; } interface IPair<T> { first: T; second: T; }
- 인터페이스는 타입을 확장, 타입은 인터페이스를 확장
- 주의할 점은 인터페이스는 유니온 타입 같은 복잡한 타입을 확장하지는 못한다는 것
- 복잡한 타입을 확장하고 싶다면 타입과 &를 사용해야함
interface IStateWithPop extends TState { population: number; } type TtateWithPop = IState & {population: number; };
- 클래스를 구현할 때는 타입과 인터페이스 둘다 가능
- 인터페이스 선언과 타입 선언의 다른 점
- 유니온 타입은 있지만 유니온 인터페이스라는 개념은 X
- 인터페이스는 타입을 확장 할 수 있지만 유니온은 할 수 없음.
type str = "a" |"b"; interface strI extends str { // 이거 오류뜸 ... }
- 아래의 코드와 같은 것은 인터페이스로 표현 불가능
type NamedVariable = (Input | Output) & { name: string };
- type 키워드는 일반적으로 interface보다 쓰임새가 많음. type은 유니온이 될 수 있고 매핑된 파입 또는 조건부 타입 같은 고급 기능에 활용 되기도
- 튜플과 배열 타입도 type키워드로 간결하게 표현 가능
- 튜플
- 튜플 타입을 이용해 원소의 수와 각 원소의 타입이 정확히 지정된 배열의 타입을 정의 할 수 있음
- 튜플 타입 변수는 정호가히 명시된 개수 만큼의 원소만을 가질 수 있다.
- 튜플
- interface도 튜플과 비슷하게 구현할 수 있지만, concat 같은 메서드 사용 불가.
- 튜플과 배열 타입도 type키워드로 간결하게 표현 가능
- 인터페이스에는 타입에 없는 몇 가지 기능이 있음
- 보강이 가능
- 선언 병합: 속성을 확장하는 것
interface IState { name: string; capital: string; } interface IState { population: number; }
- 선언 병합
- 선언 병합은 주로 타입 선언 파일에서 사용
- 타입 선언 파일을 작성할 땐 선언 병합을 지원하기 위해 반드시 인터페이스를 사용해야함.
- 병합은 선언과 마찬가지로 일반적인 코드에서도 지원 → 언제 병합이 가능한지 알아야!
- 타입은 기존 타입에 추가적인 보강이 없는 경우에만 사용해야함
- 결론
- 복잡한 타입 → 타입 별칭
- 간단한 객체 타입 → 일관성과 보강의 관점에서 고려
- 사용하고 있는 것을 우선으로 사용해라
- 향후 보강의 가능성이 있을 경우
- 어떤 API에 대한 타입 선언을 작성해야 한다면 인터페이스를 사용
- 프로젝트 내부적으로 사용되는 타입에 선언 병합이 발생하는 것은 잘못된 설계이므로 이럴 땐 타입을 사용
'책 정리 > 이펙티브 타입스크립트' 카테고리의 다른 글
아이템 41 any의 진화를 이해하기 (0) | 2023.07.26 |
---|---|
아이템 40 함수 안으로 타입 단언문 감추기 (0) | 2023.07.26 |
아이템 26 타입 추론에 문맥이 어떻게 사용되는지 이해하기 (0) | 2023.07.26 |
아이템 25 비동기 코드에는 콜백 대신 async 함수 사용하기 (0) | 2023.07.26 |
아이템 14 타입 연산과 제너릭 사용으로 반복 줄이기 (0) | 2023.07.26 |