[이펙티브 타입스크립트] 객체 리터럴의 타입 체크 : 타입 호환성과 신선도

책을 이용한 스터디를 하면서 평소에 쓰지 않는 (경험이 아닌 책 내용을 정리하는) 글을 쓰면서 많은 고민을 하게 된다. 어떻게 해야 완벽히 이해하고, 정리하고, 기록할 수 있을까. 책의 순서 그대로 쓰지 않고 내가 이해한 흐름대로 재구성해서 글을 쓰도록 노력해보려고 한다. 효율적인 방법인지는 모르겠지만.

 

---

 

지난주에 공부했던 구조적 타이핑의 관점에서 보면 아래의 코드는 오류가 발생하지 않는다.

interface Room {
    numDoors: number;
    ceilingHeightFt: number;
}

const obj = {
  numDoors: 1,
  ceilingHeightFt: 10;
  elephant: 'present',
}
const r: Room = obj;

추론된 obj의 타입은 Room타입의 부분 집합을 포함하므로, Room에 할당 가능하고 타입 체커도 통한다. 하지만 이러한 구조적 타입 처리는 무언가가 실제 다루는 것보다 더 많은 데이터를 받아들인다는 오해를 불러일으킬 수 있다는 약점이 있다.

 

interface Options {
    title: string;
    darkMode?: boolean;
}

단적인 예로 위의 코드가 있다. string 타입의 title 속성만 제대로 있다면 모든 객체는 Options 타입에 속할 수 있다. 타입의 범위가 매우 넓어지는 것.

 

 

신선도(Freshness)

이를 위해 TypeScipt는 구조적으로 타입 호환성이 있는 객체 리터럴의 타입 검사를 쉽게 할 수 있도록 신선도(Freshness)라는 개념을 제공한다(다른 말로 엄격한 객체 리터럴 검사라 하기도 한다).

 

const r: Room =  {
  numDoors: 1,
  ceilingHeightFt: 10;
  elephant: 'present', //오류!!
}

객체 리터럴일 때만 이런 식의 타입 검사를 수행하고 오류를 내뱉는다. 이펙티브 타입스크립트에서는 '잉여 속성 체크'라고 함.

 

모든 object literal은 초기에 “fresh” 하다고 간주되며, 타입 단언 (type assertion) 을 하거나, 타입 추론에 의해 object literal의 타입이 확장되면 “freshness”가 사라지게 됩니다. 특정한 변수에 object literal을 할당하는 경우 이 2가지 중 한가지가 발생하게 되므로 “freshness”가 사라지게 되며, 함수에 인자로 object literal을 바로 전달하는 경우에는 “fresh”한 상태로 전달됩니다.

https://toss.tech/article/typescript-type-compatibility

 

fresh한 객체 리터럴을 변수에 할당하지 않고 바로 사용한다면, 어차피 해당 함수에서만 사용되고 다른 곳에서 사용되지 않는다. 이 경우에는 유연함에 대한 이점보다는 부작용을 발생시킬 가능성이 놆으므로 굳이 구조적 타이핑을 지원해야 할 이유가 없다.

 

정리하자면, 객체 리터럴을 변수에 할당하거나 함수에 매개변수로 전달할 때 잉여 속성 체크가 수행되는 것. 따라서 타입 호환을 허용하지 않는다.

 

 

비슷한 타입 체크를 지원하는 경우

옵셔널한 속성만 가지는 'weak' 타입도 비슷하게 별도의 체크를 수행한다.

interface LineChartOptions {
    logscale?: boolean;
    invertedYAxis?: boolean;
    areaChart?: boolean;
}

구조적 타이핑 관점에서 LineChartOptions 타입은 모든 속성이 선택적이므로 모든 객체를 포함할 수 있다. 아무거나 넣어도 문제가 없을거라는 이야기이다.

 

const opts = { logScale: true };
const o: LineChartOptions = opts; //오류!!

하지만 위의 코드에선 s 와 S 의 오타는 체커에서 걸러주는게 효과적이다. 이러한 체크는 엄격한 객체 리터럴 체크와 다르게 모든 할당문마다 수행된다. fresh하지 않더라도.

 

객체 리터럴이지만 잉여 속성 체크를 하지 않는 경우

별것도 아닌데 예외가 있다구요.

 

1. 타입 선언이 아닌 타입 단언을 했을 때

interface Options {
    title: string;
    darkMode?: boolean;
}

const o = {darkmode: true, title: 'Ski Free'} as Options //정상

위에서 봤던 예시를 다시 가져왔다. 객체 리터럴을 변수에 바로 할당했기 때문에 잉여 속성 체크를 해야할 것 같지만, 타입 단언문을 사용했을 땐 적용되지 않는다.

 

2. 인덱스 시그니처를 사용했을 때

interface Options {
    darkMode?: boolean;
    [otherOptions: string]: unknown;
}

const o: Options = {darkmode: true}; //정상

인덱스 시그니처를 사용하면 타입스크립트가 추가적인 속성을 예상하도록 할 수 있다.

하지만 웬만하면 쓰지 마셈.

 

---

 

정리하자면 이렇다.

• TypeScipt는 구조적으로 타입 호환성이 있는 객체 리터럴의 타입 검사를 쉽게 할 수 있도록 신선도(Freshness)라는 개념을 제공한다.
• 객체 리터럴을 변수에 할당하거나 함수에 매개변수로 전달할 때 잉여 속성 체크가 수행된다.
• 임시 변수 이용, 인덱스 시그니처 등으로 잉여 속성 체크를 건너뛸 수 있다.