union 타입 확정 - type narrowing, assertion (as)

Type Narrowing

if문과 typeof 키워드나 in, instanceof 등으로 현재 파라미터의 타입을 검사해서 

타입이 number 면 이렇게 해주세요 ~, 타입이 string 이면 이렇게 해주세요 ~ 하는것.

타입이 확실하지 않을 때 생기는 부작용을 막기위한 장치임.

예를들면,

이렇게 그냥 variant 파라미터는 number 또는 string 이라는 union type 이기 때문에 "variant + 1 은 할수 없어요" 라고 에러를 띄워줌

여기에 적절한 narrowing 을 해준다면

"variant 파라미터의 타입이

number 면 variant +1 을 해주시구요,

string 타입이면 variant +1 을 해주세요.

그것도 아니면 그냥 0을 반환해 주세요." 가 됨.

 

이렇게 코딩하는걸 가끔 defensive 하게 코딩한다 라고도 함.

 

Q. 근데 else 문은 굳이 왜 썼나요 ? 

A. if 문 쓸때 마지막에 else문 안쓰면 에러남.

return 하지 않는 조건문이 있으면 나중에 버그가 생길수도 있어서 에러를 내줌.

이게 귀찮으면 tsconfig.js 파일에서 "noImplicitReturns": false 옵션을 달아주면 되는데 

굳이 이 옵션을 건드리는것보다는 엄격하게 써주는게 에러 방지하는데에 더 좋음.

 

 

-- 꼭 typeof 아니더라도 타입을 하나로 확정지을수 있는 코드라면 어떤 것이라도 narrowing 이 될수 있음.

예를들면,

 

 typeof  변수

속성명  in  오브젝트자료

인스턴스  instanceof  부모

 

Type Assertion

narrowing 이 귀찮으면 assertion 하는 방법도 있는데 

예를들면

변수명  as  string 

식으로 짜면 "이 변수의 타입을 string 으로 생각해주세요" 라는 뜻이 됨.

무슨말이냐면

 

이런식으로 짜면 "나 variant 변수 number 라고 주장하니까 그런줄 알아" 라는 뜻.

근데 union type 같은 복잡한 타입에 대해서 하나의 정확한 타입으로 줄이는 역할이지 

string 타입인걸 as number 로 하고 이런 씨알도 안먹히는건 안들어줌.

 

근데 실제 파라미터 값을 입력할때 variant 에 "123" (string 타입) 을 입력하면 숫자처럼 계산해서 124를 뱉어 주는게 아니라 "1231" 이렇게 뱉어줌.

그래서 사실 as 쓰면 에러내기 딱 좋음.

 

그래서 as 문법은 이럴때 잠깐 잠깐 쓰는 문법

1. 왜 타입에러가 나는지 모르겠는 상황에서 임시로 에러해결용으로 사용

2. 내가 어떤 타입이 들어올지 확신을 가지고 잇고 결과값을 보고싶은데 컴파일러가 방해할 때

 

as 문법 말고 narrowing 을 하는게 좋은 관습임. 

 

잠깐 옛날 assertion 문법을 보자면은 

html 태그랑 헷갈릴수 있어서 지금은 그냥 as 씀.