누가봐도 넓은 타입은 any와 다를 바 없음!
HTMLelement를htmldivelement로 바꾸기- 타입을 점차 좁혀서 쓰는 것이 TS 실력향상에 도움이 됨
퀴즈1
타입추론될 것을 예측하면서 타입쓰기
무지의 4단계
타입스크립트에서 무지의 4단계
타입추론이 되도록 코드를 작성할 필요가 있음
- 타임추론을 유도한다
- 타입추론이 되지 않으면 타입을 단다
- 에러가 나면 타입을 잘 다는데..
런타임은? 어떻게 해야할까
= 개발자는런타임을 예측하기 힘드니까as를 떡칠하기 시작 ㅠㅠ
타입가드
1.타입스크립트에서만 가능한 문법 알기
typeof 를 왜 넣나? narrowing을 위해서!
타입스크립트는 complie 단계 밖에 개입을 못하기 때문에 런타임 단의 검사를 꼭 넣어줘야함 => type of, if 등의 타입가드 넣기
- if (..in) 의 예
type assertion인 as 는 불안할 수 있음
많이하는 실수 1
-런타임에 터질 수 있는 코드는 타입스크립트가 에러를 띄워줌
타입스크립트에만 있는 is
- 타입가드를 위해서
util타입 만들 수 있음 - 타입가드를 만드는 것은 엄청나게 중요함
- 컴파일과 런타임을 이해하고
타입가드를 안정하게 만들 수 있으면 TS를 어느정도 잘 사용할 수 있게됨 - 타입스크립트를 잘하느냐의 기준은 1. 버그가 없고 안전한 것 =>
안전하게 만드려면런타임은 타입가드를 이용해서 만들기
npm prop type
// prop type vs typescript 차이는?
prop type 은 런타임에 막으려고!
런타임 vs 컴파일
타입스크립트를 썼을 때 안전하게 런타임을 할 수 있는 방법은 뭐냐고 질문이 들어오면?
- 타입스크립트는 런타임에 개입하지 않으므로
타입가드로 잘 방어한다. soundness특성도 있고, 개발자에게 권한을 준다.
unknown 타입
-any 타입과 비슷하지만 error를 발생시킴 타입가드를 유도함
예1
질문 -안티패턴
- 안티패턴일 수도 있지만 어쩔 수 없는 상황도 있음
- redux saga 같은 경우는 typescript 자원 안함
예2 라우팅 타입이 너무 넓은 예 => 타입 좁히기
고쳐주기1
- enum이나 다른 as const 쓸 수 있음
고쳐주기2
- 괴랄하지만 유용한
keyof typeof - 아래가 틀린 이유는?? key 값만 뽑아옴 => value 값을 뽑아와야함 => 다시 고치기
다시고치기3
- 상수(Route) 하나 잘 만들면 무궁무진하게 쓸 수 있음
keyword
non-null assertion operator
soundness -TypeScript는 일부 불건전한 행위를 인정해 준다.- 타입스크립트 컴파일러야 잠시 조용히해 - (개발자 or user를 믿고 인정해줌 ! 같은 경우) => 정말 검증된 상황이 아니면 any를 쓰는 것과 같음
2개가 갈리는 경우 하나 더 있음
기록하기