<div id="readability-page-1" class="page"><div><h3 id="1-parameters-type-helper">1. parameters type helper</h3>
<img src="https://velog.velcdn.com/images/dongha1992/post/e0d9d2df-682d-4b28-9ff3-9fb34ed16df4/image.png">
위와 서드파티 라이브러리 함수의 인자 타입이 필요하다고 가정하자 (더 복잡한 인자와 타입을 가질 수도 있다)
가장 쉬운 방법으로는 아래처럼 튜플 형식으로 타입을 정의하는 것이다.
<img src="https://velog.velcdn.com/images/dongha1992/post/0c83c29a-1038-431f-87be-aba1cfa87e7c/image.png">
하지만 이렇게 하게 되면 <a href="https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%A7%84%EC%8B%A4_%EA%B3%B5%EA%B8%89%EC%9B%90">SSoT</a> 에 위배되므로 좋은 타입 설계는 아니다. 
위와 같은 상황에서는 <code>Parameters</code>를 사용할 수 있다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/f8803b0f-93af-41ba-81e3-fb94fa0db178/image.png">
정확하게 파라미터 타입을 가져온 것을 확인할 수 있다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/90b4989c-b84e-4b31-89bc-fa357e6ae8a6/image.png">
반환값에 대한 타입은 <code>ReturnType&lt;typeof function&gt;</code>이다
<h3 id="2-annotation-satisfies-operator">2. annotation satisfies Operator</h3>
<img src="https://velog.velcdn.com/images/dongha1992/post/9d45bc49-09d5-4cd3-b2b7-496534453a3f/image.png">
위와 같이 <code>config</code>의 타입을 정의한다고 가정하자. 언뜻보기엔 맞는 거 같지만 타입스크립트는 제대로 작동하지 않는다.
<img src="https://velog.velcdn.com/images/dongha1992/post/37f94a77-e091-4e09-8d07-4a2ac5695e8e/image.png">
<code>Color</code> 타입에 2가지 타입이 존재하기 때문에 정확한 타입을 알기 위해선 타입 가드나 타입 좁히기를 해줘야 한다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/c916b9af-d968-44ec-89bc-81319d0bf0d7/image.png">
<img src="https://velog.velcdn.com/images/dongha1992/post/f4a8af3e-e855-486c-abfc-e540d26b47cf/image.png">
하지만 사실 <code>config</code> 객체엔 타입 정의가 되지 않아도 타입 추론에 의해 제대로 타입이 작동한다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/b1cc1ab5-52b5-4b5d-af24-010624aaafd4/image.png">
<img src="https://velog.velcdn.com/images/dongha1992/post/d0341d2c-3059-4bb9-abe7-13227f5bb647/image.png">
하지만, 타입이 없다면 필수값이 없는 상황에서 제대로된 에러를 뱉지 못하게 된다. (r, g, b는 필수값인 상황)
<img src="https://velog.velcdn.com/images/dongha1992/post/9fd7372e-e10b-431e-baa3-c299620420e8/image.png">
그럴때에 <code>as saftsfies</code>를 사용한다.
<img src="https://velog.velcdn.com/images/dongha1992/post/db66d4b5-5b73-44fd-911a-abaa7280f68d/image.png">
<code>satisfies</code>의 경우, 타입 단언과 검증을 같이 실행한다. <code>config</code> 객체는 여전히 타입 추론을 하고 추론된 타입과 맞는지 검증한다. 그렇기 때문에 만약 객체에서 변경사항이 일어나면 컴파일 타임에 오류를 발생시킨다.
반면 일반적인 명시적 타입은 타입 추론을 비활성화한다. 그렇기 때문에 <code>config</code> 객체의 실제 값이 <code>Color</code> 타입에 맞는지에 대한 추가적인 검증을 수행하지 않는다. 
그렇다면 <code>satisfies</code>를 언제 사용할까? (실무에서 써본 적이 없다)
주로 <code>keyof typeof</code> 패턴에서 사용할 수 있다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/1fdd2a4f-25fa-46ff-b200-4a386a2c0d5f/image.png">
위처럼 <code>keyof typeof</code>를 사용하여 추론한 타입을 사용할 때
<img src="https://velog.velcdn.com/images/dongha1992/post/a5ca9fd5-4453-497f-a27c-9d276cc20ca5/image.png">
명시적으로 타입을 지정해버리면 제대로 된 타입 체킹은 가능하지만 
<img src="https://velog.velcdn.com/images/dongha1992/post/4c7a05bd-5e73-4986-8ceb-0404d3aef0f1/image.png">
<code>keyof typeof</code>의 이점을 잃게 된다. 
이럴 때 <code>satisfies</code> 사용하면 <code>keyof typeof</code>을 그대로 사용하면서도 타입 체킹이 가능하다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/483312c8-7e4d-4eb0-87e8-7e9e43951079/image.png">
<img src="https://velog.velcdn.com/images/dongha1992/post/603c5ec7-c504-45d8-b27c-93a29193053b/image.png">
<h3 id="3-satisfies-as-variable-annotation">3. satisfies, as, variable annotation</h3>
그렇다면 satisfies, as, variable annotation는 각각 어느 상황에서 사용해야 할까
1. satisfies vs as
<img src="https://velog.velcdn.com/images/dongha1992/post/749f41d3-0734-46ae-a27d-4db7d0b10c6e/image.png">
빈 객체를 <code>as</code>로 타입을 지정한 상황이다. 여기서 <code>as</code> 대신 <code>satisfies</code>로 변경하게 되면 undefined 에러가 나온다.
<img src="https://velog.velcdn.com/images/dongha1992/post/c05227c2-e773-42f6-9583-63ed60c4f59b/image.png">
<img src="https://velog.velcdn.com/images/dongha1992/post/ddbb8c06-5d69-4c02-9562-20e3b033c8d6/image.png">
<code>satisfies</code>는 키워드에서 알 수 있듯이 모든 값을 만족해야한다. 값의 실제 타입을 추론하기 때문에 타입을 만족하지 않으면 컴파일 단계에서 에러를 뱉는다.
반대로 <code>as</code>는 기본적으로 타입을 강제하는 경우다. 추가적인 타입 검증이 없기 때문에 추론도 하지 않는다. 컴파일 에러는 없지만, 런타임 에러가 발생할 수도 있다. 
2. satisfies vs variable annotation
<img src="https://velog.velcdn.com/images/dongha1992/post/7334a16b-696e-441d-81d2-d0fc44493d7e/image.png">
위와 같은 상황에서 <code>variable annotation</code>나 <code>as</code>로 타입을 지정하게 되면 타입 체킹에는 문제가 없지만 객체의 키 타입이 <code>string</code>이 되어 버려 이상한 타입 추론을 하게 된다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/5ae59423-9951-4eaa-9164-5321851c97a1/image.png">
<img src="https://velog.velcdn.com/images/dongha1992/post/64c5fec4-f4ee-42c6-ad2f-555a2844f6d3/image.png">
이럴 때 <code>satisfies</code>를 사용할 수 있다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/ebfaeb86-cf9e-44c6-8faa-33961f964cff/image.png">
<img src="https://velog.velcdn.com/images/dongha1992/post/3459b694-2967-45c2-9495-0df302c53710/image.png">
참고: <a href="https://www.totaltypescript.com/">total typescript</a></div></div>

