```javascript
const object = {
  a: 'a',
  b: 'b',
  c: 'c',
}

const value = 'a'

const values = Object.values(object) // a, b, c
const isValid = values.includes(value) // true

if (!isValid) {
  throw new TypeError(`${value} is not one of values, ${values`)
}
```

위 코드에서, `value`가 `a` `b` `c` 중 하나가 아니면 에러가 날 것이다. 이를 타입스크립트에서 타입 가드를 하는 방법을 살펴보자.

## typescript

```typescript
const object = {
  a: 1,
  b: 2,
  c: 3,
}

type objectShape = typeof object
```

여기서 `objectShape`는 아래와 같을 것이다.

```typescript
type objectShape = {
  a: number
  b: number
  c: number
}
```

여기에 `as const` 를 추가해보자.

```typescript
const object = {
  a: 1,
  b: 2,
  c: 3,
} as const

type objectShape = typeof object
```

```typescript
type objectShape = {
  readonly a: 1
  readonly b: 2
  readonly c: 3
}
```

두가지가 바뀐 것을 볼 수 있다. 첫번째로, 모든 속성에 `readonly`가 붙어서 객체의 키 값을 바꿀 수 없게 되었고 두번째로는 `string`이 었던 값이 정확히 값으로 바뀌게 되었다. 이는 모두 `readonly`로 값이 수정되지 않는 다는 것을 확실히 했기 때문이다.

이번엔 키를 추출해보자.

```typescript
type keys = keyof objectShape // "a" | "b" | "c"
```

이러한 키를 추출했으니, 값들도 추출해 낼 수 있다.

```typescript
type values = objetShape[keys] // 1 | 2 | 3
```

## Valueof Generic

```typescript
type objectShape = typeof object
type keys = keyof objectShape
type values = objectShape[keys]
```

이번엔 제네릭으로 돌아가보자.

```typescript
type values = Shape[keyof objectShape]
type ValueOf<T> = T[keyof T]
```

```typescript
const object = {
  a: 1,
  b: 2,
  c: 3,
}

type ValueOf<T> = T[keyof T]
const a: ValueOf<typeof object> = 1
const b: ValueOf<typeof object> = 2
const c: ValueOf<typeof object> = 3
const d: ValueOf<typeof object> = 4 // error Type '4' is not assignable to type 'ValueOf<{ readonly a: 1; readonly b: 2; readonly c: 3; }>
```


Typescript, 객체의 키와 값 타이핑하기

## Table of Contents

## 불변성

Immutability(이하 불변성)이란, 초기에 할당 한 이후에 더 이상 상태가 변하지 않는 객체를 의미한다. 프로젝트 내의 모든 객체에 이 불변성을 적용하면, 가독성 향상, 코드에 대한 이해도 증가, 스레드의 안정성 등을 확보할 수 있다.

## 불변성을 논하기에 앞서

소프트웨어 아키텍쳐의 전통적인 객체지향 접근법에서, 모든 클래스 인스턴스는 특정 인스턴스에만 연결된 상태를 가질 수 있다. 상태의 초기화는 클래스 생성자에서 발생하며, 클래스 메소드를 호출 할 때 해당 상태에 대한 변경을 적용할 수 있다. 아무리 이러한 상태 값의 변화가 체계적으로 정리되어 있다고 하더라도, 클래스의 상태가 변할 수 있다는 측면은 클래스에 의존하는 코드의 구조에 크게 영향을 미친다.

이러한 상태 값 변이에 따른 단점을 이해하기에 앞서, 두개의 타입의 함수를 먼저 소개하고자한다.

- synchronous(동기): 현태 실행 컨텍스트에서 즉시 실행되어 리턴한다
- asynchronous(비동기) 현재 실행컨텍스트에서 대기하며, 다른 실행 컨텍스트에서 실행되어 값을 가져온다.

코드 실행환경에 따라, 클로져가 비동기 함수가 끝나는 것을 기다리지 않고 호출하며, 그 함수가 상태값을 바꾼다면, 클로져 내부에서의 함수 호출에 대해 신뢰성을 가질 수가 없다. 동기호출에는 이러한 부수효과가 없다. 그러나, 특정 상태를 기반으로 한 호출은, 동기 함수가 내부에서 상태를 변경해버린다면 모두 무효가 되버린다.

두번째로, 불변함수와 변이함수를 구분해야 한다. 불변함수를 호출하는 것은 부수효과를 만들지 않으며, 결과를 리턴한다는 단하나의 효과(effect) 만 가진다. 그러나 변이 함수는 내부에서 상태를 바꿀 수 있는 가능성이 있고, 이는 부수효과를 불러 이르키게 된다.

세번째로, 객체지향 아키텍쳐에서 개발자는 어떤 클래스에서든 getter와 setter를 정의할 수 있다. `getter`는 단순히 상태값을 리턴하는 행위로, 불변함수로 동작한다. 반면에 `setter`는 상태에 값을 부여하므로 변이를 이르키게 된다.

마지막으로, 이러한 모든 개념을 다 통틀어서, 개발자는 코드의 다양한 위치와 다양한 실행 컨텍스트 (스레드, 콜백 모두)에서 변이되는 상태가 만드는 잠재적인 복잡성을 볼 수 있어야 한다. 개발자들이 미래의 복잡함으로 부터 상태를 보호하는 지침을 따르지 않는다면 코드에 대한 디버깅이나 추론이 복잡한 시스템에서 골칫거리로 작용할 수 있다. 이것은 불변성을 적용하는 근본적인 이유, 프로젝트의 원활한 유지보수를 지원하기 위한 의욕을 떨어 뜨릴 수 있다.

## 자바스크립트의 불변성

자바스크립트는 멀티 패러다임 언어이므로, 개발자에게 함수형 사고를 강요하지 않으면서도 함수형 프로그래밍의 측면을 구현할 수 있다. 언어 자체적으로는 앞서 언급한 불변성을 지원하는데, 이를 위해 몇가지 문자열을 붙여야 한다. 불변성을 적용하기 위해서는, 해당 변수나 객체에 명확하게 표현하는 작업을 거쳐야 한다.

### Primitive, wrapper type

자바스크립트에는 몇가지 원시타입 (`boolean` `number` `bigint` `string` `symbol` `null` `undefined`) 이 있다. 이들 모두 메소드가 없다. 따라서 불변의 방식으로 작동하며, 이는 함수로 이들을 전달하는 것이 부수효과를 만들지 않는 다는 것을 의미한다. 대부분의 자바스크립트 개발자가 5가지 wrapper (object)에 대해 잘 알지 못한다. (`Boolean` `Number` `BigInt` `String` `Symbol`) 이는 언어가 원시타입과 래퍼 객체에 상호교환(interchangeable)을 가능하게 해주기 때문이다.

모든 객체 (원시타입이 아닌것, 함수 포함)는 메소드를 포함하므로 값의 변화가 있을 수 있다. 객체는, 그 정의에 따라 프로토타입을 가지고 있으며, 이러한 프로토타입을 바꾸는 것은 객체의 동작을 바꿀 수도 있다.

### 변수 선언

개발자들은 변수를 선언하기 위해서 `let` `const`를 사용해야 한다. 개인적으로 개발자들에게 `let`의 사용을 자제하도록 하게 하는 편이다. `let`은 스코프 내에서 몇번이고 재할당이 이루어져서 문제가 될 수 있기 때문이다. 경험이 많은 개발자들은, 변수의 재 할당을 여러 함수에 나누고, 이를 별도로 리턴하도록 리팩토링 한다.

### 객체 동결

자바스크립트는 객체를 `얕게` 불변하게 만들어주는 함수를 가지고 있다. `얕게`라는 말에 주목하자. 중첩된 객체에서는 이러한 특성이 적용되지 않는다. `Object.freeze` 함수는 말그대로 객체를 동결시켜 주며, 이를 얕게 불변하게 만들어준다.

```javascript
const obj = {
  a: {
    b: 1,
  },
}
Object.freeze(obj)
obj.a = null // 안됨!
obj.b = true // 안됨!
obj.a.b = 2 // 됨?!!
```

`Object.freeze`는 객체의 런타임 수준에서 직접적으로 제한을 건다. 객체를 동결하면, `writable`과 `configurable`가 false로 바뀐다. [이-글](/2020/10/object-freeze-seal-preventExtensions)을 참고하자. 아무튼, 객체를 정말로 깊게 불변하게 만들기 위해서는, 별도로 써드 파티 라이브러리를 사용하거나 스스로 구현해야 한다.

### 함수 속성

함수 또한 객체라는 점에서, 모든 함수 속성은 잠재적으로 변할 수 있는 가능성이 있다. 객체를 함수에 전달하는 것은 메모리 참조에 의해서 일어나고, 전달된 원시타입은 값에 의해 일어난다고 보자. 흥미롭게도(혹은 귀찮게도) 자바스크립트는 함수의 arguments를 재할당 할 수 있도록 해주는데, 이는 클로져 규칙에 따라 함수 범위 밖에서는 영향을 미치지 않는다.

## 타입스크립트의 불변성

타입스크립트는 불변성과 관련되어 놀라운 기능을 제공한다. compile-time 타입 시스템을 활용하여, 엔드 유저에게 전달되는 코드의 양을 줄이고, 런타임 레벨에 대한 제한을 명시할수도 있게 해준다. 타입스크립트는 불변성을 달성하기 위해, `readonly` 속성의 개념을 도입한다.

### `readonly`

`readonly`는 타입과 인터페이스, 클래스 속성과 생성자에 사용할 수 있다.

- `readonly`: https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#readonly-and-const
- `- readonly`

클래스 레벨에서 상수를 정의하면, 객체 오직 단한번, 객체 생성중에만 할당된 변경 불가능한 속성을 정의할 수 있다.

### `readonly`의 사용

타입스크립트는 다음과 같은 방법으로 얕은 불변성을 제공한다.

- `Readonly<T>`: https://www.typescriptlang.org/docs/handbook/utility-types.html#readonlytype
- `ReadonlyArray<T>`: https://www.typescriptlang.org/docs/handbook/2/objects.html#the-readonlyarray-type
- `ReadonlySet<T>`
- `ReadonlyMap<K, V>`

`Object.freeze<T>`가 결과로 `Readonly<T>`를 리턴한다는 사실을 주목하자. 이는 자바스크립트의 `freeze`와 `readonly`사이의 일종의 연결고리다.

### 깊은 불변성

언급했다시피, `readonly`는 깊은 불변성을 제공하지 않으므로 개발자가 써드파티 라이브러리를 쓰거나 직접 구현해야 한다. [ts-essentials](https://github.com/krzkaczor/ts-essentials)에서 제공하는 [DeepReadonly](https://github.com/krzkaczor/ts-essentials#Deep-wrapper-types)를 사용해보자.

## 불변성을 위한 가이드

프로젝트 내부의 객체에 불변성을 적용하는 것은 매우 중요하므로, 프로젝트의 핵심 아키텍쳐 원리에 통합되어야 한다. 물론 소프트웨어 전문가들이 어느정도까지 이러한 패턴을 적용해야 하는지는 많은 논쟁이 있었지만, 대체로 다음과 같은 타입스크립트 개발을 위한 지침을 추천한다.

- `const`로 변수 선언하기
- 컴파일 타입 불변성 사용
- 클래스 인스턴스의 사용을 함수로만 제한
- `Readonly<T>`를 사용하여 불변의 타입으로 선언
- 불변의 유형에서 적절한 서브타입을 추출하여 변이 타입을 사용하되, 이에 대한 사용을 한정 지을 것
- 얕은 불변성은 깊은 불변성을 효과적으로 적용하기 위하여 모든 기능을 제공할 것 (= 얕은 불변성 만으로 깊은 불변성을 달성할 수 있어야 한다)
- 함수는 불변의 파라미터를 받아야 한다.
- 함수는 불변값을 리턴해야 한다.
- 가장 최선의 함수는 순수함수다.

프로젝트 전체 영역에 불변 타입을 선언하면, 개발자들은 개발시에 불변성을 먼저 염두해둘 수 있으며, 필요한 경우 이러한 불변타입의 도움을 얻어 보다 복잡한 타입을 구성할 수도 있다. 시스템의 대부분의 함수는 변경할 수 없는 구조를 수용하고, 이를 만들어 내야 한다. 아래 코드를 참조하자.

```typescript
type Writable<K extends string | number | symbol, V> = {
  -readonly [P in K]: V
}

type ExtractFromReadonlySet<T> = T extends ReadonlySet<infer R> ? R : never
type ExtractFromReadonlyArray<T> = T extends ReadonlyArray<infer R> ? R : never
type ExtractFromReadonlyMap<T> = T extends ReadonlyMap<infer K, infer V>
  ? [K, V]
  : never
```

```typescript
// 얕은 수준의 불변성 타입을 이용하여, 깊은 불변성을 강제한다.
type User = Readonly<{
  id: string
  groups: ReadonlySet<
    Readonly<{
      id: string
      public: boolean
    }>
  >
}>

// ReadonlySet로 부터 타입을 추출한다.
type ExtractFromReadonlySet<T> = T extends ReadonlySet<infer R> ? R : never

// 함수는 불변의 인자를 받는다
// 함수가 불변 타입의 값을 리턴한다.
// 순수함수
const getUserPublicGroupIds = (user: User): User['groups'] => {
  // 변수는 const로 선언되어야 한다.
  const set = new Set<ExtractFromReadonlySet<User['groups']>>()

  Array.from(user.groups).forEach((group) => {
    if (group.public) {
      set.add(group)
    }
  })

  return set
}
```

## 리팩토링

새로운 프로젝트의 경우엔 상관없지만, 오래된 코드베이스의 리팩토링은 숙련된 개발자에게도 문제가 될 수 있으므로 소프트웨어 전문가들이 항상 프로젝트 전반의 변경을 사전에 계획할 필요가 있다.

타입스크립트 프로젝트에 불변성을 강제하는 작업을 하기 위해, 아래와 같은 목록을 작성해보았다.

- 기존 함수의 반환 값을 불변으로 변경하고, 그에 따른 문제 해결
- 기존 함수의 파라미터를 불변으로 변경하고, 그에 따른 문제 해결
- 얕은 복사, 또는 깊은 복사를 통해 불변의 구조로 변경
- 코드 리팩토링 중에 컴파일러가 잠재적으로 모든 버그를 보여줄 것이라 기대하지 말 것
- 광범위한 테스트에 의존

리턴 타입을 불변하게 만드는 것은 리팩토링의 첫번째 단계다. 함수가 불변한 값으로 리턴하기 위해, 아래와 같은 작업을 수행해야 한다.

- 컴파일러를 만족시키기 위해 얕은 복사를 하거나
- 코드를 다른 방향으로 수정

불변값을 얕은 수준의 불변값으로 변경하는 것은 자바스크립트의 표준 라이브러리에 이미 정의된 방법으로 구현할 수 있다.

- 객체: `Object.assign({}, obj)` `{...obj}`
- 배열: `arr.slice()`, `[...arr]`

리팩토링전

```typescript
type User = {
  id: string
  groupIds: string[]
}

const mutableAppendGroupsToUser = (groupIds: string[], user: User): User => {
  user.groupIds = Array.from(new Set([...user.groupIds, ...groups]))

  return user
}
```

리팩토링후

```typescript
type ReadonlyUser = Readonly<{
  id: string
  groupIds: ReadonlyArray<string>
}>

// 이제 함수는 오직 불변 타입만 받는다.
const immutableAppendGroupsToUser = (
  groupIds: ReadonlyArray<string>,
  user: ReadonlyUser,
): ReadonlyUser => {
  // 더 이상 `user.groupIds`를 직접 수정하지 않는다.
  const newGroupIds = Array.from(new Set([...user.groupIds, ...groupIds]))

  // 함수가 완전히 새로운 객체를 리턴한다.
  return Object.assign({}, user, { groupIds: newGroupIds })
}
```

개발자들이 큰 객체에 대한 깊은 복사를 할 때 성능상의 문제를 조심해야 한다. 또한 불변성을 도입하면, 컴파일러의 도움이 있던 없던 간에 이전부터 있었던 버그가 수면위로 떠오르는 일이 나타날 수 있다. 어떤 프로젝트던지, 합리적인 테스트를 거쳐야만 최종 사용자에게 훌륭한 경험을 보장해준다.

> https://levelup.gitconnected.com/the-complete-guide-to-immutability-in-typescript-99154f859fdb


저는 사실 Immutability에 안 좋은 추억이 있습니다

Typescript의 Immutability

## Table of Contents

## any

타입스크립트에서 얼마나 타입을 잘 지키는지는, `any`를 얼마나 사용하느냐에 달려 있다고 봐도 될 것 같다. 그러나 불가피하게 `any`가 사용되는 경우도 있다. `JSON.parse`가 그 중 하나다. 이 메소드는, 리턴타입을 추론 할 수 없기 때문에 `any`로 리턴을 한다.

```typescript
JSON.parse('{hello: world}')
// (method) JSON.parse(text: string, reviver?: ((this: any, key: string, value: any) => any) | undefined): any
```

`any`의 유혹은 강력하다. 그냥 뭐든지 넘겨주기 때문이다.

```typescript
function testNumber(num: number) {
  return num + 1
}

const num: any = 'eleven' // any 라서 number만 넘길 수 있었는데 무시되었다.
testNumber(num)
```

따라서 `any`의 사용은 최소화 하는 것이 좋다. 타입을 아직 알 수 없을 때는, `any`대신 `unknown`을 쓰는게 좋다.

## Type Assertion

`type assertion`은 엄밀히 말해서 `cast`와는 다르다. 타입스크립트에서 `type assertion`이란 `x as number`와 같은 형태를 의미한다. 타입이 있는 다른언어 (C, Java등) 에서 `cast`는 런타임에 영향을 미친다. 예를 들어, `(int)f`가 있다면 float이 런타임 중에 int로 바뀌게 된다. [그러나 타입스크립트는 런타임시에 타입을 제거하기 때문에](http://neugierig.org/software/blog/2016/04/typescript-types.html) 실제로 아무런 영향을 미치지 않는다.

```typescript
const strOrNum = Math.random() ? '42' : 42
const num = strOrNum as number
```

을 컴파일하면 별 차이가 없다.

```javascript
'use strict'
const strOrNum = Math.random() ? '42' : 42
const num = strOrNum
```

따라서 `type assertion`이란 타입으로 캐스팅을 하는게 아니고, 그냥 그게 이 타입이라고 주장하는 것이다. (그래서 `assertion`이기도 하구)

```typescript
function testNumber(num: number) {
  return num + 1
}

const num = Math.random() ? 'eleven' : 11
testNumber(num as number) // 반반쯤의 확률로 에러가 난다.
```

이러한 `as`의 사용은 api 호출에서도 자주 보인다.

```typescript
const response = await fetch('/api/user')
const result = (await response.json()) as UserInterface
```

이러한 경우에는, [타입 가드](https://basarat.gitbook.io/typescript/type-system/typeguard)를 써서 막는 것이 좋다.

```typescript
function isUser(data: unknown): data is UserInterface {
  return data && typeof data === 'objet' && 'name' in data // ...
}
const response = await fetch('/api/user')
const result = await response.json()

if (!isUser(result)) {
  throw new Error(`${result}는 UserInterface가 아니예욧`)
}
```

조금더 빡세게(?) 타입가드를 하고 싶다면, [Zod](https://github.com/colinhacks/zod)와 같은 도구를 사용해보는 것도 좋다. 혹은 [typescript-json-schema](https://github.com/YousefED/typescript-json-schema)로 JSON schema에서 타입을 뽑아낸 다음에 검사하는 방법도 있을 수 있다.

## 객체와 배열 lookup

타입스크립트는 배열을 참조할 때 별다른 처리를 하지 않기 때문에, 에러가 날 수 있다.

```typescript
const l = [1, 2, 3]
const item = l[3]
item + 1 // error 지만, 컴파일시에는 모른다.
```

```typescript
const user: { [key: string]: string } = { name: 'kyc' }
user.age + 1 // error 지만, 컴파일 시에는 모른다.
```

왜 타입스크립트가 가만 뒀을까? 아마도 이러한 상황은 매우 자주 있는 일이고, 이것이 유효한지 체크하는 것이 꽤 어려운일이어서 그런걸수도 있다. 근데, 이를 체크하는 방법이 있다. 바로 [noUncheckedIndexedAccess](https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess)다.

```typescript
const l = [1, 2, 3]
const item1 = l[3]
const item2 = l[2]
item1 + 1 // Object is possibly 'undefined'.(2532)
item2 + 1 // 근데 문제는 이거까지 에러가 난다는 거다.

l.map((item) => item + 1) // 이런건 괜찮다.
```

[확인해보기](https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true#code/MYewdgzgLgBANjAvDA2gRgDQwExYMwC6AsAFCiSwCWUApgLZpLwqGnnQzX3ZNwrbESXBjADUMRqWE9xaIA)

위에서 보이는 것 처럼, `noUncheckedIndexedAccess`는 적당히 경고를 날려주는 장점도 있지만, 그다지 똑똑하지 않다는 단점도 있다.

결론적으로, 객체나 리스트를 lookup 할때는 undefined가 있을 가능성에 대해서 염두해 두어야 한다.

## 부정확한 타입 정의

자바스크립트의 라이브러리에 타입선언을 집어넣는 것은 일종의 거대한 `type assertion`이다. 그들의 라이브러리가 이렇게 정적으로 모델링 했다고 주장하는 거지만, 이를 보장하는 것은 아무것도 없다. (물론 이는 라이브러리가 타입스크립트로 작성되지 않았다는 것에 한해서다. 타입스크립트로 작성되지 않고, 타입만 있다면 이런일이 발생할 수 있다.)

예를 들면 2년째 고쳐지지 않는 [잘못된 타이핑](https://github.com/alex3165/react-mapbox-gl/issues/776) 이라던가...

이런 문제를 해결하는 가장 좋은 방법은, 직접 버그를 고치는 것이다. 직접 [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped)에 쳐들어가서 고치면 된다. 이게 좀 부담되는 나와 같은 ISTJ 들에겐 [augmentation](https://www.typescriptlang.org/docs/handbook/declaration-merging.html) 이나, 최악의 옵션으로 type assertion을 활용하는 방법도 있다.

물론, 몇몇 함수는 이렇게 타입을 선언하기가 굉장히 어렵다는 것도 이해해줘야 한다. [String.prototype.replace](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_function_as_a_parameter)의 파라미터를 잠깐 보자. [Object.assign](https://github.com/microsoft/TypeScript/pull/28553#issuecomment-440004598)의 경우엔, 피치못할 사정으로 인해 잘못된 타이핑이 된 경우도 있었다.

## variance and arrays

[typescript github의 이 이슈](https://github.com/microsoft/TypeScript/issues/9825#issuecomment-234115900)를 살펴보자.

```typescript
function addDogOrCat(arr: Animal[]) {
  arr.push(Math.random() > 0.5 ? new Dog() : new Cat())
}

const z: Cat[] = [new Cat()]
addDogOrCat(z) // 개가 들어갈 수도 있다.
```

이러한 짓을 방지하려면 어떻게 해야할까? `readonly`를 쓰는 방법이 있을 수 있다.

```typescript
function addDogOrCat(arr: readonly Animal[]) {
  arr.push(Math.random() > 0.5 ? new Dog() : new Cat())
  //  Property 'push' does not exist on type 'readonly Animal[]'.
}
```

아니면, `push` 대신 이렇게 하거나.

```typescript
function dogOrCat(): Animal {
  return Math.random() > 0.5 ? new Dog() : new Cat()
}

const z: Cat[] = [new Cat(), dogOrCat()]
```

관련해서 읽어볼만 한 좋은 글: https://iamssen.medium.com/typescript-%EC%97%90%EC%84%9C%EC%9D%98-%EA%B3%B5%EB%B3%80%EC%84%B1%EA%B3%BC-%EB%B0%98%EA%B3%B5%EB%B3%80%EC%84%B1-strictfunctiontypes-a82400e67f2

## 함수 호출에 따른 부작용

```javascript
interface UserInterface {
  name: string
  age?: number
}

function userProcessor(user: UserInterface, processor: (user: UserInterface) => void) {
  if (user.age) {
    processor(user)
    document.body.innerHTML = `${user.age + 1}`
  }
}
```

만약 `processor`에서 이런짓을 하면 어떻게 될까?

```typescript
userProcessor({ name: 'kyc', age: 15 }, (u) => delete u.age)
// 타입 체크는 성공하지만, 에러가 날거다.
```

물론 만일을 위해서 `if`처리가 추가되었지만, `processor`에서 이를 무효화 했다. 타입스크립트는 저 함수에서 무슨짓을 할지 모르기 때문에, 어찌보면 당연한 것이다.

자바스크립트에서 파라미터를 조작하는 일은 흔치 않고 또한 안티패턴이기 때문에, 타입스크립트에서는 이러한 동작을 허용해 뒀을 것이다.

이를 수정해두는 방법은, 역시 `readonly`를 사용하는 것이 있다.

```typescript
function userProcessor(
  user: UserInterface,
  processor: (user: Readonly<UserInterface>) => void,
) {
  if (user.age) {
    processor(user)
    document.body.innerHTML = `${user.age + 1}`
  }
}

userProcessor({ name: 'kyc', age: 15 }, (u) => delete u.age)
// The operand of a 'delete' operator cannot be a read-only property.
```

> Readonly는 얕은 비교만 하기 때문에, [ts-essentials](https://github.com/krzkaczor/ts-essentials)를 사용해야 깊은 비교를 할 수 있다.

당연하게도, 가장 좋은 방법은 객체의 처리를 객체가 정의된 이후에 하는 것이다.

```typescript
function processFact(
  user: UserInterface,
  processor: (user: UserInterface) => void,
) {
  const { age } = user
  if (age) {
    processor(user)
    document.body.innerHTML = `${age + 1}` // safe
  }
}
```

## Further reading

- https://frenchy64.github.io/2018/04/07/unsoundness-in-untyped-types.html
- https://www.typescriptlang.org/docs/handbook/type-compatibility.html#a-note-on-soundness
- https://www.typescriptlang.org/play?strictFunctionTypes=false&q=209#example/soundness


타입스크립트에서 조심해야할 습관

타입스크립트를 배우고, 본격적으로 사용하면서 부딪히는 가장 최초의 어려움은 바로 이 에러가 아닐 까 싶다.

```bash
Element implicitly has an 'any' type because type '{}' has no index signature.
```

- https://www.typescriptlang.org/tsconfig#suppressImplicitAnyIndexErrors
- https://www.typescriptlang.org/tsconfig#noImplicitAny

보통 이런 에러는 아래와 같은 코드에서 나타난다.

```typescript
for (const [key, value] of Object.entries(obj)) {
  ///...
}
```

`Object.entries` 는 아마도 다음과 같이 타이핑이 되어 있을 것이다.

```typescript
entries(o: {}): [string, any][];
```

```typescript
const test = { a: 'a', b: 'b', c: 'c' }
for (const [k, v] of Object.entries(test)) {
  const value = test[k] // Element implicitly has an 'any' type because index expression is not of type 'number'.ts(7015)
}
```

`k` 객체의 키로 `v`를 추정할 수 없기 때문에 발생하는 문제다.

이럴 때는 아래와 같이 작업해보자.

## 방법 1.

```typescript
type testKey = 'a' | 'b' | 'c'

const test: { [key in testKey]: string } = { a: 'a', b: 'b', c: 'c' }
for (const [k, v] of Object.entries(test)) {
  const value = test[k as testKey]
  console.log(k === v)
}
```

object의 key의 타입을 추론한다음, 이를 설정하는 방법이다.

## 방법 2.

```typescript
function entries<O extends Object>(obj: O): Array<[keyof O, any]> {
  return Object.entries(obj) as Array<[keyof O, any]>
}

for (const [k, v] of entries(test)) {
  const value = test[k]
  console.log(k === v)
}
```

느슨하게 타이핑되어 있는 `Object.entries`를 강력하게 `test` 객체의 형태에 맞 맞춰 타이핑한다.


Don’t give up and use suppressImplicitAnyIndexErrors 이 멋있어서 배껴봄

suppressImplicitAnyIndexErrors 옵션을 키기 전에

블로그를 또 개편했다. 개편한지 1년도 안된거 같은데 화끈하게 바꿨다.

## Table of Contents

## 1. 계기

1. 관리 능력 부재로 박살난 라이트 하우스 점수
   - 그냥 가끔씩 생각날 때 마다 보던 점수였는데, 지난 번 포스팅에서 점수가 박살난 것을 보고 매우 반성. 원인은 이런저런 실험을 하다가 삽질을 한 것.
2. 보다 보니 질리는 디자인
   - 단순함이 최고라고는 하지만, 지나치게 단순했던 것 같다. 특히 태그 목록페이지는 눈뜨고 보기 어려울 정도. 그리고 다크 모드 지원도 해보고 싶었다.
3. 코드 리팩토링
   - 그 때는 나름 최선이었던 것 같지만(?) 더 이상 최선이 아닌 코드들을 리팩토링
4. styled component 를 활용한 구성의 한계
   - 디자인 고자라서 내가 아무리 css로 춤춰도 한계가 있었다. 그래서 그냥 tailwindcss를 도입하기로 했다.

## 2. 바꾼점

### tailwindcss

외국 친구들 프론트엔드 이야기를 볼 때마다 가끔씩 눈에 밟히던게 있었는데 바로 [tailwindcss](https://tailwindcss.com/) 다. 클래스를 활용해서 css를 편하게 잡아줄 수 있도록 도와주는 라이브러리인데, 나 같은 디자인 고자에게 꼭 필요한 라이브러리였다. 다만 className이 장황해진다는 점, 그리고 더더욱 css를 공부할 의지가 사라진다는 점에서 좋지 않았다. (css공부를 위해 완벽 가이드를 구매했다. 이번에는 반드시)

### mdx

이것도 외국 블로그들을 돌아다니면서 알게 된 것인데, 마크다운 문서를 파싱하는 툴로 [mdx](https://mdxjs.com/)를 많이 사용한다는 것을 알게 됐다. 기존에 내 블로그는 `remark`와 `rehype`를 unify 하여 string으로 강제로 떨궈주는 방식이 었는데, 이 때문에 부득이하게 `dangerouslysetinnerhtml`를 사용했다. 물론 나밖에 안쓰는 곳이라 보안 위험 따윈 없겠지만,,, mdx를 사용하면 string이 아닌 jsx로 바꿔주기 때문에 리액트에서 사용하기엔 안성맞춤이다.

nextjs에서 사용을 위해서 mdx를 직접 사용하지는 않고, [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote)를 사용했다. 간단하게 원리를 설명하면 `getStaticProps`에서 `renderToString`를 활용하여 해당 주소별 내용을 string으로 들고 있다가 요청이 오면 이를 `hydrate`를 활용하여 jsx로 렌더링하는 방식이다. 덕분에 깔끔하게 처리할 수 있었고, 나아가 단순히 img 태그로 변환하던 이미지들도 `next/image`를 활용할 수 있도록 커스터마이징을 거쳤다.

https://github.com/yceffort/yceffort-blog-v2/blob/c19b26d17671baa4e0a7987402c9a5bfa0d6a85c/src/utils/Markdown.ts#L47-L131

`next/image` 덕분에 이미지 최적화와 lazy loading도 쉽게 가능해졌다. (next 도덕책,,,,)

이런 커스터마이징 덕분에 빌드 타임시에 잘못된 내부 이미지 링크도 수정이 가능해졌다. 추가로 내가 디자인을 바꾸고 싶은 마크다운 요소가 있다면 컴포넌트를 집어넣어서 디자인 변경도 가능하다. string으로 변환해서 꽂을 때와 비교하면 많은 것이 달라졌다.

### next-seo, next-themes

SEO 지원을 위해 [next-seo](https://github.com/garmeeh/next-seo)를, 다크모드 지원을 위해 [next-themes](https://github.com/pacocoursey/next-themes)를 사용했다.

### 그 외 리팩토링

현재 블로그 포스트에 두가지 주소 체계가 존재한다.

- (과거) `/:year/:month/:day/:title`
- (현재) `/:year/:month/:title`

현재 설정 건드리기 귀찮아서 nextjs에서 제공하는 디렉토리 라우팅을 사용하고 있는데, 이 두 주소 지원을 위해서 미련하게도 거의 비슷한 비즈니스 로직이 들어 있는 두가지 파일을 별개로 관리하고 있었다. 이를 `/:year/[...slug].tsx`로 바꿔서 하나의 라우팅에서 모두 처리가 가능하도록 변경했다.

그리고 그 외에 미뤄뒀던 코드 리팩토링도 거쳤는데, 사실 다 한 것 같진 않다. 여전히 귀찮아서 생략한 타이핑도 존재하기 때문에,, 아,, 언제 하지?

## 3. 결과

디자인도 바꼈고, 라이트 하우스느님의 심기를 거슬리는 부분도 많이 줄였다. 아쉬운 점은 디자인과 파서 외에는 급진적인 변화를 거치지 못했다는 것이다. rescript를 써보고 싶었지만(?) 그걸 갖다 쓸 만큼 실력이 되지 못했고, 그 외에 크게 이목을 끌 만한 기술도 접하지 못했다.

과연 이 객기의 끝은 어디일까. 또 무엇을 만족하지 못하고 바꿀 것인가,, 내년 이맘 때를 지켜보자.


아무도 보지 않는 블로그를 갈아 엎는 사람이 있다?

Typescript 2

Typescript, 객체의 키와 값 타이핑하기

Typescript의 Immutability

타입스크립트에서 조심해야할 습관

suppressImplicitAnyIndexErrors 옵션을 키기 전에

블로그 4.0 업데이트!