## Table of Contents

## Introduction

[이전 글](/2020/09/typescript-enum-not-treeshaked)에서도 언급했던 것 처럼, enum은 트리쉐이킹이 되지 않기 때문에 (정확히는 번들러가 무엇을 트리쉐이킹 해야할지 알 수 없으므로) 잘 사용하지 않는 다고 언급했었다.

```typescript
enum Direction {
  Up,
  Down,
  Left,
  Right,
}

Direction.Up // 0
Direction.Down // 1
Direction.Left // 2
Direction.Right // 3
```

는 자바스크립트로 아래와 같이 컴파일된다.

```javascript
'use strict'
var Direction
;(function (Direction) {
  Direction[(Direction['Up'] = 0)] = 'Up'
  Direction[(Direction['Down'] = 1)] = 'Down'
  Direction[(Direction['Left'] = 2)] = 'Left'
  Direction[(Direction['Right'] = 3)] = 'Right'
})(Direction || (Direction = {}))
Direction.Up // 0
Direction.Down // 1
Direction.Left // 2
Direction.Right // 3
// { 0: "Up", 1: "Down", 2: "Left", 3: "Right", Up: 0, Down: 1, Left: 2, Right: 3 }
```

[typescript playground](https://www.typescriptlang.org/play?#code/KYOwrgtgBAIglgJ2AYwC5wPYigbwFBRQCqADgDQGwYDuIFhAMsAGar1QBKcA5gBZt4AvnjzwkaTCAB0pKAHo5UAAyjEKdFikwa2BVACMq8RulNW8xQCYj6yVK59UFqAGYgA)

`const enum`을 사용하여 위와 같은 큰 트랜스파일을 없앨 수도 있지만, `--isolatedModules`옵션으로 인하여 별도의 처리가 필요하다고 언급했었다. 만약 그 문제를 넘어간다 하더라도 `enum`은 문제가 없는 것일까?

> [--isloatedModules](https://www.typescriptlang.org/tsconfig#isolatedModules) These limitations can cause runtime problems with some TypeScript features like const enums and namespaces. Setting the isolatedModules flag tells TypeScript to warn you if you write certain code that can’t be correctly interpreted by a single-file transpilation process.

## 숫자형 enum은 예기치 못한 문제를 이르킬 수 있다.

```typescript
enum Direction {
  Up,
  Down,
  Left,
  Right,
}

declare function move(direction: Direction): void

move(100) // ??
```

`Up`, `Down`, `Left`, `Right`가 0, 1, 2, 3 으로 할당되어서 분명 100은 들어가면 안됐을 텐데, 100도 별다른 문제 없이 들어가는 것을 볼 수 있다. 왜 그럴까?

사실 이는 [타입스크립트에서 의도된 동작](https://github.com/microsoft/TypeScript/issues/38294#event-3305063822)이다.

> [Ryan Cavanaugh](https://github.com/RyanCavanaugh)는 타입스크립트 author 아저씨다. [이 issue](https://github.com/microsoft/TypeScript/issues/26362)로 추측컨데, bitwise연산으로 인한 문제로 보인다.

## 문자형 enum의 경우

구조적 타이핑 세계에서, enum은 named type으로 불리기도 한다. 즉, 값이 올바르고 호환 가능하다 할지라도, 문자열 enum이 필요한 함수나 객체에 값을 전달할 수 없다는 뜻이다. 아래 예시를 살펴보자.

```typescript
enum Direction {
  Up = 'Up',
  Down = 'Down',
  Left = 'Left',
  Right = 'Right',
}

declare function move(direction: Direction): void

move('Up') // impossible
move(Direction.Up) // possible
```

이렇듯 문자형 enum과 숫자형 enum의 동작 방식에 차이가 있고, 또 위험성을 안고 있기 때문에 enum 사용을 꺼리는 편이다.

## Enum간의 값 비교도 안됨

```typescript
enum Direction1 {
  Up = 'Up',
  Down = 'Down',
  Left = 'Left',
  Right = 'Right',
}

enum Direction2 {
  Up = 'Up',
  Down = 'Down',
  Left = 'Left',
  Right = 'Right',
}

// This condition will always return 'false' since the types 'Direction1.Up' and 'Direction2.Up' have no overlap.
if (Direction1.Up === Direction2.Up) {
}
```

아무리 같은 값이라 할지라도, enum 내에 있으면 타입스크립트는 이 값을 비교할 수 없기 때문에 false가 리턴된다.

## Union Types을 대신 써보기

우리에겐 union type이 있다.

```typescript
type Direction = 'Up' | 'Down' | 'Left' | 'Right'

declare function move(direction: Direction): void

move('Up') // possible
```

만약 진짜 enum, 즉 숫자형 enum 을 쓰고 싶다면, `const`, 그리고 `as const` 와 함께 `Values<T>`의 헬퍼 타입을 써보는 것도 좋다.

```typescript
const Direction = {
  Up: 0,
  Down: 1,
  Left: 2,
  Right: 3,
} as const

type Values<T> = T[keyof T]

declare function move(direction: Values<typeof Direction>): void

move(Direction.Up) // Ok!
move(0) // Ok!
move(100) // ㅠ_ㅠ
```

- enum의 동작과 다르게 결과물이 어떨지 코드를 통해 명확히 알 수 있음
- 문자열 enum, 숫자형 enum 등으로 바꾼 다고 해서 (값을 바꾼다고해서) 동작에 차이가 발생하지 않음
- 타입 안전성 확보
- enum과 동일한 편의성 제공


내가 타입스크립트에서 Enum을 잘 쓰지 않는 이유

## Table of Contents

이따금씩 다른 사람들이 만들어둔 컴포넌트 코드를 보면, 함수형 컴포넌트에 `React.FC<>`를 달아두어서 함수를 타이핑 한 것을 종종 볼 수 있었다.

그러나 나는 그러한 방식을 썩 선호하지는 않는다. 그 이유는 다음과 같다.

## `React.FC<>`란 무엇인가?

리액트에서는 크게 두가지 방법으로 컴포넌트를 정의할 수 있다.

1. `Component`를 extending하는 클래스 컴포넌트
2. `JSX`를 리턴하는 함수형 컴포넌트

일단 리액트는 타입스크립트로 작성되있지 않기 때문에, 리액트 커뮤니티에서는 `@types/react`패키지를 제공하여 리액트에 대한 타이핑을 지원하고 있다. 여기에는 `FC`라고 하는 제네릭 타입이 있는데, 이를 활용하면 함수형 컴포넌트를 아래와 같이 타이핑 할 수 있게 도와준다.

```typescript
import { FC } from 'react'

type GreetingProps = {
  name: string
}

const Greeting: FC<GreetingProps> = ({ name }) => {
  return <h1>Hello {name}</h1>
}
```

그리고, 이 FC는 다음과 같은 구조로 되어 있다.

```typescript
type FC<P = {}> = FunctionComponent<P>

interface FunctionComponent<P = {}> {
  (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null
  propTypes?: WeakValidationMap<P> | undefined
  contextTypes?: ValidationMap<any> | undefined
  defaultProps?: Partial<P> | undefined
  displayName?: string | undefined
}
```

> [github 소스 코드 보기](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L548-L556)

## 함수를 타이핑 하지만, 인수를 타이핑 하지는 않는다.

`React.FC`는 함수를 타이핑해준다. 이름에서 할 수 있는 것처럼. 함수 타이핑은 일반적인 기명 함수에 적용하기 매우 어렵다. 만약 아래와 같은 코드에 함수 타이핑을 적용해본다고 가정해보자.

```typescript
function Greeting({ name }) {
  return <h1>Hello {name}</h1>
}
```

먼저 쉽게할 수 있는 방법 중 하나는, 익명 함수를 변수에 할당하여 타이핑 하는 것이다.

```typescript
const Greeting: FC<GreetingProps> = function ({ name }) {
  return <h1>Hello {name}</h1>
}
```

혹은 화살표 함수를 쓸 수도 있겠다.

```typescript
const Greeting: FC<{ name: string }> = ({ name }) => {
  return <h1>Hello {name}</h1>
}
```

그러나 우리가 일반적으로 쓰는 기명 함수 방식에서는 이러한 타이핑을 사용할 수 없다. 만약 함수 타이핑을 사용하지 않는다면, 함수를 기명이건 익명이건 어떤 방식으로 사용해도 문제가 없다.

```typescript
function Greeting({ name }: GreetingProps) {
  return <h1>Hello {name}</h1>
}
```

## `React.FC<>`는 항상 children을 가질수 있다.

`React.FC<>`로 타이핑 하는 것은 컴포넌트에 children이 있을 수 있다는 것을 의미한다.

```typescript
export const Greeting: FC<GreetingProps> = ({ name }) => {
  return <h1>Hello {name}</h1>
}

const App = () => (
  <>
    <Greeting name="Stefan">
      <span>{"I can set this element but it doesn't do anything"}</span>
    </Greeting>
  </>
)
```

`Greeting`에는 딱히 `children`을 렌더링하거나 처리하는 코드가 없음에도 위 코드는 정상적으로 처리되는 것을 볼수 있다.

대신, 일반적인 방법으로 한다면 아래코드는 다음과 같은 결과가 나온다.

```typescript
function Greeting({ name }: {name: string}) {
  return <h1>Hello {name}</h1>
}
const App = () => <>
  // Property 'children' does not exist on type 'IntrinsicAttributes & { name: string; }'.ts(2322)
  <Greeting name="Stefan">
    <span>{"I can set this element but it doesn't do anything"}</span>
  </Greeting>
</>
```

최소한 컴포넌트에 children의 존재가 가능한지 여부를 확인하는 것은 도움이 될 수 있다. 만약 컴포넌트에 children이 존재할 수도 있다는 것을 알리기 위해서는, `PropsWithChildren`을 사용하는 것이 좋다.

```typescript
type PropsWithChildren<P> = P & { children?: ReactNode | undefined }
```

[https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L830](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L830)

```typescript
function Card({ title, children }: PropsWithChildren<{ title: string }>) {
  return (
    <>
      <h1>{title}</h1>
      {children}
    </>
  )
}
```

## `React.FC<>`는 defaultProps를 쓰지 못하게 만든다.

`defaultProps`는 클래스 기반 컴포넌트의 유물로, props에 기본값을 세팅할 수 있도록 도와준다. 함수형 컴포넌트에서는, 자바스크립트의 기본적인 기능을 활용하면 기본값을 제공할 수 있다.

```typescript
function LoginMsg({ name = 'Guest' }: LoginMsgProps) {
  return <p>Logged in as {name}</p>
}
```

타입스크립트 3.1 버전 이후로, `defaultProps`를 이해하는 메커니즘이 추가되었으며, 이는 사용자가 세팅한 값을 기반으로 기본값이 설정된다. 그러나 `React.FC`는 `defaultProps`에 대한 타이핑 하기 때문에 이러한 기본값에 대한 연결고리를 끊어버리게 된다. 아래 코드를 살펴보자.

```typescript
type GreetingProps = {
  name: string
}

export const Greeting: FC<GreetingProps> = ({ name }) => {
  return <h1>Hello {name}</h1>
}
음
Greeting.defaultProps = {
  name: 'World',
}

const App = () => (
  <>
    {/* name에 world가 들어오지 않음 💥*/}
    <Greeting />
  </>
)
```

하지만, 일반적인 함수 방식이라면 `defaultProps`는 여전히 유효하다.

```typescript
export const Greeting = ({ name }: GreetingProps) => {
  return <h1>Hello {name}</h1>
}

Greeting.defaultProps = {
  name: 'World',
}

const App = () => (
  <>
    {/* Yes! ✅ */}
    <Greeting />
  </>
)
```

## Stateless Function Component의 과거

예전에는 모두가 함수형 컴포넌트를 stateless function component (무상태 함수형 컴포넌트)라고 불렀었다.

```typescript
/**
 * @deprecated as of recent React versions, function components can no
 * longer be considered 'stateless'. Please use `FunctionComponent` instead.
 *
 * @see [React Hooks](https://reactjs.org/docs/hooks-intro.html)
 */
```

[https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L532-L548](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0beca137d8552f645064b8a622a6e153864c66ee/types/react/index.d.ts#L532-L548)

훅이 소개된 이후로, 함수형 컴포넌트에는 많은 상태가 들어오기 시작했고 이제는 더이상 stateless하게 취급하지 않는다. 위 코드에서 볼 수 있는 것 처럼, `SFC`는 `FC`가 되었다. 또 훗날 `FC`가 무엇으로 바뀔 수 있을지도 모를일이다. 그러나 단순히 인수 (props)를 타이핑 하는 것은 이후에 함수의 타입이 바뀌더라도 안전하게 처리할 수 있다.

## Summary

`React.FC`를 쓰는 것이 꼭 나쁜 것 만은 아니다. 여전히 이것을 사용하는게 좋은 경우도 있을 것이고, 그렇다고 이를 억지로 고칠 필요도 없을 수 있다. 그러나 props를 타이핑 하는 것이 조금더 자바스크립트의 느낌과 비슷하고, 다양한 경우의 수로 부터 조금더 안전해 질 수는 있다.


React.FC가 잘못됐다는 이야기는 아닙니다

React.FC를 사용하지 않는 이유

## Table of Contents

## Introduction

리액트에서 훅이 등장한 2018년 이래로, 리액트 커뮤니티에서는 함수형 컴포넌트 사용에 많은 탄력을 받았다. 훅을 사용하여, 함수형 컴포넌트의 상태 로직 (stateful logic)과 렌더링 로직을 매우 손쉽게 분리할 수 있게 되었다.

이 후 수년간 리액트에서 훅을 사용해오면서, 훅이 항상 편리함만을 제공해주는 것은 아니다. 모든 코드가 그렇지만 당연히 여기에도 위험성이 존재하며, 훅도 마찬가지다.

## 클로져

객체/함수지향 프로그래밍에 대해 잘못 알려진 사실 중 하나는, 객체 지향은 stateful하고, 함수지향은 stateless 하다는 것이다. 그리고 이 논쟁에 뒤따르는 사실 중 하나는, 상태는 보통 나쁜 것으로 치부되기 때문에 상태를 피하고, 더 나아가 객체 지향을 피해야 한다는 사실로 이어진다. 이 말 중 일부는 옳지만, 대부분의 진실이 그렇듯, 잘못된 사실도 있다.

`state`, 즉 상태란 무엇인가? 컴퓨터에서는 '계산을 한 값을 보관해두는 것'이라고 불리우는, 주로 메모리에 들어가 있는 값을 의미한다. 변수에 무언가를 저장할 때 마다 그 변수에 주어진 라이프 타임 동안 상태를 유지하게 된다. 그리고 프로그래밍 패러다임의 유일한 차이는, 이 변수를 얼마나 오래 보관해두느냐, 그리고 이 결정이 어떤 트레이드 오프를 가지고 오느냐 정도로 볼 수 있다.

아래 동일한 작업을 하는 함수형 코드와 객체지향 코드를 살펴보자.

```javascript
class Hello {
  i = 0
  inc() {
    return this.i++
  }
  toString() {
    return String(this.i)
  }
}
const h = new Hello()
console.log(h.inc()) // 1
console.log(h.inc()) // 2
console.log(h.toString()) // "2"
```

```javascript
function Hello() {
  let i = 0
  return {
    inc: () => i++,
    toString: () => String(i),
  }
}
const h = Hello()
console.log(h.inc()) // 1
console.log(h.inc()) // 2
console.log(h.toString()) // "2"
```

여기에서 메모리를 유지하는 메커니즘 (`i`) 은 많은 공통점을 가지고 있다. 클래스는 객체의 인스턴스를 참조하는 `this`를 사용하는 방식으로, 함수형은 범위내 모든 변수를 기억하는 클로져를 활용하는 방식으로 이 기능을 구현했다.

클로져는 함수를 `stateful`하게 만들어 주기 때문에 매우 중요한 개념이라 볼 수 있다. 그러나 클로져의 한가지 중요한 문제점이라고 한다면, 메모리 누수가 쉽게 일어난다는 점이다. 함수가 스코프를 넘어서도 살아있을 수 있기 때문에, 가비지 콜렉터가 이를 수집할 수가 없게 된다. 위 예제에서는, `inc`가 존재하는한, `i`는 가비지 콜렉팅 당하지 않을 것이다.

클로져에서 또한가지 조심해야 할 것은, 명시적 의존성을 암묵적인 의존성으로 바꿔버린다는 것이다. 함수에 인수를 넘겨주면, 그 함수의 의존성은 명시적이라고 볼 수 있지만, 프로그램이 이 클로저가 무엇에 의존성을 가지고 있는지는 알 수 없게 된다. 즉, 클로저가 메모리에 보관하는 값은 호출에 따라서 변화할수도, 그 결과에 따라 다른 값을 만들어 버릴 수도 있다.

## 클로져와 훅

```javascript
function User({ user }) {
  useEffect(() => {
    console.log(user.name)
  }, []) // exhaustive-deps

  return <span>{user.name}</span>
}
```

훅에 있는 개념 중 하나는, 의존성에 변화가 있을 때마다 (`dependencies`) 부수효과가 발생한다는 것이다. 예를 들어, `useEffect`는, 엑셀 시트처럼, 부수효과에 필요한 입력값이 달라지는 경우에만 실행된다. `useMemo` `useCallback`도 마찬가지다.

훅은 예제의 `user` 처럼, 해당 스코프에서 정보를 보고 유지할 수 있기 때문에 클로져의 이점을 누릴 수 있다. 그러나, 이러한 종속성이 암묵적이어서, 이 사이드 이펙트가 언제 실행되어야 하는지 알 수 없다.

클로져는 훅 api에 일련의 `dependencies`가 필요한 이유다. 이 결정은 프로그래머가 이러한 암묵적인 의존성을 명확히 하는 책임을 지도록 강요하고, 따라서 일종의 '휴먼 컴파일러'로서 기능한다. dependencies를 선언하는 것은 수동으로 하는 보일러 플레이트 작업이며, C 메모리 관리와 같이 오류가 발생하기 십상이다.

이 문제를 해결하기 위한 리액트의 해결책은 `eslint` 이지만, 리액트 훅을 커스텀 훅으로 구성하면 문제가 또 발생한다.

이 문제를 완전히 피할 수 있는 방법은, 훅을 컴포넌트 외부로 이동시키는 것이다. 이렇게 한다면, 의존관계로 사용할 수 있는 인수를 강제적으로 건내받을 수 있게 된다.

```javascript
const createEffect =
  (fn) =>
  (...args) =>
    useEffect(() => fn(...args), args)
const useDebugUser = createEffect((user) => {
  console.log(user.name)
})

function User({ user }) {
  useDebugUser(user)

  return <span>{user.name}</span>
}
```

훅을 클로져 외부로 이동시키면, dependencies를 수동으로 추적하거나 subscription이 부족해지는 문제 (`dependencies`가 모자른)에 직면할 필요가 없다. 그러나 여전히 리액트와 자바스크립트가 두 종속성이 같은지를 판단하는 문제에 대해서는 여전히 취약하다.

## 동일성과 메모리

동일성이라고 한다면, 변하지 않은 것 이라고 이해하 면 쉽다. 예를 들어, 3은 언제나 3이다. 자바스크립트에서는, 이러한 동등 비교를 실행할 수 있는 여러가지 방법이 있다. 예를 들어, `==` `===` `Object.is`는 완전히 다른 방식이며, 각 다른 결과를 얻을 수 있다. `Object.is`의 경우, 연산한 값이 같은지 확인한다.

- 두 개가 `undefined` 인지
- 두 개가 `null`인지
- 두 개가 `true` `false` 인지
- 두 개가 `+0` 인지
- 두 개가 `-0` 인지
- 두 개가 `NaN`인지
- 혹은 0, `NaN`이 아니며 같은 값을 가지고 있는지
- 문자열의 경우, 크기와 구성하고 있는 글자가 같은 순서인지
- 나머지 non-primitive의 경우, 이들은 mutate하기 때문에, 메모리 참조가 같은지 비교한다. 이는 일반적인 개발자의 직관과 다르다. `Object.is([], [])`는 두 배열 객체의 메모리 포인터가 다르므로 `false` 가 나온다.

> [MDN 문서](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object/is#%EC%84%A4%EB%AA%85) 참고

## 훅과 동일 비교

훅은 dependencies를 비교할 때 `Object.is`를 사용한다. 따라서 의존성을 비교했을 때, 이 둘이 다를 때만 실행 된다. 여기서 같다는 것은 `Object.is`를 사용하여 비교한다.

```javascript
const User({ user }) {
  useEffect(() => {
    console.log(`hello ${user.name}`)
  }, [user]) // eslint barked, so we added this dependency

  return <span>{user.name}</span>
}
```

위 컴포넌트에서, `useEffect`는 얼마나 실행될까? 알 수 없다. `user`가 달라지는 횟수 만큼 실행될 것이다. `user`가 메모리에 어떻게 할당되었는지 모른다면, 이 객체가 어떻게 동일 비교를 할 수 있는지 알 수 없다. 즉 이 코드는 동작할 수 있지만, 올바르지 않으며 상위컴포넌트에서 변경이 일어나면 완전히 망가질 수도 있다.

```javascript
function App1() {
  const user = { name: 'paco' }

  return <User user={user} />
}

const user = { name: 'paco' }
function App2() {
  return <User user={user} />
}
```

위 예제에서, 우리는 훅의 미묘한 부분을 알 수 있다.

`App1`은 매번 새로운 객체를 할당한다. 이 객체는 개발자가 볼 때는 항상 동일하지만, `Object.is`가 볼 때는 그렇지 않다. 즉, 이 컴포넌트는 렌더링 할 때마다 `useEffect`가 실행될 것이다.

`App2`는 항상 같은 객체 포인터를 참조한다. 즉, 렌더링 횟수에 관계없이 사이드 이펙트가 실행되는 것은 한번 뿐이다.

실제 코드는 이보다 훨씬 더 복잡하기 때문에, 개발자는 객체가 언제, 얼마나 할당되는지 이해하기 쉽지 않다.

이번엔 실제 프로덕션에서 사용될 법한 코드를 살펴보자.

```javascript
function App({ options, teamId }) {
  const [user, setUser] = useState(null)
  const params = { ...options, teamId }

  useEffect(() => {
    fetch(`/teams/${params.teamId}/user`)
      .then((response) => response.json)
      .then((user) => {
        setUser(user)
      })
  }, [params])

  return <User user={user} params={params} />
}
```

위 예제는 동일한 요청을 반복적으로 시도할 것이다. 객체를 재구성하게 되면, 렌더링 시마다 새로운 객체를 할당하므로 `useEffect`의 dependencies로 사용하기에는 부적절하다.

## 결론

훅은 다른 기술과 마찬가지로, 새로운 기술로서의 일종의 과대 광고 효과를 어느정도 누렸다고도 볼 수 있다. 많은 개발자가 상태 관리 솔루션 대신, 상태 저장 로직을 구현하기 위해 훅을 채택했다. API는 쉬워 보이지만, 그 내부 동작은 복잡하기 때문에 부정확할 위험이 높아진다.

대부분의 버그는 컴포넌트에서 훅을 떼고, 유일한 의존관계로 primitive 를 사용하여 해결할 수 있다. 타입스크립트를 사용하는 경우, 자체 훅을 만들어 엄격하게 입력하고 관리할 수 있다. 이를 통해 개발자들이 훅이 가진 한계를 이해하는데 큰 도움이 될 수 있다.

```typescript
type Primitive = boolean | number | string | bigint | null | undefined
type Callback = (...args: Primitive[]) => void
type UnsafeCallback = (...args: any[]) => void

const createEffect =
  (fn: Callback): Callback =>
  (...args) => {
    useEffect(() => fn(...args), args)
  }

const createUnsafeEffect =
  (fn: UnsafeCallback): UnsafeCallback =>
  (...args) => {
    useEffect(() => fn(...args), args)
  }
```


deps에 primitive 값만 사용하기, 훅을 컴포넌트에서 제거하기

리액트 훅을 사용할 때 조심해야 할 것

## Table of Contents

## exclude

[exclude](https://www.typescriptlang.org/docs/handbook/utility-types.html#excludeuniontype-excludedmembers)는 여러개의 타입이 함께 존재하는 유니언 타입에서 특정 타입을 제거하는 유틸리티 타입이다. `exclude`로 제거할 수 있는 것은 하나의 타입 부터 유니언 까지 가능하다.

```typescript
type T0 = Exclude<'a' | 'b' | 'c', 'a'>
// type T0 = "b" | "c"
type T1 = Exclude<'a' | 'b' | 'c', 'a' | 'b'>
// type T1 = "c"
type T2 = Exclude<string | number | (() => void), Function>
// type T2 = string | number
```

[exclude의 동작방식](https://github.com/microsoft/TypeScript/blob/546a87fa31086d3323ba4843a634863debb75781/lib/lib.es5.d.ts#L1503-L1506)을 보면 다음과 같이 확인할 수 있다.

```typescript
/**
 * Exclude from T those types that are assignable to U
 */
type Exclude<T, U> = T extends U ? never : T
```

### extends

제네릭에서 사용되는 `T extends U`라는 키워드는 **T가 U라는 타입인지** 를 의미한다.

즉, 위 예시를 해석하면 다음과 같다.

> `T`가 `U`의 타입 이라면, `never` (빈 타입)을, 그렇지 않다면 `T` 그자체, 즉 원래대로 돌려준다

## pick

[pick](https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-keys)은 객체 타입에서, 넘겨받은 키에 해당하는 키만 리턴하는 새로운 객체 타입을 만들어준다.

```typescript
interface Todo {
  title: string
  description: string
  completed: boolean
}

type TodoPreview = Pick<Todo, 'title' | 'completed'>

const todo: TodoPreview = {
  title: 'Clean room',
  completed: false,
}
```

pick이 작동하기 위해서는, 먼저 객체에서 키를 뽑아서 해당 키를 제외해야 하므로, 객체 타입에서 키를 뽑는 법 부터 알아야 한다.

```typescript
keyof Todo // "title" | "description" | "completed" | "createdAt"
```

그 다음, 이 키에 해당 하는 객체 타입의 값만 뽑아 오면 될 것이다.

```typescript
type Pick<T, Key extends keyof T> = {
  [NewKey in key]: T[key]
}
```

작동방식을 확인하면 거의 유사하다는 것을 알 수 있다.

> [타입스크립트 원본 코드 확인해보기](https://github.com/microsoft/TypeScript/blob/546a87fa31086d3323ba4843a634863debb75781/lib/lib.es5.d.ts#L1489-L1494)

## Omit

[omit](https://www.typescriptlang.org/docs/handbook/utility-types.html#omittype-keys) 은 객체 타입 (interface 등)에서 특정 키를 기준으로 생략하여 타입을 내려주는 유틸리티 타입이다.

```typescript
interface Todo {
  title: string
  description: string
  completed: boolean
  createdAt: number
}

// description을 제외
type TodoPreview = Omit<Todo, 'description'>

const todo: TodoPreview = {
  title: 'Clean room',
  completed: false,
  createdAt: 1615544252770,
}
```

마찬가지로 키를 먼저 뽑아온다.

```typescript
type TodoKeys = keyof Todo // "title" | "description" | "completed" | "createdAt"
```

그리고 이번에는 해당하는 값을 가져오는 것이 아니고, 제거를 해야한다. 여기서 부터 조금씩 복잡해지는데, 하나씩 해보자.

먼저 앞서 사용했던 `Pick`과 `Exclude`를 활용하여, `TODO`에서 `title`만 제거해보자.

```typescript
type TodoWithoutTitle = Pick<Todo, Exclude<keyof Todo, 'title'>>
// type TodoWithoutTitle = {
//     description: string;
//     completed: boolean;
//     createdAt: number;
// }
```

이를 깔끔하게 제네릭으로 정리하면 다음과 같다.

```typescript
type Omit<T, K> = Pick<T, Exclude<keyof T, K>>
```

객체의 키로 `string`, `number`, `symbol`만 가능하기 때문에, 조금 아래와 같이 추가할 수도 있다.

```typescript
type Omit<T, K extends keyof string | number | symbol> = Pick<
  T,
  Exclude<keyof T, K>
>
```

> https://github.com/microsoft/TypeScript/blob/546a87fa31086d3323ba4843a634863debb75781/lib/lib.es5.d.ts#L1513-L1516
> 뭔가 저건 과하다고 생각한건지 `any`로 퉁쳤다.

### Omit 과정 다시한번 살펴보기

```typescript
interface Todo {
  title: string
  description: string
  completed: boolean
  createdAt: number
}

type TodoWithoutTitle = Omit<Todo, 'title'>

type TodoWithoutTitle = Pick<Todo, Exclude<keyof Todo, 'title'>>

type TodoWithoutTitle = Pick<
  Todo,
  Exclude<'title' | ' description' | 'completed' | 'createdAt', 'title'>
>

type TodoWithoutTitle = Pick<
  Todo,
  | ('title' extends 'title' ? never : 'title')
  | ('description' extends 'title' ? never : 'description')
  | ('completed' extends 'title' ? never : 'completed')
  | ('createdAt' extends 'title' ? never : 'createdAt')
>

type TodoWithoutTitle = Pick<
  Todo,
  never | 'description' | 'completed' | 'createdAt'
>

type TodoWithoutTitle = {
  [Key in 'description' | 'completed' | 'createdAt']: User[Key]
}

type TodoWithoutTitle = {
  description: Todo['description']
  completed: Todo['completed']
  createdAt: Todo['createdAt']
}

type TodoWithoutTitle = {
  description: string
  completed: boolean
  createdAt: number
}
```


헬퍼 타입도 잘 알고 써야 도움이 된다

타입스크립트의 Omit은 어떻게 동작할까? Exclude, Pick 부터 알아보기

## Table of Contents

## Introduction

자바스크립트의 경우를 먼저 생각해보자. 자바스크립트는 함수에 넘기는 인수를 다른 타입으로 하거나, 혹은 다른 위치에 넣는 등 함수가 넘겨받는 인수의 구조를 유연하게 작성할 수 있다. 아래 실제 api를 살펴보자.

- [node.js의 filehandle.write](https://nodejs.org/api/fs.html#filehandlewritebuffer-offset-length-position)
  - `filehandle.write(buffer)`
  - `filehandle.write(string)`
- [node-postgress](https://node-postgres.com/features/queries)의 쿼리
  - `client.query('query', (err, res) => ...)`
  - `client.query('query', ['value1', value2'] (err, res) => ...)`

이런 함수의 다향성을 쉽게 타이핑하기 위해서는 어떻게 해야할까?

## `Union`

`Union` 타입을 쓰는 것은 다른 타입의 인수를 허용하는 함수를 작성할 때 가장 먼저 떠오르는 방법일 것이다.

```typescript
declare function foo(a: string | number)
```

여기서 `a`는 `string` `number` 둘다 될 수 있으므로, 다양한 타입의 인수가 필요하다면 `Union`을 쓰는 것은 적절해보인다. 그리고 내부에 타입 가드 함수를 추가하여 함수 내부에서 적절하게 필요한 타입을 좁힐 수 있다.

```typescript
function foo(a: string | number) {
  if (typeof a === 'string') {
    // do something...
  }

  if (typeof a === 'number') {
    // do something...
  }
}
```

그렇다면, 리턴 타입이 인수가 어떤 타입이느냐에 따라 달라진다고 가정해보자. 그렇다면 어떻게 타이핑하는 것이 좋을까? 여기에서는 제네릭 타입을 이용하여 인수를 타이핑 하는 것이 좋을 것이다. 그리고 이를 올바른 리턴 값에 따라 조건부로 타이핑 하면 될 것이다.

이러한 문제를 한번 예시로 들어보자. `int`라고 하는 인수가 온다면 랜덤한 숫자를, `char`라는 인수가 온다면 랜덤한 글자를 반환하는 함수를 작성해보자. 먼저 자바스크립트다.

```typescript
function getRandom(str) {
  if (str === 'int') {
    // generate a random integer
    return Math.floor(Math.random() * 10)
  } else {
    // generate a random char
    return String.fromCharCode(97 + Math.floor(Math.random() * 26))
  }
}
```

이를 타입스크립트에서 적절하게 타이핑 하기 위해서는, 아래와 같은 순서로 작업을 해야 한다.

- 먼저 `str`이 `"int" | "char"`와 같은 유니언 타입으로 선언하고, 리턴 타입을 이에 의존하도록 해야 한다. 이를 위해서는, 우리는 제네릭 타입을 사용해야 한다.
- 앞서 만든 제네릭 조건부 타입을 `GetReturnType` 이라 불리는 타입에 넘겨주어, `T`에 따라 올바른 리턴 타입이 올 수 있도록 해야 한다.

위 두 조건을 구현한 식이다.

```typescript
type GetReturnType<T> = T extends 'char' ? string : T extends 'int' ? number : never

function getRandom<T extends'char' | 'int'>(str: T): GetReturnType<T> {
  if (str === 'int') {
    // generate a random number
    return Math.floor(Math.random() * 10) as GetReturnType<T>
  } else {
    // generate a random char
    return String.fromCharCode(97+Math.floor(Math.random() * 26)) as GetReturnType<T>
}
```

이제, 여기서 한단계 더 뇌절해서 랜덤 `boolean`도 지원한다고 가정해보자.

```typescript
type GetReturnType<T> = T extends 'char'
  ? string
  : T extends 'int'
  ? number
  : T extends 'bool'
  ? boolean
  : never

function getRandom<T extends 'char' | 'int' | 'bool'>(
  str: T,
): GetReturnType<T> {
  if (str === 'int') {
    // generate a random number
    return Math.floor(Math.random() * 10) as GetReturnType<T>
  } else if (str === 'char') {
    // generate a random char
    return String.fromCharCode(
      97 + Math.floor(Math.random() * 26),
    ) as GetReturnType<T>
  } else {
    // generate a random boolean
    return Boolean(Math.round(Math.random())) as GetReturnType<T>
  }
}
```

위 코드에서 볼 수 있듯이, 타입이 하나씩 함수에 추가될 때 마다 확장하는 과정이 부담스러운 것을 볼 수 있다. 다행이도, 이러한 과정은 제네릭 타입을 받는 대신에 아래처럼 객체 타입으로 하면 좀더 쉬워 진다.

```typescript
type ReturnTypeByInputType = {
  int: number
  char: string
  bool: boolean
}

function getRandom<T extends 'char' | 'int' | 'bool'>(
  str: T,
): ReturnTypeByInputType[T] {
  if (str === 'int') {
    // generate a random number
    return Math.floor(Math.random() * 10) as ReturnTypeByInputType[T]
  } else if (str === 'char') {
    // generate a random char
    return String.fromCharCode(
      97 + Math.floor(Math.random() * 26),
    ) as ReturnTypeByInputType[T]
  } else {
    // generate a random boolean
    return Boolean(Math.round(Math.random())) as ReturnTypeByInputType[T]
  }
}
```

`document.querySelector`를 생각해보자. 이 함수는 여러가지 다양한 태그명을 인수로 받고, 그에 맞는 요소를 리턴한다. [타입스크립트의 `lib.dom.d.ts`를 보면 이러한 구현 내용](https://github.com/microsoft/TypeScript/blob/ca00b3248b1af2263d0223d68e792b7ca39abcab/lib/lib.dom.d.ts#L11050-L11052)을 볼 수 있다.

### 그런데 타입 단언은 왜 필요할까?

위 코드를 보면 거추장스럽게 모든 리턴문에 `as ReturnTypeByInputType[T]`가 붙어 있는 것을 볼 수 있다. 이는 타입스크립트 3.5 부터 추가된 리턴 값에 https://www.typescriptlang.org/docs/handbook/2/indexed-access-types.html (여기에서는 `as ReturnTypeByInputType[T]`)를 주기 위해서다. 해당 인덱스에서 선택한 속성 (타입)의 모든 가능한 intersection에 대해서 리턴 타입을 체크해야 하기 때문이다. 위 예제에서는, 리턴 값이 `ReturnTypeByInputType[T]` 모두를 만족하거나, `number & string & boolean`을 모두 만족하는 intersection 타입을 넘겨주거나 (그런 타입은 `never` 뿐이다) 해야 한다. 양쪽 두 조건을 모두 만족하는 것은 `never` 뿐이므로, `as never`로 작성해도 작동한다.

타입 단언은 본질적으로 안전하지 않은 방식이다. 이를 함수 오버로딩으로 해결하는 방식도 있다. 그러나 두개다 사실 그정도로 안전하지는 않다.

## 옵셔널 파라미터

옵셔널 파라미터 또한 매우 일반적인 방식으로, 파라미터를 정의하여 사용할 수 있으며, 정의 되지 않은 파라미터에 대해서는 검사할 필요도 없다.

타입스크립트에서는, `?`를 사용하면 된다.

```typescript
declare function foo(a: string, b?: boolean)
```

여기에서는 결과적으로, `b`는 `boolean | undefined` 형태의 union 타입이 된다.

이러한 옵셔널 파라미터의 제공 여부에 따라서 다른 유형의 값을 리턴하는 패턴도 일반적으로 볼 수 있다.

검색 결과를 비동기로 가져오는 `search` 함수가 있다고 가정해보자. 이 함수는 콜백 함수를 인수로 받는다. 이 콜백 인수가 있으면, 검색 결과를 콜백 함수로 전달한다. 그렇지 않으면 검색 결과를 확인 할 수 있는 `Promise`를 반환한다.

```javascript
function search(query, cb) {
  const res = api(query)
  if (cb) {
    res.then((data) => cb(data))
    return
  }

  return res
}

const p = search('foo') // return a promise
const v = search('foo', (data) => {}) // void
```

타입스크립트에서는, 이 함수를 다음과 같은 과정으로 타이핑 할 수 있다.

- `cb`를 `?`와 함께 옵셔널 파라미터로 지정한다.
- `cb` 의 타입을 제네릭으로 타이핑 한다.
- `extends` 키워드를 사용하여 올바른 타입으로 타이핑 한다.

```typescript
type Callback = (results: Result[]) => void

function search<T extends Callback | undefined = undefined>(
  query: string,
  cb?: T,
): T extends Callback ? void : Promise<Result[]> {
  const res = api(query)

  if (cb) {
    res.then((data) => cb(data))
    return undefined as void & Promise<Result[]>
  }

  return res as void & Promise<Result[]>
}

const p = search('key') // ✅ Promise<Result[]>
const v = search('key', (data) => {}) // ✅ void
```

여기서 확인할 수 있는 사실은 다음과 같다.

- `extends` 라고 하는 조건부 표현을 사용하여 올바른 리턴타입을 정의 했다.
- 타입 단언이 역시나 필요하다.

여기도 타입단언이 추가되면서 꽤나 복잡해졌다. 만약 복잡한 다형성 함수가 필요하다면, 더 나은 다음의 대안을 쓰는게 좋을 수도 있다.

## 함수 오버로드

타입스크립트는 함수 오버로드를 지원하고 있다. 이 타입스크립트의 함수 오버로드는 1.1 부터 볼 수 있던 오래된 기능이다. 그러나 타입스크립트 초기 개발 중에 추가된 다른 기능들과는 다르게, (enum 등) 이 오버로드 기능은 잘 쓰이지 않는 경향이 있다.

아마도 함수 오버로드를 잘 사용하지 않는 이유는 자바스크립트 개발자들에게는 조금 낯선 개념이라 그런게 아닐까 싶다. 자바스크립트에서는, 함수 오버로드가 없다. 자바스크립트는 특정 스코프에서는 특정한 명칭을 가진 하나의 함수만 존재할 수 있다.

그러나 동적 타입 언어세너는, 자바스크립트의 타입 체크가 런타임 중에 일어난다. 이 말은 함수의 인수를 동적으로 우리가 필요한 만큼 가질 수 있으며, 이는 마치 함수 오버로드와 같이 동작한다는 것이다.

### 함수 오버로딩 구현하기

인수가 숫자라면 이를 문자로, 반대로 문자라면 숫자로 리턴하는 함수를 구현한다고 가정해보자. 자바스크립트에서는 아마 이렇게 구현할 것이다.

```typescript
function switchIt(input) {
  if (typeof input === 'string') return Number(input)
  else return String(input)
}
```

이를 앞선 예제와 같은 형식으로 타입스크립트에서 구현한다면 이렇게 될 것이다.

```typescript
function switchIt<T extends string | number>(
  input: T,
): T extends string ? number : string {
  if (typeof input === 'string') {
    return Number(input) as string & number
  } else {
    return String(input) as string & number
  }
}

const num = switchIt('1') // has type number ✅
const str = switchIt(1) // has type string ✅
```

이것을 함수 오버로딩 방식으로 타이핑 할 것이다.

- 먼저 두개의 다른 시그니쳐를 만든다.
- 오버로드한 함수의 구현부를 작성한다.
  - 유니언 타입으로 각 인수의 타입을 받는다.
  - 함수 내부에서는, 타입 가드를 사용하여 적절한 처리를 추가한다.

```typescript
function switchIt_overloaded(input: string): number
function switchIt_overloaded(input: number): string
function switchIt_overloaded(input: number | string): number | string {
  if (typeof input === 'string') {
    return Number(input)
  } else {
    return String(input)
  }
}
```

함수 오버로드를 사용하여,

- 제네릭과 조건부 타입을 제거
- 타입 단언 제거

이 덕분에

- 가독성 향상. 오버로드한 함수가 어떤 타입이 올 수 있는지 명확하게 구별할 수 있다. 또한 인수의 타입과 그에 따른 리턴 타입이 명확하게 분리되어 있다.
- IDE가 오버로드 함수를 더욱 잘 지원할 수 있게 된다.

### 좀더 복잡한 예제

방금 전에 만들었던 검색 함수 예제를 떠올려 보자. 이를 함수 오버로딩으로 구현하면 다음과 같이 처리할 수 있다.

```typescript
type Callback = (results: Result[]) => void

function search_overloaded(term: string): Promise<Result[]>
function search_overloaded(term: string, cb: Callback): void
function search_overloaded(
  term: string,
  cb?: Callback,
): void | Promise<Result[]> {
  const res = api(term)

  if (cb) {
    res.then((data) => cb(data))
    return
  }

  return res
}

const p = search_overloaded('key') // ✅ Promise<Result[]>
const v = search_overloaded('key', (data) => {}) // ✅ void
```

### 이것도 안전하지 않기는 마찬가지

타입 단언은 종종 좋지 않은 코드 (code smell)로 간주되며, 이를 함수 오버로드로 제거하는 것은 좋아보일 수도 있다. 그러나 이것 또한 안전하지 않은 건 매한가지다.

```typescript
function switch_overloaded(input: string): number
function switch_overloaded(input: number): string
function switch_overloaded(input: number | string): number | string {
  if (typeof input === 'string') {
    return input // 그냥 string 리턴함
  } else {
    return input // 그냥 숫자 리턴함
  }
}

const num = switch_overloaded('1') // ❌ ????
const str = switch_overloaded(1) // ❌ ????
```

> [typescript playground에서 보기](https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAZwO4yhAFgfTgNwFMAnAGzgEMATQqgChjAAcQoAuFKYxgcwEoOYEAFsARiQBQoSLAQp0mXARLlqtBs1aCR44gM7cwPKeGjwkaDNjxEylGvUYt2iIWJKIAPgd763urx8jRABvCUQIiJhgRDooAE8mQjgYp1ZEAF4sxAByZC5eHL5Q8Miy4kIoEGIkNKhEAHoGxEAP2sBThqCeREAazsAWRcALVdKIgF9EQlJkQhKy8srq2s16ptaOwGohwATxnoGhxFGJYYkJCAR81xFM+SslW1UHOhyARiLG5sAZcjPhPMQEpMQYZA+AVE6QwfwBFGgIAopFI8UQFE6RxO9XyxAulkUNhU9nUD2Ky3eqK+Pym-06iGB9VBZIhVWhsPhgJIQA)

읭? 올바르지 않은 타입을 리턴해버렸음에도 에러가 나지 않는다. 타입스크립트 컴파일러는 함수 본체의 코드 (오버로드 된)의 함수 시그니처와 대조할 뿐이지, 분기 문에서 어떻게 오버로드를 다루는지는 알 수 없다. 결과적으로, 오버로드 함수 시그니처와 모순된 내부 코드를 작성할 수 있는 위험성이 존재한다.

### 사실 함수 오버로드도 함수타입의 intersection 일 뿐...

함수 오버로드는 intersection 함수 타입에 대한 단지 문법적 설탕일 뿐이다.

```typescript
function switchIt(input: string): number
function switchIt(input: number): string
```

이는 사실 아래와 같다.

```typescript
type F = ((input: string) => number) & ((input: number) => string)

const switchIt_intersection: F = (input) => {
  if (typeof input === 'string') {
    return Number(input)
  } else {
    return String(input)
  }
}

const num = switchIt_intersection(1) // ✅
const str = switchIt_intersection('1') // ✅
```

마찬가지로, `F`도 객체 타입(인터페이스) 형태로 작성할 수도 있다.

```typescript
interface F {
  (input: number): string
  (input: string): number
}
```

## 정리

함수 오버로드를 사용하건, 조건부 타입을 활용한 제네릭 타입을 사용하건, 어떤 것을 사용하든지 이 선택에는 적절한 이유가 있어야 하고, 어느 것도 안전하지 않기 때문에 신중해야 한다.

- 함수의 인수가 여러개가 될 수 있는 경우, 함수 오버로드를 사용하는게 적절할 수 있다.
- 조건 타입에 따른 제네릭 타입은 인수가 리턴 타입에 영향을 미칠 때 적절하게 활용 가능하다. 매핑으로 구현하면 가독성이 눈에 띄게 향상되기 때문이다. 이를 함수 오버로드로 작성하면 매우 장황해질 수 있고, 읽는 사람으로 하여금 혼란을 야기할 수 있다.


mapped type과 오버로딩, 어떤걸 쓰는게 좋을까?

Typescript 2

내가 타입스크립트에서 Enum을 잘 쓰지 않는 이유

React.FC를 사용하지 않는 이유

리액트 훅을 사용할 때 조심해야 할 것

타입스크립트의 Omit은 어떻게 동작할까? Exclude, Pick 부터 알아보기

타입스크립트의 함수의 다형성