삶도 재입학이 되나요?

1. parameters type helper
위와 서드파티 라이브러리 함수의 인자 타입이 필요하다고 가정하자 (더 복잡한 인자와 타입을 가질 수도 있다)
가장 쉬운 방법으로는 아래처럼 튜플 형식으로 타입을 정의하는 것이다.
하지만 이렇게 하게 되면 SSoT 에 위배되므로 좋은 타입 설계는 아니다. 
위와 같은 상황에서는 Parameters를 사용할 수 있다. 
정확하게 파라미터 타입을 가져온 것을 확인할 수 있다. 
반환값에 대한 타입은 ReturnType<typeof function>이다
2. annotation satisfies Operator
위와 같이 config의 타입을 정의한다고 가정하자. 언뜻보기엔 맞는 거 같지만 타입스크립트는 제대로 작동하지 않는다.
Color 타입에 2가지 타입이 존재하기 때문에 정확한 타입을 알기 위해선 타입 가드나 타입 좁히기를 해줘야 한다. 
하지만 사실 config 객체엔 타입 정의가 되지 않아도 타입 추론에 의해 제대로 타입이 작동한다. 
하지만, 타입이 없다면 필수값이 없는 상황에서 제대로된 에러를 뱉지 못하게 된다. (r, g, b는 필수값인 상황)
그럴때에 as saftsfies를 사용한다.
satisfies의 경우, 타입 단언과 검증을 같이 실행한다. config 객체는 여전히 타입 추론을 하고 추론된 타입과 맞는지 검증한다. 그렇기 때문에 만약 객체에서 변경사항이 일어나면 컴파일 타임에 오류를 발생시킨다.
반면 일반적인 명시적 타입은 타입 추론을 비활성화한다. 그렇기 때문에 config 객체의 실제 값이 Color 타입에 맞는지에 대한 추가적인 검증을 수행하지 않는다. 
그렇다면 satisfies를 언제 사용할까? (실무에서 써본 적이 없다)
주로 keyof typeof 패턴에서 사용할 수 있다. 
위처럼 keyof typeof를 사용하여 추론한 타입을 사용할 때
명시적으로 타입을 지정해버리면 제대로 된 타입 체킹은 가능하지만 
keyof typeof의 이점을 잃게 된다. 
이럴 때 satisfies 사용하면 keyof typeof을 그대로 사용하면서도 타입 체킹이 가능하다. 
3. satisfies, as, variable annotation
그렇다면 satisfies, as, variable annotation는 각각 어느 상황에서 사용해야 할까
1. satisfies vs as
빈 객체를 as로 타입을 지정한 상황이다. 여기서 as 대신 satisfies로 변경하게 되면 undefined 에러가 나온다.
satisfies는 키워드에서 알 수 있듯이 모든 값을 만족해야한다. 값의 실제 타입을 추론하기 때문에 타입을 만족하지 않으면 컴파일 단계에서 에러를 뱉는다.
반대로 as는 기본적으로 타입을 강제하는 경우다. 추가적인 타입 검증이 없기 때문에 추론도 하지 않는다. 컴파일 에러는 없지만, 런타임 에러가 발생할 수도 있다. 
2. satisfies vs variable annotation
위와 같은 상황에서 variable annotation나 as로 타입을 지정하게 되면 타입 체킹에는 문제가 없지만 객체의 키 타입이 string이 되어 버려 이상한 타입 추론을 하게 된다. 
이럴 때 satisfies를 사용할 수 있다. 
참고: total typescript

Total Typescript - deriving types from values & satisfies operator

댓글