3장. 고급 타입
- 개인적으로 예제 코드가 실제 배민에서 쓰는 코드 + 아직 설명하지 않은 TS 테크닉이 다수 포함된 코드라 이해가 힘들었는데 저만 그랬나요?
4장. 타입 확장하기, 좁히기
4.1.2 유니온 타입
타입스크립트의 타입을 속성의 집합이 아니라 값의 집합이라고 생각해야 유니온 타입이 합집합이라는 개념을 이해할 수 있다- [p.123] 이거 바로 이해 되신 분 있나요?
- 어떤 값이 들어올지는 런타입에 결정이 되므로 실제 들어오는 값은 합집합의 개념으로 모두 받을 수 있지만, 해당 스코프에서 접근이 가능한 속성은 안정성을 위해 교집합의 개념으로 접근이 가능하다 라고 설명하는게 더 맞지 않을까 싶은데... 다들 어떻게 생각하시나요?
4.1.3 교차 타입
다시 말하지만 타입스크립트의 타입을 속성의 집합이 아니라 값의 집합으로 이해해야 한다.
BaedalProgress 교차 타입은 CookingStep이 가진 속성(orderId, time, price)과 DeliveryStep
이 가진 속성(orderId, time, distance)을 모두 만족(교집합)하는 값의 타입(집합)이라고 해석할 수있다.- [p.124] 이거도 바로 이해 되신분? 이쯤 되니 제가 바보인가 하는 생각이 듭니다만... 교집합 하는 값의 집합이라 해석할 수 있다..... 이게 뭔말이야
type IdType = string | number;
type Numeric = number | boolean;
type Universal = IdType & Numeric; // number type 으로 지정 된다
const universalVal: Universal = 1;- 오히려 교차 타입은 속성과 값 전부 합집합이라고 설명을 하고, 위의 케이스의 경우 타입간의 베타성으로 인하여 합집합 개념이 통용되지 않는 특수한 케이스이다 이러는게 설명이 더 이해가 잘 될거 같은데 어찌 생각하시나요?
4.1.4 extends 와 교차 타입
interface DeliveryTip {
tip: number;
}
// ERR, number 에 string 을 할당하려고 하므로 에러 발생
interface Filter extends DeliveryTip {
tip: string;
}
// type 사용하면 교차 타입으로 선언되어 tip 은 never 가 된다
type DeliveryTipType = {
tip: number;
};
type FilterType = DeliveryTip & {
tip: string;
};- [p.127] type 으로 사용할 경우 런타임에 해당 타입이 할당되면 바로 ERR 가 발생할 텐데, 해당 접근법은 올바른 접근일까요?
4.4 Exhaustiveness Checking 으로 정확한 타입 분기 유지하기
type ProductPrice = '10000' | '20000' | '5000';
const getProductName = (productPrice: ProductPrice): string => {
if (productPrice === '10000') return '배민상품권 1만 원';
if (productPrice === '20000') return '배민상품권 2만 원';
// if (productPrice === "5000") return "배민상품권 5천 원";
else {
exhaustiveCheck(productPrice); // Error: Argument of type ‘string’ is not assign able to parameter of type ‘never’
return '배민상품권';
}
};
// 매개변수를 never 로 처리하여, getProductName 에서 early return 으로 처리되지 않아 exhaustiveCheck 가 실행이 되면 Type 에러
const exhaustiveCheck = (param: never) => {
throw new Error('type error!');
};- [p.147] 해당 패턴은 매우 좋네요!
- [p.148] 프로덕트 코드에 삽인하는 어설션과 테스트 코드에 대한 시각도 재미있네요. 다들 어찌 생각하시나요?