
## Contents

# as 키워드 사용이 불가능한 경우

- `in` 연산자와 사용할 경우

  ```tsx
  // 에러: 'in' 연산자 오른쪽에 타입 단언 사용 불가능
  if (('property' in obj) as SomeType) {
  }

  // 올바른 방법
  if ('property' in (obj as SomeType)) {
  }
  ```

- 타입 가드에서의 리턴 값

  ```tsx
  // 에러: 타입 가드의 리턴 값에 'as' 사용 불가능
  function isString(value: any): value is string {
    return typeof value === ('string' as boolean)
  }

  // 올바른 방법
  function isString(value: any): value is string {
    return typeof value === 'string'
  }
  ```

- readonly에 대한 할당

  ```tsx
  type MyObject = {
    readonly myProp: number
  }

  const obj: MyObject = {
    myProp: 5,
  }

  obj.myProp = 10 as any // error
  ```

- 튜플 타입에 대한 길이 제한

  - 튜플은 배열 길이가 고정이므로, `as` 를 사용하여 튜플 길이를 초과하는 할당을 하려는 경우 에러가 발생, 의도인 경우 `as unknown` 체인을 사용한다.

  ```tsx
  let tuple: [number, number] = [1, 2]

  tuple1 = [1, 2, 3] as [number, number]
  /*
  Conversion of type '[number, number, number]' to type '[number, number]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
    Source has 3 element(s) but target allows only 2.(2352)
  */
  ```

# 콜백에서 this에 대한 타입 제공하기

- this는 let이나 const와 달리 ‘호출된’ 방식에 따라 달라지는 다이나믹 스코프이다.
- this 바인딩을 사용하거나, this를 콜백에서 사용할 시에 매개변수에 this를 추가하고, 콜백 함수를 call로 호출한다.

```tsx
function addKeyListener(
  el: HTMLElement,
  fn: (this: HTMLElement, e: KeyboardEvent) => void,
) {
  el.addEventListener('keydown', (e) => {
    fn.call(el, e)
  })
}

// 콜백 함수 매개변수에 this를 추가하면 this 바인딩이 체크되어 실수를 방지할 수 있다.
```

- 또한 라이브러리 사용자의 콜백 함수에서 this를 참조할 수 있고, 안정성이 증가한다.
- 화살표 함수를 콜백으로 작성하고 this를 참조하려고 하면 타입스크립트에서 문제를 잡아낸다.

# 타입스크립트에서 객체 순회

```tsx
const obj = {
  one: 'uno',
  two: 'dos',
  three: 'tres',
}
for (const k in obj) {
  const v = obj[k] // obj에 인덱스 시그니처가 없기 때문에 엘리먼트는 암시적으로 'any' 타입
}

// k의 타입은 string으로 추론되는 반면, obj 객체에는 특정 키만 존재하기 때문에 오류 발생

let k: keyof typeof obj
for (k in obj) {
  const v = obj[k]
}

// k의 타입을 더욱 구체적으로 명시해주어 오류 해결
```

- 왜일까?
  - 특정 객체 타입에는 그 외에 할당 가능한 다른 속성이 존재할 수 있다.
  - 그러므로 타입스크립트는 객체의 키를 string 타입으로 선택하는게 합당하다.
  - 하지만 keyof 키워드로 한정지으면 string | number로 추론되어 적합하지 못하다.
  - `Object.entries` 를 사용하자

```tsx
function foo(abc: ABC) {
  for (const [k, v] of Object.entries(abc)) {
    k // string
    v // any
  }
}
```

- keyof 선언은 상수이거나 추가적인 키 없이 정확한 타입을 원할 경우
- Object.entries는 더욱 일반적으로 쓰이지만, 키와 값의 타입을 다루기 까다롭다.

# 추천 글

