타입스크립트 이해
타입스크립트는 여러 타입들의 집합이라고 생각하면 된다.
슈퍼타입과 서브타입
Number타입(슈퍼타입) Number Literal Type(서브타입)
Number 타입은 Number Literal Type에 할당 불가능
Number 타입 안에 Number LIteral Type이 있음.
업캐스팅 다운캐스팅
업캐스팅은 서브타입을 슈퍼타입으로 보는 것
다운캐스팅은 슈퍼타입을 서브타입으로 보는 것
다운캐스팅
TypeScript는 런타임 검사 안 함 → 컴파일 단계에서만 통과
잘못된 다운캐스팅도 컴파일은 되지만, 런타임 오류는 발생
타입단언이 필요
기본타입 호환성
unknown: 모든 타입의 슈퍼타입
never : 모든 타입의 서브타입(공집합),어느 타입도 다운캐스팅 불가능
void : undefined의 슈퍼타입
any : 모든 타입의 슈퍼,서브타입 never는 제외
객체타입 호환성
객체타입도 프로퍼티를 기준으로 슈퍼,서브타입을 가짐
대수 타입
합집합 타입(Union)
let a: string | number;
a =1;
a ="hi";
두개의 타입 중 하나의 타입만 다 포함해도 사용이 가능하다.
교집합 타입(intersection)
let nariable : number & string;
두개의 타입 모두 다 포함한 type 만 교집합(intersection)이 된다.
타입 추론
타입스크립트가 초기값을 기준으로 타입을 추론해줌.
함수는 return 값을 기준으로 타입을 추론
매겨변수는 기본값이 있으면 그 값으로 추론하고 매개변수는
타입을 지정해줘야함.
any 타입의 진화
변수의 초기값을 설정하지 않으면 any타입 값을 넣어주면 number,string 등 값으로 진화함. any 타입을 사용 시 이러한 진화 떄문에 혼동이 올 수 있음.
const로 변수 선언 초기화 시 리터럴 타입으로 추론됨.
타입 단언
as 타입을 기준으로 타입추론이 됨.
타입 단언 규칙
값 as 단언(타입) <- 단언식
A as B => A가 B의 슈퍼타입 or A가 B의 서브타입 이어야함.
ex) let num1 = 10 as number;
const 단언
let cat = {
name :"고양이",
color:"red"
} as const readonly가 됨 변경할 수 없게됨!!
Non null 단언
const len:number = post.author?.length
const len:number = post.author!.length
! 해주면 null이 아닐거라고 단언하여 오류가 사라짐
타입 단언은 확실할 때에만 사용해야함 아니면 null 혹은 타입이 다르더라도
컴파일이 되기 떄문에 실제 그 값이 아니면 런타임오류가 발생함.
타입 좁히기
넓은 타입의 타입을 좁은 타입의 타입으로 줄이는 것
ex) 함수로 받아온 매개변수의 값이 string 혹은 number일떄
typeof 연산자와 if문을 이용해 number타입일 경우와 string 타입일 경우를 따로 로직을 작성 매개변수가 union인 경우 타입을 좁히지 않으면 string혹은 number의 메서드가 사용이 안됨!!
타입 가드
- typeof
- instancof
- in
타입 가드를 통해 타입을 좁혀주어 컴파일러가 해당 블록 안에서 안전하게 타입을 추론하고 사용할 수 있게 한다
서로소 유니온 타입
교집합이 없는(서로소) 타입들로만 만든 유니온 타입
사용자가 admin,guset,member 일경우나 api 호출 시 loading,failed,succece일 경우 사용하면 좋다.
태그 프로퍼티를 string 리터럴 타입으로 만들면서 Admin,member,guest를 서로소로 만들어 사용이 가능하다. 여기서 리터럴 타입으로 만들어야 서로소가 가능함.
type AsycnType = {
state : "LOADING" | "FAILED" | "SUCCECED"
error? : {
message: string
}
response? : {
data : string
}
}이렇게 구조를 짜면 조건문에 state별로 나눠 로직을 짜면 error나 reponse에 모든 상태에서 항상 존재한다는 보장이 없기 때문에 타입스크립트는 안전하게 접근하도록 강제 ?(옵셔널 체이닝)이 붙게 된다
이러한 경우를 없애기 위해
type LoadingTask ={
state : "LOADING"
}
type FailedTask = {
state : "FAILED"
error : {
message :string
}
}
type SuccedTask = {
state : "SUCCED"
response : {
data:string
}
}이렇게 하면 서로소 유니온 타입이 되어 state 값에 따라 어떤 속성이 반드시 존재하는지 타입 차원에서 보장이 된다!
