📄 Item34 ~ 38

Item34. 부정확한 타입보다는 미완성 타입을 사용하기

• 타입 안전성에서 불쾌한 골짜기는 피해야 한다. 타입이 없는 것보다 잘못된 게 더 나쁘다.
  • 불쾌한 골짜기(uncanny valley) : 타입 선언에서 어설프게 완벽을 추구하려다가 오히려 역효과가 발생하는 것
• 정확하게 타입을 모델링할 수 없다면, 부정확하게 모델링하지 말아야 한다. 또한 any와 unknown를 구별해서 사용해야 한다.
• 타입 정보를 구체적으로 만들수록 오류 메시지와 자동 완성 기능에 주의를 기울여야 한다. 정확도뿐만 아니라 개발 경험과도 관련된다.

---

➕ unknown vs any vs never

✔️ unknown

• Typescript의 탑 타입이며, Typescript에 존재하고, 존재할 수 있는 모든 타입들을 포함하여 어떤 값이든 가질 수 있지만, 그로 인해 모든 타입이 공통적으로 할 수 있는 연산 외에는 할 수 있는 것이 없다.
  • 그래서 이 타입 변수는 사용할 때 어떤 타입인지 다시 명시해줘야 한다.
• 또한 이 타입 변수는 타입 검사가 된 후에는 타입을 명시해주지 않아도 된다.
  • 예를 들어 if 조건문에서 엄격한 비교를 통해 통과한 경우 그 안의 실행문에서는 별도의 타입 명시를 하지 않아도 된다.

let value: unknown = 'wow';
value = 123; // unknown 타입은 어떤 타입의 값이든 할당, 재할당 모두 가능

const value2: number = value; // error! (value 변수의 타입이 명확하지 않으므로 number 타입 변수에 할당 불가능)
const value3: number = (value as number); // 사용하려면 이렇게 타입 명시를 해줘야 함

✔️ any

• 타입 검사를 통해 항상 만족하며 어떤 값이든 바로 대입하고 사용할 수 있는 마법과 같은 타입이다.
• 타입 검사를 항상 만족하므로 의도치 않은 형 변환이나 전혀 예상하지 못한 의도되지 않은 타입의 값이 대입되는 등 여러 사이드 이펙트를 일으켜 안전성이 낮아질 수 있으므로 조심해야 한다.

✔️ never

• unknown 타입과 반대로 never 타입은 모든 타입의 하위 타입이다. 그래서 어떤 다른 값도 never 타입에 할당할 수 없다.

// 모두 컴파일 에러 발생
const first: never = 123;
const second: never = 'wow';

• never 타입 사용 예시

// 1) 어떤 값도 반환하지 않은 함수에서의 반환 타입
const showError = (message: string): never => {
  throw new Error(message);
}

// 2) 특정 타입 값을 할당받지 않도록 하는 타입 예시
// 아래 예시는 string 타입인 경우는 never로 추론하여 string 타입의 값이 할당되지 못하도록 할 수 있다.
type NonString<T> = T extends string ? never : T;

📄 Reference

• https://xo.dev/typescript-unknown-any-never/

---

Item35. 데이터가 아닌, API와 명세를 보고 타입 만들기

• 명세를 참고해 타입을 생성하면 타입스크립트는 사용자가 실수를 줄일 수 있게 도와준다.
• 반면에 예시 데이터를 참고해 타입을 생성하면 눈앞에 있는 데이터들만 고려하게 되므로 예기치 않은 곳에서 오류가 발생할 수 있다.

Item36. 해당 분야의 용어로 타입 이름 짓기

• 가독성을 높이고, 추상화 수준을 올리기 위해서 해당 분야의 용어를 사용해야 한다.
• 동일한 의미를 나타낼 때는 같은 용어를 사용해야 한다.
  • 글을 쓸 때나 말을 할 때, 같은 단어를 반복해서 사용하면 지루할 수 있기 때문에 동의어를 사용한다.
  • 동의어를 사용하면 글을 읽을 때는 좋을 수 있지만, 코드에서는 좋지 않다.
  • 정말로 의미적으로 구분이 되어야 하는 경우에만 다른 용어를 사용해야 한다.
• data, info, thing, item, object, entity 같은 모호하고 의미 없는 이름은 피해야 한다.
  • 만약 entity라는 용어가 해당 분야에서 특별한 의미를 가진다면 괜찮다.
  • 그러나 귀찮다고 무심코 의미 없는 이름을 붙여서는 안 된다.
• 이름을 지을 때는 포함된 내용이나 개선 방식이 아니라 데이터 자체가 무엇인지를 고려해야 한다.
  • 예를 들어 INodeList 보다는 Directory가 더 의미있는 이름이다.
  • Directory는 구현의 측면이 아니라 개념적인 측면에서 디렉터리를 생각하게 된다.
  • 좋은 이름은 추상화의 수준을 높이고 의도치 않은 충돌의 위험성을 줄여 준다.

Item37. 공식 명칭에는 상표를 붙이기

• 타입스크립트는 구조적 타이핑을 사용하기 때문에, 값을 세밀하게 구분하지 못하는 경우가 있다.
  • 값을 구분하기 위해 공식 명칭이 필요하다면 상표를 붙이는 것을 고려해야 한다.
• 상표 기법은 타입 시스템에서 동작하지만 런타임에 상표를 검사하는 것과 동일한 효과를 얻을 수 있다.

Item38. any 타입은 가능한 한 좁은 범위에서만 사용하기

(1) 함수에서 any 타입 사용하기

• any를 사용하여 타입 오류를 해결하는 방법은 두 가지가 있다.

function f1() {
  const x: any = expressionReturningFoo(); // Don't!
  processBar(x);
}

function f2() {
  const x = expressionReturningFoo()
  processBar(x as any); // Do!
}

• 위 방법 중 두 번째 방법으로 작성해야 하는 이유는 any 타입이 processBar 함수의 매개변수에서만 사용된 표현식이므로 다른 코드에는 영향을 미치지 않기 때문이다.
• any의 사용 범위를 좁게 제한해야 any 타입이 전혀 연관없는 함수 바깥으로 영향을 미치지 않게 된다.
• 비슷한 관점에서, 타입스크립트가 함수의 반환 타입을 추론할 수 있는 경우에도 함수의 반환 타입을 명시하는 것이 좋다.
  • 함수의 반환 타입을 명시하면 any 타입이 함수 바깥으로 영향이 미치는 것을 방지할 수 있다.

(2) 객체에서 any 타입 사용하기

const config: Config = {
  a: 1,
  b: 2,
  c: {
    key: value,
     // ~~~ 'foo' 속성이 'Foo' 타입에 필요하지만, 'Bar' 타입에는 없습니다.
  }
}

• 객체의 경우에는 config 값 자체를 as any로 선언하여 오류를 제거할 수 있지만 객체 전체를 any로 단언하면 다른 속성들(a와 b) 역시 타입 체크가 되지 않는 부작용이 생긴다.
• 그러므로 아래 코드처럼 최소한의 범위에만 any를 사용하는 것이 좋다.

const config: Config = {
  a: 1,
  b: 2,
  c: {
    key: value as any,
  }
}