타입스크립트 컴파일러는 어떻게 동작하는가?

## Table of Contents

## 무엇이 문제인가?

리액트 개발을 어느정도 하다보면, 리렌더링을 거치는 과정에서 함수를 고정시키기 매우 어렵다는 것을 알 수 있다. 아래 예제를 살펴보자.

```jsx
function Chat() {
  const [text, setText] = useState('')

  const onButtonClick = () => {
    console.log(text)
  }

  return (
    <>
      <input value={text} onChange={(e) => setText(e.target.value)} />
      <button onClick={onButtonClick}>버튼</button>
    </>
  )
}
```

`setState`는 리액트 컴포넌트의 리렌더링을 야기하므로, `input`의 값을 바꿀 때 마다 `onButtonClick` 함수는 새로 생성될 필요가 없는 함수임에도 불구하고 `setText`가 일어날 때 마다 새로 생성 될 것이다.

![useEvent-1](./images/useEvent-1.png)

![useEvent-2](./images/useEvent-2.png)

![useEvent-3](./images/useEvent-3.png)

위 스크린샷은 input에 두번씩 타이핑을 하면서 크롬에서 메모리 스냅샷을 촬영한 화면인데, 매번 `onButtonClick` 함수가 가리키는 메모리 주소가 달라지는 것을 볼 수 있다.

이를 해결하기 위해서 쓰는 방법 중 하나는 바로 `useCallback`이다.

```jsx
function Chat() {
  const [text, setText] = useState('')
  const [clicked, setClicked] = useState(false)

  const onButtonClick = useCallback(
    function onButtonClickCallback() {
      console.log(text)
    },
    [text],
  )

  return (
    <>
      <input value={text} onChange={(e) => setText(e.target.value)} />
      <button onClick={onButtonClick}>버튼</button>
      <button onClick={() => setClicked((prev) => !prev)}>
        {clicked ? '클릭함' : '안함'}
      </button>
    </>
  )
}
```

`useCallback`을 사용하고, deps로 `text`를 추가하는 방법을 고려해볼 수 있다. 그러나 이 경우에도 마찬가지로 `text`가 바뀔 때 마다 새로운 함수가 생성된다는 사실에는 변함이 없다.

![useEvent-4](./images/useEvent-4.png)

> 다른 state 변경으로는 함수가 재생성되지 않고 고정되지만, 여전히 deps에 의존하고 있는 값이 수정되면 다시 생성된다는 것에는 변함이 없다.

그렇다고 deps를 제거하면, 저 핸들러는 항상 최초의 `text`값만 보게 될 것이다. 이러한 문제를 해결하기 위해 나온 것이 `useEvent`다.

## useEvent

> 주의: 2022-05-12 기준으로 `useEvent`는 아직 사용할 수가 없는 상태다. 순전히 RFC를 기준으로 작성된 글이라는 걸 염두해두길 바란다.

```javascript
function Chat() {
  const [text, setText] = useState('')

  // text가 변경되도 항상 같은 함수임
  const onClick = useEvent(() => {
    sendMessage(text)
  })

  return <SendButton onClick={onClick} />
}
```

`useEvent`의 중요한 특징 두가지는 다음과 같다.

- `deps`가 없음
- state인 `text`가 변경되도 함수를 재생성하지 않고 하나의 안정된 함수만을 사용하게 됨.
- 그럼에도 불구하고 항상 최신의 `text`를 바라볼 수 있음.
- 따라서, `Memoize`된 `<SendButton />`의 리렌더링을 막을 수 있음.

## `useEvent`를 사용하면 이벤트 핸들러가 변경되도 `useEffect`는 다시 호출되지 않는다.

```jsx
function Chat({ selectedRoom }) {
  const [muted, setMuted] = useState(false)
  const theme = useContext(ThemeContext)

  useEffect(() => {
    const socket = createSocket('/chat/' + selectedRoom)
    socket.on('connected', async () => {
      await checkConnection(selectedRoom)
      showToast(theme, 'Connected to ' + selectedRoom)
    })
    socket.on('message', (message) => {
      showToast(theme, 'New message: ' + message)
      if (!muted) {
        playSound()
      }
    })
    socket.connect()
    return () => socket.dispose()
  }, [selectedRoom, theme, muted]) // 이 deps 중 하나만 변경되도 다시 실행됨.
  // ...
}
```

위 컴포넌트의 문제는, `theme`이나 `muted`가 바뀌게 되면 `useEffect`가 다시금 실행된다는 것이다. `theme`과 `muted`는 `effect`안에 있으므로 이를 의존성에 선언해 주어야 하고, 이것이 바뀌면 다시 실행되는 구조를 가지게 된다.

물론 `deps`에서 제거하는 방식도 고려할 수 있다. 그러나 이 경우 `eslint-disable-line react-hooks/exhaustive-deps`를 사용해줘야 하며 (얼마나 자주 썼던지 다 외웠다.), 이를 잘못 쓸 경우 예기치 않은 오류를 만들어 낼 수 있는 위험을 감수해야 한다. (이경우 `theme`이 다크모드 등으로 변경되어도 새로운 `toast`를 그리지 못하게 될 것이다.)

다른 방법으로 `useCallback`을 사용하는 것도 있지만, 역시나 앞서 언급했던 것 처럼 `theme` `muted`가 바뀌면 함수의 identity가 변경된다는 사실에는 변함이 없다.