[타입스크립트의 Never 타입 완벽 가이드](https://ui.toast.com/posts/ko_20220323)

[올해 버려야 할 타입스크립트 나쁜 버릇 10가지](https://ui.toast.com/weekly-pick/ko_20210217)


이펙티브 타입스크립트 더보기(5-8)


## Contents

# readonly와 as const

> 💡 아래 예시에서 v2의 as const 처리된 x와 v3에서 readonly 처리된 x는 어떤 차이가 있을까?

```tsx
const v1 = {
  x: 1,
  y: 2,
}

const v2 = {
  x: 1 as const,
  y: 2,
}

const v3 = {
  x: 1,
  y: 2,
} as const
```

- v2.x의 값은 `1` 자체로 고정된다.
  ```tsx
  v2.x = 1 // ok
  v2.x = 3 // Type '3' is not assignable to type '1'.
  ```
  ```tsx
  // v2는 아래와 같이 인식된다.
  const v2: {
    x: 1
    y: number
  }
  ```
- v3는 말 그대로 `readonly` 처리된다.
  ```tsx
  v3.x = 1 // Cannot assign to 'x' because it is a read-only property.
  v3.y = 1 // Cannot assign to 'y' because it is a read-only property.
  ```

미묘한 차이가 있다.

# 선택적 속성에 대한 업데이트 사항

책의 설명과 다른 부분이 있다.

```tsx
// 4. 한꺼번에 여러 속성 추가
declare let hasDates: boolean
const nameTitle = { name: 'lee', title: 'hi' }
const pharaoh = {
  ...nameTitle,
  ...(hasDates ? { start: -2589, end: -2566 } : {}),
}
pharaoh.start
// 오류 -> '{name: string; title: string;}' 형식에 'start' 속성이 없습니다.

// pharaoh.start를 사용하고 싶다면 헬퍼 함수 사용
function addOptional<T extends object, U extends object>(
  a: T,
  b: U | null,
): T & Partial<U> {
  return { ...a, ...b }
}

const pharaoh = addOptional(
  nameTitle,
  hasDates ? { start: -2589, end: -2566 } : null,
)
pharaoh.start // 정상, 타입이 number | undefined;
```

위 예시에서 선택적 속성에 대해 union으로 처리되기 때문에 별도의(`addOptional`) 처리가 필요하다고 책에서는 설명한다.

하지만 최근 버전의 타입스크립트에서는 그냥 `number | undefined` 로 추론이 된다. 왜일까?

- 4.0.5
  ![231005-162452](</posts/이펙티브_타입스크립트_더보기(3-4)/231005-162452.png>)

책에서의 설명대로 객체의 유니온으로 추론된다.

- 4.1.5
  ![231005-162504](</posts/이펙티브_타입스크립트_더보기(3-4)/231005-162504.png>)

책에서의 설명과는 달리 바로 optional로 처리된다.

### 공식 문서의 release note의 설명을 살펴보자.

[Documentation - TypeScript 4.1](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html#conditional-spreads-create-optional-properties)

기존 방식은 실제 케이스에 대해서 더 정확하게 모델링하고 있다.

하지만 극단적으로 spread가 중첩되는 경우, 각 중첩에 대해 모든 경우의 수를 계산하는데 드는 비용은 극단적이며 대부분의 경우 그럴만한 가치가 없다.

때문에 typescript 팀은 더 나은 성능과 일반적인 케이스의 더 나은 사용을 위해 optional로 처리하도록 동작을 수정했다고 한다.

# 타입 좁히기

> 💡 filter method로 값을 좁힐 수 없을까?

책에서 언급한 예시에 대해서 살펴보자.

```tsx
const members = ['Janet', 'Michael']
  .map((who) => jackson5.find((n) => n === who))
  .filter((who) => who !== undefined) // 타입이 (string | undefined)[]
```

위 예시에서 타입시스템의 추론을 예상해보자면 `string[]` 라든가, `['Jenet', 'Michael']` 이라든가의 식으로 생각할 수 있지만 결과는 그렇지 않다.

후자는 그렇다 치지만 왜 전자도 걸러내지 못하는 걸까?

- 간단히 보는 결론

![231005-162527](</posts/이펙티브_타입스크립트_더보기(3-4)/231005-162527.png>)

`lib.es5.d.ts` 의 filter 구현이다. filter 메서드는 value 값을 제너릭으로 그 배열을 반환한다.

`find()` 에서는 `string | undefined` 를 반환하고 이 결과로 만들어진 mapping된 함수가 filter에서 처리되므로 생각과는 다르게 `string | undefined[]` 의 결과를 얻게 된다.

### 왜일까?

애초에 filter 메서드에 반환 타입에 대해 구체화하는 절차를 추가하면 되지 않을까?

하지만 filter의 목적을 더 생각해 볼 필요가 있다. 타입스크립트는 자바스크립트의 구현을 바탕으로 타입 추론을 한다.

→ filter 메서드는 boolean 값을 반환하여 필터링을 수행할 뿐, 내부 구현을 확인하여 타입을 확정짓는 과정과는 차이가 있다.

typescript repository에서도 관련 이슈를 꽤 찾아볼 수 있다.

https://github.com/microsoft/TypeScript/issues/16069

- 해결책

```tsx
function isDefined<T>(x: T | undefined): x is T {
  return x !== undefined
}
const members = ['Janet', 'Michael']
  .map((who) => jackson5.find((n) => n === who))
  .filter(isDefined)
```

사용자 정의 타입 가드를 추가해 줄 수 있다.

# 중첩 객체의 타입 좁히기 문제

중첩 객체에서의 태그된 유니온은 타입 좁히기가 동작하지 않는다.

스터디에서 팀원 분이 작성해 주신 아래 예시를 통해 살펴보자.

```tsx
type LoadingState = { status: { label: 'loading' } }
type SuccessState = { status: { label: 'success' }; data: string }
type ErrorState = { status: { label: 'error' }; message: string }

declare let fetchState: LoadingState | SuccessState | ErrorState

switch (fetchState.status.label) {
  case 'loading':
    console.log('로딩중..')
    break
  case 'success':
    console.log('성공! 데이터: ', fetchState.data) //  --- (1)
    break
  case 'error':
    console.error('에러: ', fetchState.message) //  --- (2)
    break
}
```

예상대로라면 각 (1), (2)의 추론이 `SuccessState` , `ErrorState` 로 추론될 것 같다.

하지만 `LoadingState | SuccessState | ErrorState` 로 모두 의도와는 다르게 타입 좁히기가 되지 않는다. data와 message를 보장하지 못하고 에러를 표시한다.

### 왜일까?

현재 타입스크립트 시스템은 정적인 분석을 시행하고 있고, 위 예시에서 사용하려 하는 ‘nested discriminated unions’의 개념을 이해하지 못한다.

현 시스템은 직접적인 관계의 프로퍼티에 대해서만 tag로써 유효하다.

관련한 제안이 있지만 크게 진행되고 있지 않은 듯 하다.

https://github.com/microsoft/TypeScript/issues/18758

- 해결책 중 한 가지는 사용자 정의 타입 가드를 활용하는 것이다.

```tsx
function isLoadingState(state: {
  status: { label: string }
}): state is LoadingState {
  return state.status.label === 'loading'
}
```

# 더 구체적인 타입 사용하기

아래 예시를 보자.

```tsx
// 기본 구현
function pluck(records, key) {
  return records.map((r) => r[key])
}

// 타입 정의
function pluck(records: any[], key: string): any[] {
  return records.map((r) => r[key])
}
```

- any 타입으로 처리해 정밀하지 못하다. 특히 반환값에서의 any는 주의할 필요가 있다.

```tsx
function pluck<T>(records: T[], key: keyof T) {
  return records.map((r) => r[key])
}
```

- `T[keyof T][]` 의 반환값을 추론한다.
- 문제가 있다.
  - `keyof T` 는 모든 T[]의 key 값이기 때문에 records의 아이템의 모든 타입들의 유니온으로 추론된다.

```tsx
function pluck<T, K extends keyof T>(records: T[], key: K): T[K][] {
  return records.map((r) => r[key])
}
```

- 위와 같이 K를 T의 특정 key로 제한한다.
- 해당하는 key의 value의 타입으로 추론이 제한된다.

# 상표 기법 활용하기

런타임에서 체크하기 쉽지만, 타입에서는 체크하기 어려운 부분에 대해 상표를 임시로 붙여줄 수 있다.

```tsx
interface Vector2D {
  x: number
  y: number
}
function calculateNorm(p: Vector2D) {
  return Math.sqrt(p.x * p.x + p.y * p.y)
}

const vec3D = { x: 3, y: 4, z: 5 }
calculateNorm(vec3D) // 결과가 나오나, 의도치 않음

interface Vector2D {
  _brand: '2d'
  x: number
  y: number
}
function vec2D(x: number, y: number): Vector2D {
  return { x, y, _brand: '2d' }
}
function calculateNorm(p: Vector2D) {
  return Math.sqrt(p.x * p.x + p.y * p.y)
}

const vec3D = { x: 3, y: 4, z: 5 }
calculateNorm(vec3D) // '_brand' 속성이 ... 형식에 없습니다.
```

- number 타입에도 상표를 붙일 수 있다.

```tsx
type Meters = number & { _brand: 'meters' }
type Seconds = number & { _brand: 'seconds' }

const meters = (m: number) => m as Meters
const seconds = (s: number) => s as Seconds

const oneKm = meters(1000) // 타입이 Meters
const onMin = seconds(60) // 타입이 Seconds
```

- number 타입에 상표를 붙여도 산술 연산 이후에는 상표가 없어지기 때문에 주의하자.
- 코드에 여러 단위가 혼합된 많은 수의 숫자가 들어 있는 경우, 숫자의 단위를 문서화하는 괜찮은 방법일 수 있다.

> 💡 string 타입에서도 메서드를 사용하면 상표가 없어지나?

그렇다. 아래 예시를 통해 간단히 확인할 수 있다.

```tsx
type a = string & { _brand: 'a' }

const cc = (s: string) => s as a

const neww = cc('hi') // -> a

const b = neww.slice(1) // -> string
```

# 도움 주신 분들

[타입스크립트스터디](https://github.com/prgrms-web-devcourse/FEDC4-TypeScript-Kkobugi-Study) 팀원 분들!!


이펙티브 타입스크립트 더보기(3-4)


## Contents

_이펙티브 타입스크립트 도서의 1, 2 장 중 혼동이 있을만한 내용에 대해 다룹니다._

# 타입스크립트의 목적

1장은 타입스크립트의 목적이나, 개념적인 위치에 대해 설명하고 있다.

이 책은 초반 장이 중요하면서도 모호하게 다가오기 때문에 초반 장을 중요하게 봐야 한다.

타입스크립트 개발의 의도에 공감하는 식으로 접근하면 편했다.

> **“타입스크립트는 자바스크립트의 상위 집합(superset)이다”**

- 자바스크립트가 타입스크립트를 포함하는 것이 아니라 타입스크립트가 자바스크립트를 포함한다.
  - → 모든 자바스크립트 프로그램은 타입스크립트 프로그램으로써 작용할 수 있지만, 반대는 성립하지 않는다.

> 💡 the intent is to catch legitimate bugs in our programs.

- 타입스크립트의 목적은 코드의 설계가 런타임에서 문제를 일으킬 수 있는 경우를 최대한 방지하는 목적이지, 런타임에서의 타입을 강제하거나 확인하는 데에 있지 않다.
  - → 개인적으로 이후에 나오는 각종 케이스들을 보면 타입스크립트는 프로그램의 타입 안정성을 보장하기 위한 각종 편의와 예외를 제공한다. strict하게 무조건적인 규칙을 검사하는 것이 아닌, 실제 나타날 수 있는 위험을 줄이는 장치를 담고 있다는 인상을 받았다.
- 즉 타입 체크를 통과하더라도 여전히 런타임에 오류가 발생할 수 있다. 그리고 런타임 오류 방지를 애초에 보장하지 않는다.
  - → 간단한 예로, 타입을 ‘apple’로 한정했는데, api로 받은 결과가 이와 다른 경우를 생각해보자. 타입스크립트에서 커버해 줄 수 없는 부분이다.

# 타입스크립트 컴파일러의 역할

> **타입스크립트 컴파일러는 두 가지 역할을 수행합니다.**

- 최신 타입스크립트/자바스크립트를 브라우저에서 동작할 수 있도록 구버전의 자바스크립트로 트랜스파일한다.
- 코드의 타입 오류를 체크한다.

→ 이 두 가지 역할은 서로 완벽히 독립적이다.

> 💡 tsc 트랜스파일링 하면 babel은 필요 없나요?

- babel은 여러 기능을 제공하지만 주요 기능은 polyfill이다.
- tsc의 target 설정으로 이를 처리할 수 있다.

- babel의 `@babel/preset-typescript` 를 사용하면 ts를 js로 트랜스파일링하면서 타입 구문을 제거한다. 그러면 타입스크립트 사용의 이점이 줄어든다.
- babel의 이점은 단순 js 버전 호환에만 있지 않다. browerlist 등을 통해 세분화된 커스터마이징이나 플러그인을 통해 특정 라이브러리에 대한 호환성을 제공해 줄 수 있다.
- 그래서 이 둘을 사용할 경우 babel을 통해 트랜스파일링 하고, tsc를 함께 사용해 타입 체킹을 해 주는 것이 좋다.
- vite 등 최신 빌드 툴 등에서는 이런 트랜스파일링과 타입 체크를 적절히 자동으로 체크해준다.

→ 타입스크립트는 ‘런타임’ 오버헤드가 없는 대신, ‘빌드타임’ 오버헤드는 존재한다.

# 구조적 타이핑과 잉여 속성 체크 그리고 타입 추론 이해하기

## 구조적 타이핑

> **자바스크립트는 본질적으로 덕 타이핑(duck typing) 기반입니다.**

- 타입스크립트 또한 이를 그대로 모델링한다.
- 호환되는 구조에 대해 타입 에러 없이 사용이 된다.

> 💡 타입스크립트의 타입 시스템은 기본적으로 ‘열려(open)’있기 때문입니다.

- `a, b`를 요구하는 함수에 대해서 `a, b, c, d` 가 들어있는 데이터를 넘기든, `a, b, x` 가 들어있는 데이터를 넘기든 문제로 인식할 수 없다.

```tsx
// 봉인된, 닫혀있는 타입 시스템을 생각하고 만든 코드
function calculate(v: {x: number, y:number}): number{
  let sum = 0
	for(const key of Object.keys(v)){
		sum += v[key]
	}
    return sum
}

-> error
// 'string' 타입이 v에 입력될 수 있다는 에러가 나온다.
// Object.keys()는 결과값으로 string[]을 제공한다. key는 keyof v가 아닌 string으로 추론된다.

// 단순히 에러를 처리해 준 코드
function calculate(v: { [x: string]: number; y: number }): number {
  let sum = 0
  for (const key of Object.keys(v)) {
    sum += v[key]
  }

  return sum
}

-> no error but not good
// 'string' 인덱스 시그니처를 추가해주어 x, y 외에 속성이 string 키의 number 값일 것임을 이해시킨다.
// 하지만 설계 의도(x와 y만 사용하는 목적)과는 다른 결과를 불러올 수 있다.

// 열려있는 타입 시스템에 의도를 명확히는 코드
function calculate(v: {x: number, y:number}): number{
    let sum = 0
    sum += v.x + v.y

    return sum
}

-> good
// 명확히 사용할 내용을 나타내주어 타입에서나 런타임에서나 문제 소지를 줄일 수 있다.
```

## 타입이 값들의 집합이라고 생각하기

> **’할당 가능한 값들의 집합’이 타입이라고 생각하면 됩니다.**

- 이 집합은 타입의 ‘범위’라고 부르기도 한다.
- 유닛(unit) 타입이라고도 불리는 리터럴(literal) 타입은 한 가지 값만 포함하는 타입이다.
- 유니온 타입은 값 집합들의 합집합을 일컫는다.

> **집합의 관점에서, 타입 체커의 주요 역할은 하나의 집합이 다른 집합의 부분 집합인지 검사하는 것이라고 볼 수 있습니다.**

- 할당 가능한’이라는 문구는 집합의 관점에서, ‘~의 원소(값과 타입의 관계)’ 또는 ‘~의 부분 집합(두 타입의 관계)’를 의미한다.
- & 연산자는 두 타입의 인터섹션(intersection, 교집합)을 계산한다.

다들 이해하기 힘들어했던 부분이다. 차근차근 아래 내용을 살펴보자.

```tsx
interface Person {
  name: string
}

interface Lifespan {
  birth: Date
  death?: Date
}
```

위와 같은 두 인터페이스가 있다.

```tsx
type PersonSpan = Person & Lifespan // -> ?
```

- 타입 연산자는 인터페이스의 속성이 아닌 값의 집합(타입의 범위)에 적용된다.
- 추가적인 속성을 가지는 값도 여전히 그 타입에 속하게 된다.

즉 선택적 속성 외 모든 타입이 필요하다.

→ Person 범위와 Lifespan 범위에 모두 속하는 값의 타입이 된다.

```tsx
type K = keyof (Person | Lifespan) // -> ?
```

`'name' | 'birth'` 아닌가요? 많이 했던 부분이다. 차근차근 뜯어보자.

잠시 다른 예를 살펴보자. microsoft의 typescript 깃허브의 이슈로 올라온 내용이다(https://github.com/microsoft/TypeScript/issues/12815).

```tsx
type A = { a: string }
type B = { b: string }
type AorB = A | B

declare const AorB: AorB

if (AorB.a) {
  // use AorB.a
}
```

위 AorB.a의 사용에서 타입스크립트는 에러를 나타낸다.

(속성 a가 AorB 유형에 존재하지 않습니다…)

왤까? 왜냐하면 AorB에서는 a가 string임을 보장할 수 없기 때문이다. 타입스크립트는 구조적 타이핑을 사용하기 때문에, B와 유니온 된 속성 a는 어떤 값이든 될 수 있다.

타입스크립트는 임의의 속성인 현재 상태에 a를 정할 수 없다. 그러므로 하나의 해결책으로 아래와 같이 a를 알려준다.

```tsx
type A = { a: string }
type B = { b: string; a: undefined }
type AorB = A | B

declare const AorB: AorB

if (AorB.a) {
  // Ok, a는 string|undefined
}
```

(사실 in 키워드를 사용해 AorB가 type A임을 알려주어도 된다. 다만 이 예시를 통해 설명하고자 하는 내용을 위해 위 예시를 작성했다)

다시 원래 내용을 살펴보자.

```tsx
Person | Lifespan -> {name: string} | {birth: Date}
```

→ `{name: string; birth: string} | {birth: Date; name: Date}` 가 되도 문제가 없다.

이 때 `keyof(Person | Lifespan)` 은 왜 `never(공집합)`으로 추론될까?

타입스크립트에서는 이 결과를 사용할 때 type-safe를 보장해야 한다.

즉 `keyof T` 인 `k` 가 `T[k]` 로 사용됐을 때 안전한 작업을 보장한다.

```tsx
interface Person {
  name: string
}

interface Lifespan {
  birth: Date
  death?: Date
}

type PersonSpan = Person | Lifespan

const person1: PersonSpan = {
  // ...
}

person1['name'] // -> ?
```

위 예시에 대해서 `person1['name']` 에 대해서 타입스크립트는 뭐라고 추론해야할까?

이전까지의 설명 내용을 통해 위 추측이 implicit한 any로 밖에 될 수 없다는 것을 알 수 있다. 그러므로 `keyof PersonSpan` 으로 생각할 수 있는 ‘name’은 특정한 타입의 값을 보장해 줄 수 없다(무엇이든 될 수 있기 때문에).

다시 돌아와서, 아래와 같이 Person과 Lifespan의 union의 key는 공집합으로 추론될 수 밖에 없음을 이해할 수 있다.

```tsx
keyof(Person | Lifespan) // -> never
```

## 잉여 속성 체크

구조적 타이핑과 잉여 속성 체크를 연속으로 접하고는 많은 혼동이 있었다. 이에 대해 알아보자.

> **구조적 타입 시스템에서 발생할 수 있는 중요한 종류의 오류를 잡을 수 있도록 ‘잉여 속성 체크’라는 과정이 수행됩니다.**

- 타입이 명시된 변수에 객체 리터럴을 할당할 때 타입스크립트는 해당 타입의 속성이 있는지, 그리고 ‘그 외의 속성은 없는지’ 확인한다.

```tsx
interface A {
	one: number;
	two: number;
}
const a: A = {
	one: 1,
	two: 2
	three: '3' // 개체 리터럴은 알려진 속성만 지정할 수 있으며 'A' 형식'three'가 없습니다.
}
```

- 구조적 타이핑 관점에서 보면 오류가 없어야한다.

> **잉여 속성 체크가 할당 가능 검사와는 별도의 과정이라는 것을 알아야 합니다.**

- 타입스크립트는 단순히 런타임에 예외를 던지는 코드에 오류를 표시하는 것 뿐만 아니라, 의도와 다르게 작성된 코드까지 찾으려고 한다.

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

function createWindow(options: Options) {
	...
}

createWindow({
	title: 'hi',
	darkmode: true // 개체 리터럴은 알려진 속성만 지정할 수 있지만 'Options' 형식에 'darkmode'이(가) 없습니다.
// 'darkMode'을(를) 쓰려고 했습니까?
})

```

- 순수한 구조적 타입 체커는 이런 종류의 오류를 찾아내지 못한다.
- 잉여 속성 체크를 이용하면 기본적으로 타입 시스템의 구조적 본질을 해치지 않으면서도 객체 리터럴에 알 수 없는 속성을 허용하지 않음으로써, 앞에서 다룬 문제점을 방지할 수 있다.

- 임시 변수를 사용하거나 객체 리터럴이 아닌 경우에는 잉여 속성 체크가 적용되지 않고 오류는 사라진다.

```tsx
const intermediate = { darkmode: true, title: 'hi' }

const o: Options = intermediate // -> 정상
```

- 타입 단언문을 사용할 때에도 적용되지 않는다.
- 인덱스 시그니처를 사용해서 타입스크립트가 추가적인 속성을 예상하도록 할 수 있다.

```tsx
interface Options {
  darkMode?: boolean
  [otherOptions: string]: unknown
}
const o: Options = { darkmode: true } // 정상
```

- 선택적 속성만 가지는 ‘약한(weak)’ 타입에도 비슷한 체크가 동작한다.

```tsx
interface A {
  name?: string
  phoneNumber?: string
}

const person = { phonenumber: '01012341234' }
const p: A = person
// ~ '{ phonenumber }' 유형에 'A' 유형과 공통적인 속성이 없습니다.

// 이런 약한 타입에 대해서 타입스크립튼는 값 타입과 선언 타입에 공통된 속성이 있는지 확인하는
// 별도의 체크를 수행한다.
```

→ 공통 속성 체크는 잉여 속성 체크와 다르게 약한 타입과 관련된 할당문마다 수행된다.

→ 임시 변수를 제거하더라도 공통 속성 체크는 여전히 동작한다.

즉 타입스크립트는 구조적 타이핑으로 모든 것을 일괄 적용하는 것이 아닌, 경우에 따라 잉여 속성 체크나 공통 속성 체크를 통해 사용자가 의도에 맞게 코드를 작성한 것이 맞는지 확인하는 별도의 장치를 두었다.


이펙티브 타입스크립트 더보기(1-2)


## Contents

# 서문

지난 7-9월 동안 ‘이펙티브 타입스크립트’ 도서에 대한 스터디를 진행했다.

개인적으로는 2회독이었는데, 혼자 공부한 1회독에서 책을 반도 못 흡수한 것 같아 아쉬움이 있었다.

스터디에서 함께 공부하고 발표하며 의견을 나누다보니 훨씬 쉽고 깊게 이해할 수 있어 좋았다.

![231004-152234](</posts/이펙티브_타입스크립트_더보기(0)/231004-152234.png>)

그리고 어쩌다보니 9번의 스터디 중 5번을 발표했다. 설명을 조리있거나 친절하게 잘 하는 편이 아니라서 좋은 연습 경험이었다.

[유튜브 링크](https://www.youtube.com/watch?v=4T3uN_wOxY0&list=PLvshXKhj0k4xGszZ1VBZT-dx4bdUzWA3w&ab_channel=%ED%9A%A8%EB%A6%AC%EB%B3%B4%EA%B3%A0)

그 동안은 단순하게 장 마다의 내용을 요약해서 업로드했는데, 구글링하면 비슷한 게시글이 많이 나온다. 그런데 책 자체가 불친절한 면…이나 번역이 있어 그대로 옮긴 내용들은 그다지 도움되지 않는다.

하여 주요한 깨달음이나 내용을 위주로 정리해 보고자 한다.

# 링크

- 스터디 깃허브
  https://github.com/prgrms-web-devcourse/FEDC4-TypeScript-Kkobugi-Study


TS

이펙티브 타입스크립트 더보기(5-8)

이펙티브 타입스크립트 더보기(3-4)

이펙티브 타입스크립트 더보기(1-2)

이펙티브 타입스크립트 더보기(0)