```jsx
function Chat({ selectedRoom }) {
  const [muted, setMuted] = useState(false);
  const theme = useContext(ThemeContext);

  // ✅ 재생성되지 않음
  const onConnected = useEvent(connectedRoom => {
    showToast(theme, 'Connected to ' + connectedRoom);
  });

  // ✅ 재생성되지 않음
  const onMessage = useEvent(message => {
    showToast(theme, 'New message: ' + message);
    if (!muted) {
      playSound();
    }
  });

  useEffect(() => {
    const socket = createSocket('/chat/' + selectedRoom);
    socket.on('connected', async () => {
      await checkConnection(selectedRoom);
      onConnected(selectedRoom);
    });
    socket.on('message', onMessage);
    socket.connect();
    return () => socket.disconnect();
  }, [selectedRoom]); // ✅ 룸이 변경될 때만 실행됨
```

`useEvent`를 사용하여 `onConnected`와 `onMessage`를 분리했다. 이렇게 함으로써, 앞서서 예상되었던 이슈들을 모두 해결할 수 있게 되었다. `useEvent`로 값들을 내재화하여 `useEffect`의 `deps`에서 제거할 수 있게 되었고, 함수도 재생성되지 않고 안정적인 값을 가질 수 있게 되었다. 그리고 여전히, `selectedRoom`에 의존함으로서 우리가 기존에 구현하고 싶었던 기능을 안정적으로 제공할 수 있게 되었다.

```jsx
const onConnected = useEvent((connectedRoom) => {
  console.log(selectedRoom) // 이미 useState를 거쳐서 업데이트 된 값
  showToast(theme, 'Connected to ' + connectedRoom) // 이벤트를 발생시킨 값
})
```

`useEvent`의 `props`로는 이 이벤트를 발생시킨 값을 받을 수 있다.

```jsx
function Chat({ selectedRoom }) {
  const [muted, setMuted] = useState(false)
  const theme = useContext(ThemeContext)

  const onConnected = (connectedRoom) => {
    showToast(theme, 'Connected to ' + connectedRoom)
  }

  const onMessage = (message) => {
    showToast(theme, 'New message: ' + message)
    if (!muted) {
      playSound()
    }
  }

  useRoom(selectedRoom, { onConnected, onMessage })
  // ...
}

function useRoom(room, events) {
  const onConnected = useEvent(events.onConnected) // ✅ Stable identity
  const onMessage = useEvent(events.onMessage) // ✅ Stable identity

  useEffect(() => {
    const socket = createSocket(room)
    socket.on('connected', async () => {
      await checkConnection(room)
      onConnected(room)
    })
    socket.on('message', onMessage)
    socket.connect()
    return () => socket.disconnect()
  }, [room]) // ✅ Re-runs only when the room changes
}
```

또 사용하는 곳에서 `useEvent`를 사용하여 wrapping하는 전략을 취할 수도 있다.

`useEvent`가 사용될 수 있는 또다른 예시를 살펴보자. 특정 페이지에 진입했을 때 로깅하는 컴포넌트를 구현한다고 가정해보자.

```jsx
function Page({ route, currentUser }) {
  useEffect(() => {
    logAnalytics('visit_page', route.url, currentUser.name)
  }, [route.url, currentUser.name])
  // ...
}
```

이는 얼핏보면 잘 작동하는 것 처럼 보인다. 그러나 사용자가 이름을 바꾸면 어떻게 될까? 사용자는 단순히 이름만 바꿨는데, 다른 사용자로 인식되어 (=`useEffect`가 실행되어) 다시 한번 로깅을 할 것이다.

```jsx
function Page({ route, currentUser }) {
  // ✅ Stable identity
  const onVisit = useEvent((visitedUrl) => {
    logAnalytics('visit_page', visitedUrl, currentUser.name)
  })

  useEffect(() => {
    onVisit(route.url)
  }, [route.url]) // ✅ Re-runs only on route change
  // ...
}
```

`useEvent`가 이러한 문제의 해결책이 될 수 있다. `onVisit` 의 props로 주소를 받으면, `currentUser.name`이 변경되었는지 상관없이 우리가 원하던 대로 로깅을 할 수 있게 된다.

## 어떻게 구현되어 있을까?

`useEvent`의 대략적인 구현으로는 아래와 같이 설명하고 있다.

```jsx
// 대략적인 동작
function useEvent(handler) {
  const handlerRef = useRef(null)

  // 실제 구현에서는, layout effect 보다도 먼저 실행된다.
  // 하지만 정확히 언제 실행될지는 아직 개발중
  useLayoutEffect(() => {
    handlerRef.current = handler
  })

  return useCallback((...args) => {
    // 실제 구현에서는, 렌더링중 호출되면 에러를 발생 시킬 것이다.
    // 즉 렌더링 중에는 이 함수는 처리되지 않아야 한다는 것을 의미한다.
    // 렌덜이 중에 함수가 호출되지 않게 함으로써 이들의 identity를 안전하게 가져갈 수 있또록 한다.
    // 렌더링 중에는 호출할 수 없으므로, 렌더링에 영향을 주지 않고, input이 변경된더라도 변경할 필요가 없다.
    const fn = handlerRef.current
    return fn(...args)
  }, [])
}
```

이와 비슷한 코드가 존재한다.

```typescript
import { useLayoutEffect, useMemo, useRef } from 'react'

type Fn<ARGS extends any[], R> = (...args: ARGS) => R

const useEventCallback = <A extends any[], R>(fn: Fn<A, R>): Fn<A, R> => {
  let ref = useRef<Fn<A, R>>(fn)
  useLayoutEffect(() => {
    ref.current = fn
  })
  return useMemo(
    () =>
      (...args: A): R => {
        const { current } = ref
        return current(...args)
      },
    [],
  )
}

export default useEventCallback
```

[https://github.com/Volune/use-event-callback/blob/master/src/index.ts](https://github.com/Volune/use-event-callback/blob/master/src/index.ts)

위 설명에서 언급했던 내용을 거의 유사하게 구현해 두었다.

## 느낀점

- 일단 RFC 이기 때문에 이런게 있을 수도 있다 정도로 알아두면 될 것 같다. 그러나 여기저기 홍보하는 걸로 봐서는 이른 시일내에 추가될 듯
- 트위터에서 이것도 염탐하다가 공감하게 된 사실인데, 확실히 리액트는 어려워 지고 있는 것 같다. 초보자들에게 친화적인 프레임워크 라고 보기 어렵지 않을까 싶다. 물론 리렌더링이고 뭐고 간에 다 생각 안하고 만든다면 상관없지만
- 리액트를 정확하게 이해하기 위해서는 자바스크립트의 기초를 정말정말 잘 이해헤야할 것 같다.
- vue, svelte 등은 이런 문제를 어떻게 해결하고 있을까? 너무 react-way로만 길들여져 있어서 다른 프레임워크는 어떻게 처리하고 있는지 궁금하다. 리액트의 어려움을 토로하는 트위터 쓰레드를 보면, 간간히 vue 광고하시는 분들도 있다. vue는 정마라 이런 문제가 없는 것인가...


리액트의 새로운 훅, useEvent

### 제네릭 활용하기

테이블 컴포넌트가 있고, 여기에 props를 할당해서 그린다고 생각해보면, 보통은 이런 코드가 나올 것이다.

```tsx
import React from 'react'

interface Props {
  items: Array<{ id: string }>
  renderItem: (item: { id: string }) => React.ReactNode
}

export const Table = (props: Props) => {
  return null
}

export const Component = () => {
  return (
    <Table
      items={[{ id: '1' }]}
      renderItem={(item) => {
        return null
      }}
    />
  )
}
```

하지만 이런 구조는 `{id: string}` 으로 고정되어 있어,여러가지 종류의 props를 그리기에는 무리가 있다. 이럴 때 사용하면 좋은 것이 Generic이다. Generic은 타입, 인터페이스 등에서 외부에서 정의된, 공통의 속성을 사용하고 싶을 때 유용하다.

```tsx
import React from 'react'

interface Props<TItem> {
  items: Array<TItem>
  renderItem: (item: TItem) => React.ReactNode
}

export const Table = <TItem,>(props: Props<TItem>) => {
  return null
}

export const Component = () => {
  return (
    <>
      <Table
        items={[{ id: '1' }]}
        // item이 {id: "1"}로 추론되는 것을 볼 수 있다.
        renderItem={(item) => {
          return null
        }}
      />
      <Table
        items={[{ id: '1', name: 'yceffort' }]}
        // 서로 다른 props가 와도 문제 없다.
        renderItem={(item) => {
          return null
        }}
      />
    </>
  )
}
```

이렇게 props와 interface내에서 사용하는 것 뿐 만 아니라, 타입을 아직 알 수 없는 객체 등을 다룰 때도 유용하다.

```ts
export const getDeepValue = (obj: any, firstKey: string, secondKey: string) => {
  return obj[firstKey][secondKey]
}

const obj = {
  foo: {
    a: true,
    b: 2,
  },
  bar: {
    c: '12',
    d: 18,
  },
}

const value = getDeepValue(obj, 'foo', 'a')

// value any
```

어떠한 객체의 키로 특정한 값을 가져온다고 생각해보자. 객체의 형태를 당장 알 수 없으므로 `any`를 두고, 키는 string으로 두었다. `any`를 쓰는 것은 타입스크립트에서 최대한 자제해야하는 행위다.

이것을 해결하기 위해, 마찬가지로 Generic을 사용할 수 있다.

```typescript
export const getDeepValue = <
  TObj,
  TFirstKeyOfObj extends keyof TObj,
  TSecondKeyOfObj extends keyof TObj[TFirstKeyOfObj],
>(
  obj: TObj,
  firstKey: TFirstKeyOfObj,
  secondKey: TSecondKeyOfObj,
) => {
  return obj[firstKey][secondKey]
}

const obj = {
  foo: {
    a: true,
    b: 2,
  },
  bar: {
    c: '12',
    d: 18,
  },
}

const value = getDeepValue(obj, 'foo', 'a')
// value number
```

`extends`을 활용하면 기존의 제네릭을 상속 받아 또 다른 제네릭을 만들 수 있다. `TFirstKeyOfObj`는 `keyof TObj`, 즉 `TObj`의 키를 상속받아 만들었고, `TSecondKeyOfObj`는 `TObj[TFirstKeyOfObj]`의 키를 상속받아 만든 제네릭이다. 처음보기엔 무언가 복잡해보이지만, 차분하게 읽어보면 별거 없다는 것을 알 수 있다.

### 조건부 타입

타입도 다른 변수들이나 표현과 마찬가지로 조건부로 만들 수 있다.

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

type Human = {
  firstName: string
  lastName: string
}

type GetRequiredInformation<TType> = any

export type RequiredInformationForAnimal = GetRequiredInformation<Animal>

export type RequiredInformationForHuman = GetRequiredInformation<Human>
```

`GetRequiredInformation`에서 받은 제네릭 `TTYpe`이 `Animal`인지, `Human`인지 확인하여 새로운 타입을 extends할 수 있는 타입을 만들어보자.

```typescript
type GetRequiredInformation<TType> = TType extends Animal
  ? { age: number }
  : { salary: number }
```

`extends`를 사용하면 단순히 상속하는 것 뿐만 아니라, 마치 조건문으로 사용해서 상속할 수 있는지 여부도 확인할 수 있다. 이에 따라 타입별로 원하는 추가 타입을 선언해 줄 수 있다.

추가로, `GetRequiredInformation`에 `Animal` `Human`외에 다른 것이 오는 것을 막고 싶다면, 아래와 같이 `never`를 사용하면 된다.

```typescript
type GetRequiredInformation<TType> = TType extends Animal
  ? { age: number }
  : TType extends Human
  ? { salary: number }
  : never
```

[과거 글](/2022/03/understanding-typescript-never#왜-never가-필요한가)에서 이야기 했던 것처럼, 그 어떤 것도 사용할 수 없는 불가능한 타입, bottom type을 만들고 싶을 때 `never`를 사용한다.

이러한 방식을 조금더 응용하면, 내가 타입스크립트 컴파일러에 사용할 수 있는 에러도 만들 수 있다.

```typescript
export function deepEqualCompare(a: any, b: any) {
  if (Array.isArray(a) || Array.isArray(b)) {
    throw new Error('배열은 비교할 수 없습니다.')
  }
  return a === b
}
```

```typescript
export function deepEqualCompare<Arg>(a: Arg extends any ? "배열은 비교할 수 없습니다", b: Arg) {
  if (Array.isArray(a) || Array.isArray(b)) {
    throw new Error("배열은 비교할 수 없습니다.")
  }
  return a === b
}

deepEqualCompare([1, 2, 3], [1]) // Argument of type 'number[]' is not assignable to parameter of type '"배열은 비교할 수 없습니다."'.(2345)
```

그러나, 이러한 코드가 동작해버리는 참사가 발생버리기 때문에, `never`를 쓰는 것이 좋다.

```typescript
deepEqualCompare('배열은 비교할 수 없습니다.', '배열은 비교할 수 없습니다.') // ????
// 물론 코드가 잘못된 것은 아니지만, 우리가 원하는 바는 이게 아닐 것이다.
```

### 타입스크립트의 타입을 공부할 때 도움이 되는 것들

- [ts-belt](https://github.com/millsp/ts-toolbelt): 타입스크립트에서 유용하게 사용할 수 있는 다양탄 유틸리티 라이브러리를 제공한다. 찾아보면 별에 별 유틸리티 타입들을 다 제공하는데, 이를 어떻게 만들었을지 상상해 보는 재미가 있다.
- [zod](https://github.com/colinhacks/zod): [joi](https://github.com/sideway/jo)의 타입스크립트 버전이라고 보면된다. 타입스크립트의 스키마를 체크하는데 도와주는 라이브러리다.
- [type-challenges](https://github.com/type-challenges/type-challenges): 알고리즘에 백준이 있다면, 타입스크립트에는 `type-challenge`가 있다. 문제를 하나씩 풀어나가는 재미가 있다. `hard`까지는 그럭저럭 꾸역꾸역할 수 있었는데, `extreme`부터는 약간 그냥 테스트를 위한 테스트 같은 느낌이다. (내가 못풀어서 그런 걸수도 있다.) 실무에서 개발하는 타입스크립트 개발자라면, `medium`까지만 풀어도 충분할 것 같다.
- [TypeScript Error Translator](https://marketplace.visualstudio.com/items?itemName=mattpocock.ts-error-translator): 타입스크립트를 처음 접했을 때 많이 헤매는 것이 잘못된 타입으로 인한 에러인데, 이 에러를 읽기가 처음에는 약간 버거운 경우도 있다. 이러한 불친절한 에러를 사람이 읽기 쉽게 번역해주는 extension이다.


\"타입\"스크립트니까 타입만 잘 할줄 알면 됩니다.

알아두면 유용한 타입스크립트 팁

## Introduction

웹 애플리케이션 성능 최적화 내지는 메모리 이슈를 해결하기 위해서 이것저것 뒤지다보면, 결국 최종적으로 확인해봐야 할 것은 바로 이 메모리 프로파일링 탭이다. 이 탭을 통해 웹 애플리케이션에서 메모리 누수가 일어나고 있는지, 또 메모리를 최대한 효율적으로 사용하고 있는지를 확인하기 위해서는, 이 메모리 프로파일링 탭을 읽을 수 있어야 한다. 마침 크롬 버전이 업데이트 되면서 (꽤 되긴했지만) 친절하게 크롬의 디버그 도구가 한글로 번역까지 되어 있다.

본격적으로 탭을 살펴보기에 앞서, 크롬 메모리 프로파일러를 처음 보면 매우 혼란스럽다. 친절한 자바스크립트 코드를 보다가 포인터와 각종 희한한 정보들을 살펴보다면 매우 혼란스러울 것이다. 그래서 본격적으로 우리가 (혹은 내가) 만든 페이지를 디버깅 하기에 앞서, 빈 html 태그만 있는 페이지를 기준으로 살펴보려고 한다.

HTML의 역사는 매우매우 오래되었고 또 갖가지 문법들이 유서깊게 짬뽕되어 있기 때문에, 우리가 빈 `<html/>` 문서만 만들어도 크롬은 알아서 `head`와 `body` 삽입해서 기본적인 HTML 트리를 만들어 준다. 아무튼, 이 빈 `<html/>`을 시작으로 크롬 메모리 탭에서 무슨 일이 일어나고 있는지 살펴보자.

```html
<html />
```

위 파일을 별도 html로 저장한 다음에 시크릿탭으로 페이지를 한번 열어보자. 꼭 시크릿탭으로 여는 것이 좋다. 그렇지 않으면 안그래도 정신사나운 정보들에 추가로 익스텐션 정보들까지 달라붙어 매우 읽기 어려워진다.

![chrome-memory-profiler1](./images/chrome-memory-profiler1.png)

힙 스냅샷 하단에 있는 숫자값을 포함할지 여부를 꼭 선택하자. [이전 포스트](/2022/04/how-javascript-variable-works-in-memory#숫자는-조금-복잡)에서 살펴보았던 것처럼, `smi` 숫자는 관리 방식이 달라 이것을 체크하지 않으면 숫자값을 볼 수 없다.

![chrome-memory-profiler2](./images/chrome-memory-profiler2.png)

놀랍게도, 아무것도 없는 말그대로 빈페이지 주제에 단순히 빈 페이지를 렌더링하는데에도 많은 오브젝트가 관여되어 있는 것을 볼 수 있다. 이 페이지가 로드된 이후, 인스턴스화된 각 자바스크립트 객체는 해당 생성자 클래스 아래에 그룹화되어 있는 것을 볼 수 있다. 괄호로 쳐져있는 그룹 `()`은 직접 호출할 수 없는 네이티브 생성자를 나타낸다. 위 그림에서 보면 많은 `(compiled code)` `(system)` 등도 볼 수 있고, 그리고 `Date` `String` `RangeError` 과 같은 전통적인 자바스크립트 객체도 볼 수 있다.

이 모든 것을 이해하기 위해서, 유저가 간단하게 버튼을 눌러서 동작하는 작업을 추가해보자.

```html
<html>
  <head>
    <script>
      var counter = 0
      var instances = []

      function X() {
        this.i = counter++
      }

      function allocate() {
        instances.push(new X())
      }
    </script>
  </head>
  <body>
    <button onclick="allocate()">Allocate</button>
  </body>
</html>
```

위 코드에서 버튼을 클릭하고 메모리 프로파일러를 열어보자.

![chrome-memory-profiler3](./images/chrome-memory-profiler3.png)

`X`라는 객체가 할당되어 있는 것을 볼 수 있다.

이를 조금 더 찾기 쉽게 하는 방법은, 먼저 첫번째 스냅샷을 찍은 뒤에, 다시 동그라미 버튼을 눌러 두번쨰 스냅샷을 찍는 것이다. 그리고 드롭다운에서, 이 스냅샷 사이에 생성된 생성자만 보는 방법이 있다.

![chrome-memory-profiler5](./images/chrome-memory-profiler5.png)

버튼을 클릭한 이벤트만 했을 뿐이라, `X`만 보였을 것이라 예상하였지만, 몇가지 추가적인 작업이 발생했음을 알 수 있다. 크롬의 경우 레이지 로딩 객체에 대해 최적화를 하는 작업이 있다. 이 경우에는 HTML 버튼 엘리먼트을 클릭하기 전까지 메모리가 주어지지 않았음을 알 수 있다. 즉 클릭이 실제로 일어났을 때 그때서야 비로소 메모리를 할당해서 작업을 한 것이다.

이를 확인해보는 방법은 버튼을 여러번 클릭해보는 것이다. 여러번 클릭한후 스냅샷을 찍어두면, 아까와 다르게 딱 필요한 `X`만 할당해서 작업이 이뤄지고 있음을 알 수 있다.

![chrome-memory-profiler6](./images/chrome-memory-profiler6.png)

> 여기서 보여주는 아이디는 객체 인스턴스를 구별하기 쉽게 도와주는 아이디 값으로, 실제로 메모리 주소를 가리키는 것은 아니다.

각 인스턴스는, 클래스 이름이 아래에 내열되고, 실제로 그 객체를 클릭해보면 객체에 대한 상세한 정보가 나와있는 것을 알 수 있다.

![chrome-memory-profiler7](./images/chrome-memory-profiler7.png)

여기서 주목해야할 것은 `얕은 크기`라고 작성되어 있는 열이다. 이 `얕은 크기`라는 것은 객체가 유지하고 있는 바이트의 크기를 나타낸다. 자바스크립트는, 이 자바스크립트를 만든 C언어와는 다르게 객체 하나를 지하는데 더 많은 크기를 차지한다.

`유지된 크기`는 객체가 참조를 보유하고 있는 객체 외에 객체 자체의 내부 메모리 때문에 이 객체가 보유하고 있는 바이트 수를 의미한다. 그리고 이 메모리는 가비지 콜렉팅 되지 않는다. 무슨 말인지 이해하기 위해 다음 예제를 실행해보자.

```html
<html>
  <head>
    <script>
      var counter = 0
      var instances = []

      function Y() {
        this.j = 5
      }

      function X() {
        this.i = counter++
        this.y = new Y()
      }

      function allocate() {
        instances.push(new X())
      }
    </script>
  </head>
  <body>
    <button onclick="allocate()">Allocate</button>
  </body>
</html>
```

![chrome-memory-profiler8](./images/chrome-memory-profiler8.png)

위 예제는, X 인스턴스가 생성될 때 마다 `y`에 `Y` 인스턴스를 초기화 하고 할당한다. `X`자체는 52 바이트 밖에 없지만, `X`내부가 순수 이 객체외에 참조를 유지하기 위해 이용하는 메모리, 즉 `Y`의 사이즈인 48 바이트를 추가로 사용하므로 `유지된 크기`는 100 바이트임을 알 수 있다.

```html
<html>
  <head>
    <script>
      var counter = 0
      var instances = []

      function X() {
        this.i = counter++
        if (instances.length) {
          this.ref = instances[instances.length - 1]
        }
      }

      function allocate() {
        instances.push(new X())
      }
    </script>
  </head>
  <body>
    <button onclick="allocate()">Allocate</button>
  </body>
</html>
```

크롬의 메모리 프로파일러는 `유지된 크기`를 계산하는데 있어 매우 영리한 모습을 보여준다.

![chrome-memory-profiler9](./images/chrome-memory-profiler9.png)

예제를 스냅샷 찍은 모습에서 알 수 있는 것처럼, X에 새로운 Y를 할당하는 대신에 인스턴스 베열에서 이전에 만들었던 인스턴스에 대한 참조를 유지하여 메모리를 효율적으로 관리하는 것을 볼 수 있다.

여기서 언급하지 않은 열 하나가 바로 `거리`다. 자바스크립트의 메모리 누수는 다른 객체가 참조를 보유하고 있어서 가비지 콜렉터가 객체 인스턴스를 수집하지 못할 때 발생한다.다른 객체가 해당 객체에 대한 참조를 보유하고 있기 때문에 발생한다.

![chrome-memory-profiler10](./images/chrome-memory-profiler10.png)

지금 위 그림에서 보여준 객체는 가비지 콜렉팅에 적합하지 않아서 힙에서 계속 머물러 있는 것을 볼 수 있다. 여기에서 객체 항목을 보면 이 인스턴스가 메모리를 계속해서 차지하고 있는 이유를 알 수 있다. 이 객체는 글로벌, 즉 `window` 객체가 소유하는 인스턴스 배열이 유지되어야 하기 때문에 계쏙해서 존재하는 것을 볼 우 있다. 웹 애플리케이션에서 메모리 누수가 발생하는 주요 원인은 잘못된 변수 선언에 있으며, 이러한 잘못 선언된 변수가 글로벌에 계속 머물러 있기 때문이다. 이 경우에는 이 객체 뷰를 통하여 신속하게 왜 유지되고 있는지를 확인할 수 있다.

다음으로 살펴볼 메뉴는 타임라인 할당 계측 이다. 이 메뉴는 앞선 힙 스냅샷과 유사하다. 한가지 차이점이라면 지속적으로 실행되어 멈추기전까지 이 메모리 스냅샷에서 일어나는 변화를 알 수 있다는 것이다. 사용자의 인터랙션에 따른 메모리의 상황을 점검하기 위해 유용하다.

![chrome-memory-profiler11](./images/chrome-memory-profiler11.png)

![chrome-memory-profiler12](./images/chrome-memory-profiler12.png)


스냅샷 해석과 디버깅의 책임은 본인에게 있습니다

크롬 메모리 프로파일러 사용하는 방법

## Table of Contents

## 거의 대부분의 변수는 힙에 존재한다.

**일반적으로 원시값은 스택에, 객체는 힙에 할당된다고 알려져있지만, 이와 반대로 자바스크립트의 모든 원시값도 힙에 할당되어 있다.** 이는 굳이 V8 소스코드를 까지 않고도 알 수 있는 방법이 존재한다.

1. 먼저 자신의 로컬 머신에 `node --v8-options` 명령어를 날려보자. 여기에는 다양한 노드 v8과 관련된 옵션값이 존재한다. 그 중에 `stack-size`라는 옵션을 활용하면, 로컬머신의 V8 스택 사이즈를 확인할 수 있다. 나는 최신버전의 (20220422 기준) 노드 v16.6.2를 사용하고 있는데, 864kb가 나왔다.
2. 자바스크립트 파일을 생성한다음, 엄청나게 큰 string을 만들고, `process.memoryUsage().heapUsed`를 활용해서 힙을 얼마나 차지하고 있는지 확인해보자.

```javascript
function memoryUsed() {
  const mbUsed = process.memoryUsage().heapUsed / 1024 / 1024
  console.log(`Memory used: ${mbUsed} MB`)
}

function memoryUsed() {
  const mbUsed = process.memoryUsage().heapUsed / 1024 / 1024
  console.log(`Memory used: ${mbUsed} MB`)
}

console.log('before')
memoryUsed() // Memory used: 4.7296905517578125 MB

const bigString = 'x'.repeat(10 * 1024 * 1024)
console.log(bigString) // 컴파일러가 bitString을 최적화하여 날려먹지 않게 필요하다.

console.log('after')
memoryUsed() // Memory used: 14.417839050292969 MB
```

엄청나게 큰 10mb짜리 string을 선언한 뒤 확인해보니, 해당 문자열 만큼의 약10mb의 차이가 있는 것을 확인할 수 있었다. 앞서 언급했던 스택 사이즈의 경우, 오직 864kb 밖에 없었다. 그렇다. 스택에는 이렇게 큰 문자열을 저장할 공간이 없다.

## 자바스크립트의 원시 값은 대부분 재활용 된다.

만약 아까 만들었던 `'x'.repeat(10 * 1024 * 1024)`를 또다른 변수에 할당한다면, 메모리에 그것을 그대로 복사해서 힙에 총 20mb 를 차지하게 될까?

정답은 그렇지 않다. 중복된 문자열은 별도로 할당되지 않는다. 우리가 일반적으로 알고 있는 것 처럼, 자바스크립트에서 변수를 할당 하는 동작은 실제 값의 크기에 비례하는 비용이 드는 것은 아니다. 자바스크립트 변수의 대부분은 포인터로 이루어져 있다.

이러한 사실을 Chrome DevTools를 활용한 메모리 프로파일링을 통해서 확인할 수 있다.

```html
<html>
  <body>
    <button id="button">button</button>
    <script>
      const button = document.querySelector('#button')

      button.addEventListener('click', function () {
        const string1 = 'hello'
        const string2 = 'hello'
      })
    </script>
  </body>
</html>
```

다음과 같은 html 문서를 만들어 저장하고, Chrome Devtool의 Memory 탭에서 확인해보자.

![chrome-devtool1](./images/chrome-devtool1.png)

![chrome-devtool2](./images/chrome-devtool2.png)

클릭을 여러번해도, string "hello"`는 힙에 단 하나만 존재하는 것을 알 수 있다.

이러한 것을 [String interning](https://en.wikipedia.org/wiki/String_interning)이라고 한다. 각 문자열의 값을 복사본 하나만 저장하는 방법으로, 불변해서 관리하는 것을 의미한다. 이러한 방법을 활용하면, 문자열이 생성되거나 인터닝 될때, 이로인한 시간 소요나 공간을 효율적으로 관리할 수 있게 된다.

v8 내부에서는, 이를 [string-table](https://chromium.googlesource.com/v8/v8/+/fc0cbc144530662db5ef27406e1c7302760e8461/src/objects/string-table.h) 이라는 코드의 형태로 관리한다.

여기에 추가로, V8에는 [oddball](https://chromium.googlesource.com/v8/v8/+/master/src/builtins/base.tq#506) 이라고 불리는 것이 존재한다.

```
type TheHole extends Oddball;
type Null extends Oddball;
type Undefined extends Oddball;
type True extends Oddball;
type False extends Oddball;
type Exception extends Oddball;
type EmptyString extends String;
type Boolean = True|False;
```

이들은 스크립트의 첫번째 라인이 실행되기전에 V8에 의해 힙에 미리 할당되는 값이다. 즉, 자바스크립트 프로그램에서 이러한 값이 사용되던 말건 상관없이 미리 할당해두는 값이라고 보면 된다

그리고 이 값들은 항상 재사용된다. 즉,각 `oddball` 별로 하나의 값만 가지고 있다.

```javascript
function Oddballs() {
  this.undefined = undefined
  this.true = true
  this.false = false
  this.null = null
  this.emptyString = ''
}
const obj1 = new Oddballs()
const obj2 = new Oddballs()
```

앞서 실행해보았던 코드에 위 코드를 추가하고, 다시한번 스냅샷을 찍어보자.

![chrome-devtool3](./images/chrome-devtool3.png)

클릭을 두번해서 별개의 객체가 생성되었음에도, 각각의 값들은 같은 주소를 가리키고 있는 것을 볼 수 있다.

자바스크립트가 `oddball`을 가지고 있는 변수를 만들경우, 이들은 값을 생성하거나 파괴하는 동작을 거치는게 아닌 미리 만들어둔 값을 부르는 방식으로 관리하는 것을 볼 수 있다.

## 자바스크립트 변수들은 대부분 포인터다.

V8 소스코드를 더 깊게 파고들어가 보면, 자바스크립트 프로그램에서 생성한 변수가, 힙에 위치한 C++ 객체를 가리키는 메모리 주소라는 사실을 알 수 있다.

예를 들어, `undefined`는 V8에서 [다음](https://chromium.googlesource.com/v8/v8/+/a684fc4c927940a073e3859cbf91c301550f4318/include/v8-primitive.h#830)과 같이 구현되어 있다.

```
V8_INLINE Local<Primitive> Undefined(Isolate* isolate) {
  using S = internal::Address;
  using I = internal::Internals;
  I::CheckInitialized(isolate);
  S* slot = I::GetRoot(isolate, I::kUndefinedValueRootIndex);
  return Local<Primitive>(reinterpret_cast<Primitive*>(slot));
}
```

우리가 주목해야할 것은, `GetRoot`다. `GeetRoot`는 [다음](https://chromium.googlesource.com/v8/v8/+/a684fc4c927940a073e3859cbf91c301550f4318/include/v8-internal.h#388)과 같이 구현되어 있다.

```
V8_INLINE static internal::Address* GetRoot(v8::Isolate* isolate, int index) {
    internal::Address addr = reinterpret_cast<internal::Address>(isolate) +
                             kIsolateRootsOffset +
                             index * kApiSystemPointerSize;
    return reinterpret_cast<internal::Address*>(addr);
  }
```

## 숫자는 조금 복잡

숫자의 경우에는 다른 객체와는 조금 다르다. 숫자는 사용 빈도가 매우 잦기 때문에, 앞선 방식으로 관리하게 되면 새로운 개체를 할당해야 하는데 이는 V8입장에서 너무 큰 부담이된다. 여기서 사용하는 방법이 `포인터 태깅`이고, 64비트 아키텍쳐를 기반으로 $$-2^{31}$$ 에서 $$2^{31}-1$$ 까지 구성되어 있는 이 숫자를 V8에서는 이를 `smi` 라고 부른다.

이들은 내부적으로 최적화가 되어 있어 포인터에서 추가적인 스토리지를 할당할 필요 없이 포인터 내부에서 인코딩할 수 있다. 이는 V8만의 특징은 아니고, 다른 언어에서도 발견할 수 있다.

이 방법이 조금 복잡한데, 간단하게 요약하자면 SMI에는 포인터가 아닌 부호있는 정수값을 직접 저장한다. SMI는 힙메모리에 할당하지 않는 즉치 값(Immediate values)라고 부른다.

그러나 모든 숫자가 smi인 것은 아니다. 범위를 넘어서는 정수값, double 형식, 값을 박싱해야 하는 경우에는 여전히 힙에 개체로 저장되며 이는 힙숫자라고 부른다.

숫자가 가지고 있는 또다른 복잡한 특징은 앞서 언급했던 문자열과는 반대로, 재사용되지 않을 수도 있다는 사실이다.

이러한 사실들을 실제로 메모리 스냅샷을 통해 알아보자.

```javascript
function MyNumbers() {
  ;(this._integer = 1), (this._double = 1.1)
}
// 전역변수
var _global_integer = 1
var _global_double = 1.1
const num1 = new MyNumbers()
const num2 = new MyNumbers()
```

이제 이 코드를 추가해서 또 확인해보자.

![chrome-devtool4](./images/chrome-devtool4.png)

immediate value인 1은 `smi`가 되어서 관리되고 있어 속성 값에서 나타나지 않았다. 앞서 말한 것처럼, `smi`값 1은 힙메모리에 할당되지 않기 때문이다.

![chrome-devtool5](./images/chrome-devtool4.png)

위 스크린샷은 앞서 선언했던 전역변수 두개를 살펴본 것이다. `smi`인 값은 역시 나타나지 않았고, `_global_double`의 값만 메모리 힙 스냅샷에 나타난다.

이렇게 힙에서 관리하고 있는 숫자를 `HeapNumber` 라고 하는데, 이 숫자의 특징은 재사용되지 않는 다는 것이다.

![chrome-devtool6](./images/chrome-devtool6.png)

> heap number가 각각 다른 포인트를 가리키고 있는 모습

예를 들어, $$3 + 0.14$$ 나 $$\frac{314}{100}$$ 과 같은 연산은 3.14라는 `HeapNumber`가 이미 존재하는지 확인할 필요가 없기 때문에 (이미 연산했으므로) 각각의 다른 `HeapNumber`가 할당된다.

## 정리

```javascript
const a = 'foo'
const b = 123
const c = false
const d = { name: 'foo', number: 123 }
```

컴파일러를 거치면, 이러한 변수는 메모리에 위치하게 된다.

```
a: 0x000
b: 0x010
c: 0x020
d: 0x030
```

자바스크립트 변수는 스택/힙/레지스터 등에 위치하거나 이미 알려져있는 힙 메모리 위치에 존재할 수 있다.

```
0x000: 0x100
0x010: 123
0x020: 0x200
0x030: 0x300
```

실제 자바스크립트의 값은 힙에 위치한다.

```
0x100: 'foo'
0x200: false
0x300: {name: 0x100, number: 123 }
```

컴퓨터 메모리는 엄청나게 복잡한 주제다. 그리고 이러한 주제를 다루기에 아직 부족한 면도 있고, 또 메모리와 관련된 질문에 대한 대부분의 답은 컴파일러와 프로세서 아키텍처 마다 다르다. 예를 들어, 변수는 항상 메모리(RAM)에 있는 것은 아니다. 즉, 대상 레지스터에 직접 로드될 수도 있고, 즉각적인 값으로 명령의 일부가 될 수도, 심지어 완전히 무의 상태로 최적화 될 수 있다. V8과 같은 자바스크립트 엔진은 너무 복잡하고, 제공하는 기능이 강력하므로, 만약 메모리 레이아웃과 같은 저수준의 세부 정보를 공부하기 위해서는 C, C++로 시작하여 소스코드가 기계코드가 되는 방법을 이해하는 것이 좋지 않을까?

## 더 읽어보기

- https://www.zhenghao.io/posts/javascript-variables
- http://www.egocube.pe.kr/lecture/content/html-javascript/202003240001


V8 내부 코드를 자유롭게 읽을 수 있는 그날까지

Latest

타입스크립트 컴파일러는 어떻게 동작하는가?

리액트의 새로운 훅, useEvent

알아두면 유용한 타입스크립트 팁

크롬 메모리 프로파일러 사용하는 방법

V8에서 관리되는 자바스크립트 변수