알고리즘은 문제 해결을 위한 절차 또는 방법을 의미합니다. 이 블로그에서는 알고리즘의 기본 개념과 시간 복잡도에 대해 알아보겠습니다.

알고리즘과 시간 복잡도


## 알고리즘

알고리즘은 문제를 해결하기 위한 절차 또는 방법을 의미합니다.

이해를 돕기 위해 1부터 100까지의 숫자 카드 중 출제자가 생각한 숫자를 맞추는 게임을 한다고 해봅시다. 

![1부터 100까지의 숫자 카드](/static/images/what-is-algorithm/cards-from-one-to-hundred.png)

<br />

이 게임은 정답이 아닐 경우 더 큰지 또는 더 작은지 알려주는 규칙을 가지고 있습니다. 

![정답이 아닐 경우 더 큰지, 더 작은지 알려주는 규칙](/static/images/what-is-algorithm/up-down-game-rules.png)

<br />

이 때 1에서 시작해서 100까지 순서대로 정답을 맞추는 방법도 있고 

![1부터 순서대로 정답을 맞추는 방법](/static/images/what-is-algorithm/up-down-game-linear-strategy.png)

<br />

50에서 시작해서 더 큰지, 더 작은지 확인 후 반 씩 추려나가는 방법도 있습니다.

![오답을 반씩 제거해서 정답을 맞추는 방법](/static/images/what-is-algorithm/up-down-game-binary-strategy.png)

<br />

이때  위 두 방법 모두 숫자 맞추기 게임에서 정답을 찾기 위한  알고리즘으로 볼 수 있습니다. 이 외에도 100부터 역순으로 말하기, 짝수 다 부르고 홀수 부르기 등 전부 나열할 수 없을 만큼 많은 알고리즘이 존재할 것이라는 것을 예상할 수 있습니다.

### 어떤 알고리즘을 사용해야할까?

이제 알고리즘이라는 게 뭔지는 알 것 같습니다. 그런데 많은 알고리즘 중에 어떤 알고리즘을 사용할지 어떻게 결정할까요? 여기서 시간 복잡도라는 개념이 등장합니다. 

## 시간 복잡도

시간 복잡도란 입력(데이터의 크기)에 따른 연산 수행 시간(알고리즘으로 문제를 해결하는 데 걸리는 시간)의 변화를 일반화하여 나타낸 것으로 주로 bigO 표기법을 사용해서 나타냅니다.

![시간 복잡도](/static/images/what-is-algorithm/time-complexity-graph.png)

> 지금은 O(1), O(n), O(log n), O(n^2)이 무엇인지는 알 필요 없습니다. 시간 복잡도는 입력-연산수행시간의 변화율과 관련이 있구나! 정도만 이해하고 넘어가시면 됩니다.

<br />

다시 말해, 한 알고리즘(i.g. 1부터 마지막 숫자까지 순서대로 시도하기)을 사용해서 숫자 게임을 100개, 1,000개, 10,000개, ... 이런 식으로 늘려가면서 진행했을 때 정답을 맞출 때까지 걸리는 시간이 어떻게 변화되는가를 나타내는 것입니다.

그럼 이제 위에서 소개했던 두 방법의 시간 복잡도를 알아보겠습니다.

### 순서대로 시도하는 알고리즘의 시간 복잡도

1부터 100까지의 숫자로 게임을 진행하면 정답을 맞추기 까지 얼마나 많은 시간이 필요할까요? 정답이 무엇이냐에 따라 다를 것입니다. 정답이 1이라면 단 한 번의 시도로도 맞출 수 있고 정답이 100이라면 100번의 시도 끝에 정답을 맞출 수 있습니다. 이렇게 정답이 그때그때 다를 텐데 문제 해결에 걸리는 시간을 어떻게 알 수 있을까요? 

그래서 시간 복잡도를 나타낼 때는 주로 최악의 시나리오를 가정합니다. 최악의 시나리오일 때 정답은 100이고 100번의 시도를 해야 정답을 맞출 수 있으므로 편의상 1번 시도할 때 마다 1이라는 시간이 걸린다고 가정하면 100만큼의 시간이 걸리게 됩니다.

![100개의 숫자 게임 정답을 순서대로 맞출 경우 최악의 시나리오](/static/images/what-is-algorithm/up-down-game-linear-strategy-with-worst-case.png)

<br/>

또 1부터 1,000까지 숫자로 게임을 진행하고 순서대로 맞추기 알고리즘을 사용하면 최악의 경우 정답이 1,000일 테니 1,000만큼의 시간이 걸릴 것입니다. 

![1,000개의 숫자 게임 정답을 순서대로 맞출 경우 최악의 시나리오](/static/images/what-is-algorithm/up-down-game-linear-strategy-with-worst-case2.png)

<br/>

마찬가지로 1부터 n까지의 숫자로 게임을 진행하면 n 만큼의 시간이 걸릴 것을 예상할 수 있습니다. 

![n 개의 숫자 게임 정답을 순서대로 맞출 경우 최악의 시나리오](/static/images/what-is-algorithm/up-down-game-linear-strategy-with-worst-case3.png)

<br/>

이를 BigO 표기법을 활용하여 O(n)으로 나타낼 수 있습니다. 즉, 1부터 순서대로 맞추기 알고리즘은 O(n)의 시간 복잡도를 갖는 알고리즘이며 다음과 같이 그래프로 나타낼 수 있습니다.

![그래프로 표현한 o(n) 시간 복잡도](/static/images/what-is-algorithm/o(n)-time-complexity.png)

<br/>

시간 복잡도가 O(n)인 알고리즘은 그래프에서 볼 수 있듯이 입력(데이터 크기)이 증가했을 때 연산 수행 시간(문제를 해결하는 데 걸리는 시간)이 선형적으로 증가하는 알고리즘입니다.

### 오답을 반씩 제거해나가며 시도하는 알고리즘의 시간 복잡도

이번에는 50부터 시작해서 출제자의 힌트를 듣고 오답을 반씩 제거해나가는 알고리즘의 시간 복잡도를 알아보겠습니다. 이 알고리즘의 시간 복잡도는 어떻게 나타낼 수 있을까요?

정답을 맞추는 사람의 입장이 되어 숫자 하나씩 시도를 해보겠습니다.


첫 번째 시도: 정답이 아니더라도 업인지 다운인지 알려주기 때문에 오답이었을 때 50%를 제거할 수 있도록 50을 시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 첫 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-1.png)

<br/ >

두 번째 시도: 1부터 49까지 숫자 중 정답이 있음을 알 수 있습니다. 이번에는 (1 + 49) / 2 = 25를 시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 두 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-2.png)

<br/ >

세 번째 시도: 1부터 24까지 숫자 중 정답이 있고 (1 + 24) / 2 = 12.5이므로 내림해서 12를 시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 세 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-3.png)

<br/ >

네 번째 시도: 1부터 11까지 숫자 중 정답이 있고 (1 + 11) / 2 = 6을 시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 네 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-4.png)

<br/ >

다섯 번째 시도: 1부터 5까지 숫자 중 정답 존재, (1 + 5) / 2 = 3 시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 다섯 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-5.png)

<br/ >

여섯 번째 시도: 1부터 2까지 숫자 중 (1 + 2) / 2 = 1.5이므로 내림해서 1시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 여섯 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-6.png)

<br/ >

일곱 번째 시도: 남은 숫자는 2이므로 2 시도

![오답을 반씩 제거해나가며 시도하는 알고리즘 최악의 시나리오 - 일곱 번째 시도](/static/images/what-is-algorithm/up-down-game-binary-strategy-with-worst-case-7.png)

<br/ >

최악의 시나리오를 가정하기 위해 정답을 2로 설정해 봤고 이 때 7번의 시도 끝에 정답을 맞힐 수 있었습니다. 과연 이 알고리즘의 시간 복잡도는 어떻게 구할까요?

조금 더 쉽게 생각할 수 있도록 문제를 다음과 같이 변경해 보겠습니다. 100을 반씩 줄여나갈 때 1이 될 때까지 몇 번의 시도가 필요할까요?
100 > 50 > 25 > 13 > 7 > 4 > 2 > 1이므로 7번의 시도 끝에 1이 됩니다.

만약에 400일 경우 어떨까요?
400 > 200 > 100 > 50 > 25 > 13 > 7 > 4 > 2 > 1 이므로 9번의 시도 끝에 1이 됩니다.

어떤 숫자 n이 있을 때 그 숫자를 1/2로 계속 나눴을 때 몇 번 만에 1이 될까?라는 문제는
1에서 2를 계속 곱할 때 몇 번 만에 N이 될까?로 반대로 생각해 볼 수 있습니다.

이를 수식으로 나타내보면  1*2^X = n
즉, 2^X = n입니다. 여기서 N은 데이터의 크기, X은 연산 수행 시간입니다.
지수 함수의 역함수는 로그 함수이므로 X = log n(밑이 2인 로그 함수)이며
따라서 시간 복잡도는 O(log n)으로 나타낼 수 있습니다.

이를 그래프로 나타내면 다음과 같습니다.

![그래프로 표현한 O(n)과 O(log n)의 시간 복잡도](/static/images/what-is-algorithm/o(n)-and-o(logn)-time-complexity.png)

<br/ >


### 시간 복잡도가 갖는 의미

이 그래프를 통해 알 수 있는 사실은 O(log n)의 시간 복잡도를 갖는 알고리즘의 경우 입력의 크기가 엄청 커졌을 경우에도 그에 따른 연산 수행 시간의 증가율이 가파르지 않다는 것입니다.

따라서 O(n)의 시간 복잡도를 갖는 알고리즘과 비교했을 때, 입력이 매우 큰 경우에도 빠른 시간 안에 문제를 해결할 수 있습니다.
예를 들어, 1조 개의 카드로 게임을 진행할 때 최악의 경우(1번 시도마다 1초가 걸린다고 가정했을 때)

- O(n) 알고리즘: 31,710 년 소요
- O(log n) 알고리즘: 40초 소요

위와 같이 데이터 사이즈가 클 때 O(log n)의 힘을 체감할 수 있습니다.

> 데이터 사이즈가 작을 때는 차이가 크지 않기 때문에 이 점 또한 항상 생각해야합니다.

## 마치면서

이제 시간 복잡도라는 개념을 알게 되었으니 다음과 같은 생각을 할 수 있게 되었습니다.

- 데이터 사이즈가 너무 커서 O(n) 알고리즘으로는 이 문제를 해결하기 어려울 것 같아. O(log n) 알고리즘으로 개선해보자
- 이 문제는 데이터 사이즈가 크지 않기 때문에 굳이 복잡한 O(log n)의 알고리즘을 사용하기 보다 이해하기 쉽고 빠르게 작성할 수 있는 O(n) 알고리즘을 활용하는게 더 좋아보여

다음에는 오늘 배운 알고리즘을 코드로 구현해 보면서 더 깊게 이해하는 시간을 가져보겠습니다.

React와 Svelte는 어떠한 철학을 가지고 만들어졌는지, 어떤 점이 다른지 비교해 봅니다.

React, Svelte 무엇이 다를까?


## 시작하기 전에

이 글은 Svelte를 배워보면서 느낀 React와 Svelte의 차이점, Svelte의 헷갈릴만한 부분을 소개하는 글입니다.

React를 하다가 Svelte를 배워보고 싶은 경우 또는 그 둘의 차이가 궁금하셨던 분들에게는 조금이나마 도움이 될 수 있을 것입니다.

## 지향하는 가치

### React

[Minimal API를 지향하며 개발자가 가능한 많은 명시적(explicit) 코드를 작성하도록 만듭니다.](https://www.youtube.com/watch?v=4anAwXYqLG8)

**장점과 그에 따른 비용들**

| 장점 | 비용 |
| --- | --- |
| 명시적으로 작성해야 하는 코드가 많기 때문에 숨겨지는 코드가 적으며 겉으로만 보았을 때도 이해할 수 있는 부분이 많아집니다. | 비교적 많은 코드를 작성해야 합니다.(비교적 많은 시간이 소모됩니다) ⇒ 버그가 있는 코드를 작성할 확률이 높아집니다.|
| 최소한의 API를 제공하기 때문에 기억해야 할 것들이 비교적 적습니다. | API가 최소화된다는 것은 그만큼 라이브러리가 해주는 것이 적다는 것을 의미합니다. |

<br/>

React는 다음과 같은 생각을 가지고 있습니다.

- 반복적인 코드가 잘못된 추상화을 제공하는 것보다 좋다.
- 명시적(explicit) 코드를 묵시적(implicit) 코드로 변경하는 것은 쉽지만 그 반대는 어렵다.

⇒ 그래서 추상화를 최소화하고 나머지는 React를 사용하는 개발자에게 맡깁니다.

### Svelte

["Write less code"](https://svelte.dev/blog/write-less-code)

많은 것들을 내부적으로 처리해 주며 개발자가 더 적은 코드를 작성하도록 만듭니다.

장점과 그에 따른 비용들

| 장점 | 비용 |
| --- | --- |
| 비교적 적은 코드를 작성합니다.(비교적 적은 시간이 소모됩니다) ⇒ 버그가 있는 코드를 작성할 확률이 낮아집니다. | 명시적으로 작성해야 하는 코드가 줄어들기 때문에 겉으로만 보았을 때는 비교적 어떻게 동작하는지 이해하기가 어렵습니다. |
| 많은 것들을 svelte가 알아서 처리해 줍니다. | 제대로 이해하고 사용하기 위해서 기억해야 할 것들이 많아집니다.  |

<br/>

svelte는 개발자가 더 많은 코드를 작성할수록 시간도 오래 걸리고 더 많은 버그를 생성할 것이라고 생각합니다. 따라서 React와는 상반되게 "Write less code"를 지향합니다.

결론

지향하는 방향은 180도 다른 느낌이지만 둘 다 충분히 납득할 만한 이유가 있다는 생각이 들었습니다.

## 차이점

### 상태값이 변경되었을 때 동작 방식

React는 처음 그리고 상태 값이 변경될 때마다 컴포넌트 전체가 실행됩니다.

```jsx
function NameForm() {
  const [name, setName] = useState('');

  const handleChange = (event) => {
    setName(event.target.value);
  };

  return (
    <div>
      <h1>이름 입력</h1>
      <input type="text" value={name} onChange={handleChange} />
      <p>입력된 이름: {name}</p>
    </div>
  );
}
```

위 예시에서 `name`이 변경될 때마다 `handleChange` 함수가 계속 생성됩니다. ⇒ 계속 불필요한 일을 수행합니다.
(하지만 다른 관점에서 보면 상태 값이 변경되면 컴포넌트 코드가 전부 실행되기 때문에 결과를 예상하기 쉽습니다.)

반면에 Svelte의 경우 일반적으로 script 내에 작성된 코드는 컴포넌트 인스턴스가 생성될 때 실행되며 상태 값이 변경될 때는 다시 실행되지 않습니다. (반응성 구문 같은 몇 가지 예외 제외)

```html
<script>
  let name = '';

  function handleChange(event) {
    name = event.target.value;
  }
</script>

<h1>이름 입력</h1>
<input type="text" value={name} on:input={handleChange} />
<p>입력된 이름: {name}</p>
```

React와 달리 `handleChange`는 한 번만 생성됩니다. ⇒ 효율적입니다.

그렇기 때문에 다음과 같이 `console.log`를 추가하면 처음에만 `name`의 값이 출력되며 그 이후 `name`이 변경될 때는 어떠한 값도 출력되지 않습니다.

```
<script>
  let name = '';
  console.log(name);

  function handleChange(event) {
    name = event.target.value;
  }
</script>
```

단순화시켜서 정리를 해보자면 React는 조금 비효율적이지만 자연스러우며
Svelte는 부자연스럽지만(React에 익숙해져서인지) 효율적으로 동작한다는 생각이 들었습니다.

### 상태값 변경을 감지하는 방법

React는 [Object.is](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object/is)를 사용해서 변경을 감지합니다. 원시 값이 아닌 상태 값을 변경할 때 기존 상태 값을 복사해야 합니다.

```jsx
const [todos, setTodos] = useState([])

// 참조 값이 같으므로 동작 X
todos.push(newTodo)
setTodos(todos) // Object.is(이전 값, 현재 값) => true이므로 변경 감지 불가

// 참조 값이 다르므로 동작 O
setTodos([...todos, newTodo]) // Object.is(이전 값, 현재 값) => false이므로 변경 감지 가능
```

변경할 때마다 새로운 값을 생성하고 복사하는 불필요하고 비효율적인 일을 수행해야 합니다.

반면에 Svelte는 컴파일러가 `=` 을 통해 변경을 감지합니다. 따라서 복사할 필요가 없습니다.

```jsx
let todos = [];

// 1. 참조값이 변경되지 않아도 동작 O
todos.push(newTodo);
todos = todos;

// 2. React 처럼 복사해도 동작 O
todos = [...todos, newTodo]
```

불필요한 복사를 할 필요가 없으니 조금 더 효율적입니다. 위와 같이 2가지 방법 다 사용 가능하며
데이터의 크기가 크고 변경이 빈번할 경우 1번 방식이 더 효과적일 것 같다는 생각이 들었습니다.

### Virtual DOM 사용 유무

React 컴포넌트가 반환하는 것을 실제 DOM이 아니라 화면에 무엇을 그릴지 선언적으로 표현한 가상의 엘리먼트들에 불과합니다.

다음과 같이 JSX라는 JS 확장 문법을 사용해서 JS 파일 내에서 HTML과 같은 문법을 작성할 수 있고

```jsx
function HelloMessage(props) {
	return <div className="greeting">Hello {props.name}</div>;
}
```

이는 결과적으로 babel에 의해 컴파일 되어 순수 자바스크립트 객체로 변환되며 이를 흔히 Virtual DOM이라고 부릅다. 이는 상태 값이 변경될 때마다 항상 새롭게 생성됩니다.

```jsx
function HelloMessage(props) {
	return _jsx('div', { className: 'greeting' }, 'Hello ', props.name);
}
```

React는 이렇게 생성한 Virtual DOM을 실제 DOM과 동기화시켜 줍니다.

`name`이 “React” ⇒ “Svelte” 될 경우 다음과 같은 일이 일어납니다.

1. `name`이 변경되었으므로 변경된 `name`(”Svelte”)을 기반으로 새로운 자바스크립트 객체를 생성합니다.
(`_jsx('div', { className: 'greeting' }, 'Hello ', 'Svelte')` 가 생성됩니다.)
2. 기존에 생성된 객체와 이번에 생성된 객체를 비교합니다.
- type - 이전: div ⇒ 현재: div(동일 ⇒ 유지) 
- props - 이전: `{ className: 'greeting' } ⇒ 현재: { className: 'greeting' }`(동일 ⇒ 유지)
- 첫 번째 children - 이전: 'Hello ' ⇒ 현재: 'Hello '(동일 ⇒ 유지)
- 두 번째 children - 이전: ‘React’ ⇒ 현재: ‘Svelte’(변경됨 ⇒ 변경)
3. div 엘리먼트는 유지하고, children만 변경합니다.
```js
divElement.textContent = 'Hello ' + ‘Svelte’;
```

결과적으로 변경된 부분만 실제 DOM에 반영하기는 하지만 Virtual DOM을 매번 생성하고 이전 결과물과 비교하는 것 자체가 비효율적입니다.

비록 대부분의 경우 사소하지만 이러한 불필요한 동작이 디폴트 동작인 것이라면 나중에 앱이 커지고 성능 문제가 생겼을 때 어떤 부분이 병목 현상의 원인이 되는지 파악하기 어렵습니다.

반면에 Svelte의 경우 VirtualDom을 사용하지 않습니다. Svelte는 컴파일러이기 때문에 빌드 타임 때 이미 어떤 부분이 변경될 수 있는지 알 수 있습니다. 
다음과 같은 코드를 빌드 타임에 생성해 주기 때문에 매번 Virtual DOM을 생성, 비교하는 과정이 없이 효율적이고 빠르게 화면을 업데이트합니다.

```jsx
// name이 변경될 경우 svelte 컴파일러가 다음과 같은 코드를 작성해줍니다.
if (changed.name) {	
	text.data = name;
}
```


> 💡 React는 Virtual DOM을 사용하기 때문에 빠르다”라는 잘못된 정보가 널리 퍼져있는데 이는 사실이 아닙니다. 정확히는 “충분히 빠르다”에 가깝습니다. 매번 Virtual DOM을 생성, 비교하지 않는 Svelte가 훨씬 빠릅니다.
> React core team에서 useMemo, useCallback, Memo 등의 여러 최적화 API를 제공한다는 것 자체가 React가 기본적으로 빠르지 않다는 증거입니다.
> - [Virtual DOM is pure overhead](https://svelte.dev/blog/virtual-dom-is-pure-overhead)

### 최상위 엘리먼트

React는 컴포넌트의 최상위 앨리먼트가 반드시 하나여야 합니다. ⇒ 불필요한 제약 조건이 필요합니다.

```jsx
function HelloWorld(){
	return (<> 
		<h1>Hello</h1>
		<p>World</p>
	</>)
}
```

반면에 Svelte는 그러한 제약 조건이 없습니다.

```html
<h1>Hello</h1>
<p>World</p>
```

React는 왜 반드시 하나여야 할까요?
    
React 컴포넌트가 반환하는 것은 객체이고 함수는 한 번에 2가지 이상을 반환할 수 없습니다.

```jsx

function HelloWorld(){
	return (
		<h1>Hello</h1> // _jsx('h1', null, 'Hello')
		<p>World</p> // _jsx('p', null, 'World')
	)
}

function HelloWorld(){
	// 감싸고 싶은 element가 없을 경우 fragment 또는 축약형 사용합니다.
	// _jsx(React.Fragment, null, _jsx('h1', null, 'Hello'), _jsx('p', null, 'World')) 
	return (<> 
		<h1>Hello</h1>
		<p>World</p>
	</>)
}
```
    
Svelte는 왜 제약이 없을까요?
    
Svelte는 컴포넌트에 실제(~~가상~~) 엘리먼트로 이루어진 HTML을 작성하기 때문에 React와 같은 제약이 필요 없게 됩니다.
    
```html
<h1>Hello</h1>
<p>World</p>
```
    

### State, Binding

```jsx
// React
import { useState } from 'react'

export default () => {
	const [a, setA] = useState(1);
	const [b, setB] = useState(2);
	
	function handleChangeA(event){
		setA(+event.target.value);
	}
	
	function handleChangeB(event){
		setB(+event.target.value);
	}
	
	return (
		<div>
			<input type="number" value={a} onChange={handleChangeA} />
			<input type="number" value={b} onChange={handleChangeB} />
			
			<p>
				{a} + {b} = {a + b}
			</p>
		</div>
	)
}
```

```html
// Svelte
<script>
	let a = 1;
	let b = 2;
</script>

<div>
	<input type="number" bind:value={a} />
	<input type="number" bind:value={b} />
	
	<p>
		{a} + {b} = {a + b}
	</p>
</div>
```

| React | Svelte |
| --- | --- |
| state를 사용하려면 useState를 명시적으로 작성 | 일반 자바스크립트 변수를 선언하면 컴파일러가 알아서 처리 |
| input의 값이 변경되었을 때 state를 변경하는 코드를 명시적으로 작성 | bind 지시자를 통해 다음 코드와 기능적으로 동일 (`value={state} on:input={(event) ⇒ state = +event.target.value`) |
| +를 통해 명시적으로 숫자로 변경 | bind 지시자를 통해 이 문제도 해결 |


> 💡 비슷한 점은 React도 useState를 최상단에서만 사용할 수 있듯이
> Svelte도 최상단에서 let으로 선언한 변수만이 상태값이 됩니다. 함수 안에서 let을 사용하면 그냥 순수 자바스크립트 코드와 동일합니다.

## 헷갈리기 쉬운 부분

### 반응성 구문 실행 시점

반응성 구문은 동기적으로 실행되지 않습니다.

```html
<script>
	let count = 0;
	$: doubledCount = count * 2;

	function increment(){
		count += 1;
	}
</script>

<button on:click={increment}>
	clicks: {count}
</button>
doubled: {doubledCount}
```

click 하면 숫자가 증가하는 간단한 어플리케이션

Svelte에서 상태 값으로부터 파생된 값이 필요할 경우 `$: statement`(반응성 구문)를 통해 이를 해결합니다.

> $:는 무엇일까요?
> $: 은 [Labled statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label)라는 JavaScript 문법입니다.
> 하지만 svelte는 컴파일러를 이용해서 본래의 JS가 제공하는 기능이 아닌 다른 목적으로 사용하고 있습니다.
    

하지만 주의해야 할 점이 있습니다. Svelte에서 동기적으로 변경되는 상태 값과는 달리 반응성 구문은 동기적으로 실행되지 않습니다. 모든 함수 실행이 종료되고 DOM이 변경되기 전에 실행됩니다.

### 반응성 구문 실행 순서

반응성 구문이 여러 개 있을 경우 코드의 순서와 관계없이 의존하는 값이 먼저 실행됩니다.

다음 코드의 경우 코드상으로는 시급 ⇒ 주급 ⇒ 일급 계산 코드가 실행되지만
svelte 컴파일러가 의존하는 값에 따라서 순서대로 실행시켜주기 때문에 (주급은 일급에 의존, 일급은 시급에 의존) 시급 ⇒ 일급 ⇒ 주급을 계산하는 순서로 실행이 됩니다.

> 이를 topological order에 따라 실행된다고 표현합니다.

```jsx
<script>
	let 시급 = 10000;

	$: 주급 = 일급 * 5;
	$: 일급 = 시급 * 8;
</script>

<label>
	시급
	<input type="number" bind:value={시급} />
</label>
<div>일급: {일급.toLocaleString()}원</div>
<div>주급: {주급.toLocaleString()}원</div>
```

### DOM 변경 시점

DOM은 동기적으로 변경되지 않습니다.

```jsx
<script>
	let framework = 'React';
</script>

<h1>I am using {framework} now.</h1>

<button on:click={() => {
	framework = 'Svelte';
	const h1 = document.querySelector('h1');
	console.log(h1.textContent); // "I am using React now."
}}>
	use Svelte
</button>
```

상태 값을 변경하고 즉시 DOM에 접근하여 `textContent` 를 출력하면 변경되기 전 값이 출력됩니다.
그 이유는 Svelte가 성능을 높이기 위해 변경된 상태 값들을 모두 기억해두었다가 한 번에 DOM을 변경하기 때문입니다.
그래서 DOM은 동기적으로 변경되지 않고 비동기적으로 변경됩니다.

만약에 상태 값을 변경하고 즉시 최신의 DOM에 접근하고 싶다면 다음과 같이 `tick`을 활용할 수 있습니다.

```js
import { tick } from 'svelte';

<button on:click={async () => {
	framework = 'Svelte';
	const h1 = document.querySelector('h1');
	await tick();
	console.log(h1.textContent); // "I am using Svelte now."
}}>
	use Svelte
</button>
```

### tick은 어떻게 동작할까요?

`tick`을 호출하면 프로미스가 반환됩니다. 근데 이 프로미스는 변경된 상태 값을 DOM에 반영하고 resolve 됩니다.

```jsx
function tick(){
	return new Promise((resolve) => {
		// 변경된 state를 DOM에 반영하는 코드
		resolve();
	});
}

// 만약 변경된 상태값이 없다면 즉시 resolve
function tick(){
	return Promise.resolve();
}
```

결과적으로 `await tick()`의 의미는 변경된 상태 값을 DOM에 반영할 때까지 기다린다는 의미입니다.

이벤트 핸들러에서 상태 값을 변경하고 그로 인해 DOM이 변경될 때 순서는 다음과 같습니다.

1. 이벤트 핸들러 실행
2. 상태 값 변경(동기)
3. 이벤트 핸들러 종료
4. 반응성 구문 실행
5. 변경된 모든 state로 한 번에 DOM 변경

그래서 2번과 3번 사이에서 console.log를 출력하려고 했을 때 반응성 구문이 실행되기 이전 값, DOM이 변경되기 이전 값이 출력되었던 것입니다.

그래서 `await tick()`으로 4, 5번이 실행될 때까지 기다린 후 출력하면 최신 값을 얻을 수 있었습니다.

### 추가적으로 보면 좋은 글

**[Svelte 3: Rethinking reactivity](https://svelte.dev/blog/svelte-3-rethinking-reactivity)**

이 글에서는 create-react-app 또는 Vite를 사용하지 않고, React 프로젝트를 설정하는 과정을 진행합니다. HTML, JavaScript 파일 생성부터 Webpack과 Babel을 활용한 번들링 및 JSX 사용까지 살펴봅니다.

React 프로젝트 직접 설정해보며 이해하기


## HTML 파일 생성

우선 다음과 같은 기본 `index.html` 파일을 생성해 줍니다. React 컴포넌트를 그릴 id가 root인 div 태그도 추가해 주었습니다.

```html
<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>리액트 프로젝트</title>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>
```

## JavaScript 파일 생성 및 연결

이제 JavaScript 파일을 생성하고

```javascript
console.log(document.getElementById("root"));
```

`script` 태그를 사용해 연결해 줍니다.

```html
<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>리액트 프로젝트</title>
    <script src="index.js"></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>
```

이제 `index.html` 을 실행해 보면 `null`이 로그에 찍히고 있음을 확인할 수 있습니다. 

```javascript
console.log(document.getElementById("root")); // null
```

그 이유는 브라우저가 HTML 파일을 한 줄 한 줄 읽으면서 파싱 하다가 `script` 태그를 보게 되면 파싱을 중단하고 `index.js` 파일을 다운로드 및 실행하며 이 과정이 종료되어야만 이어서 HTML을 파싱 하기 때문입니다. 
즉, `index.js` 파일이 실행될 때에는 root라는 id를 가진 `div` 태그가 DOM에 추가되기 전이기 때문에 `null` 이 찍힌 것입니다.

이를 해결하기 위해 `defer` 옵션을 활용할 수 있습니다. 
`defer` 옵션을 활용할 경우 HTML을 파싱하다가 `script` 태그를 보게되면 병렬적으로 `script` 태그에 명시된 JavaScript 파일을 다운로드받으며 HTML 파싱이 종료된 후 JavaScript 파일을 실행하기 때문에 위 문제를 해결할 수 있습니다.

```diff
-    <script src="index.js"></script>
+    <script defer src="index.js"></script>
```

```javascript
console.log(document.getElementById("root")); // <div id="root"></div>
```

## React 추가

React를 추가할 수 있는 방법에는 크게 두 가지가 있습니다.

1. CDN 링크 사용
2. npm 패키지 설치

### CDN 링크 사용

CDN 링크를 사용하여 React를 추가하기 위해서는 해당 코드를 참조하는 `script` 태그를 추가하면 됩니다. 
[이전 공식 문서](https://ko.legacy.reactjs.org/docs/cdn-links.html)를 참고하여 다음과 `script` 태그를 추가해 줍니다.

```html
<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>리액트 프로젝트</title>
    <script
      defer
      crossorigin
      src="https://unpkg.com/react@18/umd/react.development.js"
    ></script>
    <script
      defer
      crossorigin
      src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"
    ></script>
    <script defer src="index.js"></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>
```

`defer` 옵션을 사용하였기 때문에 `script` 태그에 명시된 JavaScript 코드를 병렬적으로 다운로드하고 HTML 파싱이 종료된 후 문서상의 순서에 따라 순차적으로 실행됩니다. 
따라서 `index.js`가 실행되는 시점에는 React, ReactDOM이 이미 다운로드 된 상태임이 보장됩니다.

그러면 `index.js`에는 `window` 객체에 React 및 ReactDOM 객체가 추가되며 이를 활용하여 코드를 작성할 수 있습니다.

```javascript
const root = ReactDOM.createRoot(document.getElementById("root"));

root.render("안녕");
```

그러면 브라우저로 `index.html`을 실행했을 때 정상적으로 루트에서 “안녕”이라는 텍스트를 보여주는 것을 확인할 수 있습니다.

```html
<div id="root">안녕</div>
```

#### CDN 링크를 사용할 때의 문제점

CDN 링크를 사용해서 프로젝트를 계속해서 확장한다고 생각할 경우 아쉬운 점이 많습니다. 예를 들면 다음과 같은 문제가 있습니다.

1. 사용하는 라이브러리가 HTML 파일의 `script` 태그에 명시되어 있기 때문에 어떤 JavaScript 파일에서 어떤 라이브러리에 의존하는지 파악하기 어렵습니다.
2. 라이브러리 코드의 일부만 사용할 경우에도 전체 라이브러리 코드를 다운로드 받기 때문에 사용자가 프로젝트를 실행하기 위해 실제 필요한 것보다 많은 JavaScript 코드를 다운로드 받야야합니다.
3. `script` 파일에 명시된 코드를 잘못된 순서로 실행할 경우 코드가 의도한대로 동작하지 않을 수 있습니다.
4. 많은 라이브러리에 의존할 경우 병렬적으로 다운로드해도 한 번에 개수 제한이 있기 때문에 로딩시간이 길어집니다.
5. `window` 전역 객체에 라이브러리 변수가 추가되기 때문에 변수의 충돌이 일어날 가능성이 있습니다.

### npm 패키지 설치

이러한 문제들도 해결하고 JavaScript 모듈을 효율적으로 사용하기 위해 npm으로 패키지를 설치하고 [Webpack](https://webpack.kr/)과 같은 번들러를 사용하는 것이 효과적입니다. 
이를 통해 코드 의존성을 명확히 파악하고 필요한 코드만 다운로드하여 프로젝트를 효율적으로 관리할 수 있습니다.

이제 필요한 npm 패키지를 설치해 보겠습니다.

```
// 1. npm init -y // 기본 package.json 파일을 생성합니다.
// 2. npm add react react-dom // react, react-dom 패키지를 설치합니다.
// 3. npm add -D webpack webpack-cli // webpack 그리고 webpack 명령어를 사용하기 위한 webpack-cli를 설치합니다.
// 개발 환경에서만 필요하기 때문에 -D 옵션을 사용해 devDependencies에 포함시켜주면 프로덕션 빌드 시 번들에 포함되지 않습니다.
```

여기까지 입력을 완료하면 다음과 같은 `package.json` 파일이 생성됩니다.

```json
{
  "name": "setting-up-react-project-from-scratch",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "webpack": "^5.90.3",
    "webpack-cli": "^5.1.4"
  }
}
```

이제 `webpack.config.js`를 생성하여 Webpack의 옵션을 설정해 주겠습니다.

```javascript
const path = require("path");

module.exports = {
  // Webpack을 통해 번들링하고자하는 파일인 index.js의 상대 경로를 입력해 줍니다.
  entry: "./index.js",
  output: {
    // 번들링이 완료된 JavaScript 파일을 어떤 폴더에 생성할지, 어떤 이름으로 생성할지 작성해 줍니다. 
    // dist라는 이름의 폴더에 생성하고 bundle.js라는 이름을 갖도록 설정해 주겠습니다.
    path: path.resolve(__dirname, "dist"),
    filename: "bundle.js",
  },
};
```

다시 기존의 `index.html` 파일로 돌아가 기존의 `script` 태그를 수정해 줍니다.

```diff
- <script
-     defer
-     crossorigin
-     src="https://unpkg.com/react@18/umd/react.development.js"
- ></script>
- <script
-     defer
-     crossorigin
-     src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"
- ></script>
- <script defer src="index.js"></script>
+ <script defer src="dist/bundle.js"></script>
```

`index.js` 파일로 돌아가 `import`로 필요한 모듈만 가져와서 다음과 같이 코드를 변경해 줍니다. 
CDN 링크를 사용했을 때와는 달리 의존성이 명확하게 드러나게 되었습니다.

```javascript
import { createRoot } from "react-dom/client";

const root = createRoot(document.getElementById("root"));

root.render("안녕");
```

다음 명령어를 입력하면 `webpack.config.js`에 작성한 옵션에 따라 번들링이 완료되고

```bash
npx webpack
```

브라우저에서 다음과 같은 결과를 확인할 수 있습니다.

```html
<div id="root">안녕</div>
```

### JSX 사용

JSX를 사용하여 JavaScript 파일에서 HTML 문법으로 마크업을 해보겠습니다.

```javascript
import { createRoot } from "react-dom/client";

const root = createRoot(document.getElementById("root"));

root.render(<h1>안녕</h1>);
```

기존의 `index.html` 을 `h1` 태그로 감싼 후 `npx webpack`을 통해 번들링을 시도하면 기대와는 달리 번들에 실패합니다.

Webpack은 JavaScript와 JSON 파일만 이해할 수 있습니다. 
Webpack의 입장에서는 `<h1>안녕</h1>`이 무엇인지 이해할 수 없습니다. 따라서 JSX 문법으로 작성된 코드를 JavaScript 코드로 변환해줄 필요가 있습니다. 
Webpack의 [로더](https://webpack.kr/concepts/loaders/) 그리고 babel과 babel에서 제공하는 [`@babel/preset-react`](https://babeljs.io/docs/babel-preset-react)를 사용하여 이를 해결해 보겠습니다.

우선 Webpack에서 babel을 사용할 수 있도록 `babel-loader`를 설치하고 JSX 문법으로 작성된 코드를 JavaScript 코드로 변환해주는 플러그인이 포함되어있는 `@babel/preset-react`을 설치해 줍니다.

```bash
npm add -D babel-loader @babel/preset-react
```

`webpack.config.js` 으로 돌아가 .js로 끝나는 모든 파일은 babel을 통해 변경 사항을 적용하도록 지시해 줍니다.

```javascript
const path = require("path");

module.exports = {
  entry: "./index.js",
  output: {
    filename: "bundle.js",
    path: path.resolve(__dirname, "dist"),
  },
  module: {
    rules: [{ test: /\.js$/, use: "babel-loader" }],
  },
};
```

그리고 다음과 같은 `babel.config.json` 을 생성하면 babel이 어떤 변경 사항을 적용할지 지시할 수 있습니다. 
해당 프리셋에는 JSX로 작성된 코드를 JavaScript로 작성된 코드로 변경하는 플러그인이 포함되어 있기 때문에 원하는 목적을 달성할 수 있습니다.

```json
{
  "presets": ["@babel/preset-react"]
}
```

이제 `npx webpack` 명령어를 통해 번들링을 시도하면 동작할 것이라고 생각했지만 HTML를 열어서 확인해 보면 빈 화면을 보게 됩니다. 
그리고 콘솔을 보면 다음과 같은 에러를 확인할 수 있습니다.

```javascript
Uncaught ReferenceError: React is not defined
```

그 이유는 다음과 같이 JSX 문법으로 작성한 코드는 babel이 `React.createElement`를 사용하는 JavaScript 코드로 변환해 주며 `index.js` 파일에서 React를 `import` 하지 않았기 때문입니다.

```javascript
// JSX 문법으로 작성한 코드
<h1>안녕</h1>

// babel이 변환해준 코드
React.createElement("h1", null, "안녕");
```

따라서 `index.js` 파일에 React 를 `import`하는 코드를 추가한 후 다시 `npx webpack` 명령어로 번들링 하면 다음과 같이 정상적으로 JSX 코드로 작성한 마크업과 일치하는 마크업이 루트에 추가되는 것을 확인할 수 있습니다.

```html
<div id="root">
   <h1>안녕</h1>
</div>
```

### React import 없이 사용하는 JSX

React v17부터는 JSX 문법으로 작성한 코드를 JavaScript 코드로 변환할 수 있는 더 좋은 방법을 지원하기 시작합니다.

새로운 방법을 사용하면

1. 더 이상 React를 import 하지 않아도 JSX 문법을 사용할 수 있습니다.
2. 변환된 코드의 번들 사이즈가 조금 더 줄어들게 됩니다.

다음과 같이 JSX 문법으로 코드를 작성하면

```jsx
function App() {
  return <h1>안녕</h1>;
}
```

`React.createElement` 가 아닌 `_jsx`라는 새로운 API를 사용하며 이는 babel에 의해 자동으로 주입됩니다.

```javascript
import {jsx as _jsx} from 'react/jsx-runtime';

function App() {
  return _jsx('h1', { children: '안녕' });
}
```

기존의 코드가 이 방법을 사용하도록 변경해 보겠습니다.

우선 더 이상 React를 `import`할 필요가 없기 때문에 `index.js`에서 제거해 줍니다.

```diff
import { createRoot } from "react-dom/client";
- import React from 'react';

const root = createRoot(document.getElementById("root"));

root.render(<h1>안녕</h1>);
```

그리고 `babel.config.json`에서 `runtime`이라는 옵션을 `automatic`으로 설정을 해줍니다.

```json
{
  "presets": [
    [
      "@babel/preset-react",
      {
        "runtime": "automatic"
      }
    ]
  ]
}
```

`npx webpack` 으로 번들링 한 후 확인해 보면 동일한 결과물을 확일할 수 있습니다.

```html
<div id="root">
   <h1>안녕</h1>
</div>
```


이 글은 Next.js 서버 렌더링 전략에 대해 알아보고 어떤 메커니즘으로 변경이 이루어지는지 알아봅니다.

Next.js 서버 렌더링 전략



Next.js [App Router](https://nextjs.org/docs/app)로 웹 애플리케이션을 개발할 때 활용할 수 있는 서버 렌더링 전략에는 크게 두 가지가 있습니다.

1. 정적 렌더링(Static Rendering)
2. 동적 렌더링(Dynamic Rendering)

각 렌더링 전략은 무엇이 다른지, 어떻게 변경할 수 있는지 알아보겠습니다.

## 정적 렌더링(Static Rendering)

정적 렌더링을 활용하면 페이지를 빌드 타임에 생성하고 생성된 페이지를 CDN과 같은 중간 서버에 캐시 할 수 있습니다. 
그 후 사용자가 페이지를 요청하면 서버에 직접 요청하는 대신 사용자와 가장 가까운 CDN으로부터 캐시 된 응답을 받게 됩니다.

![정적 렌더링은 빌드 타임에 페이지를 생성합니다.](/static/images/next-js-server-rendering-strategies/static-rendering.png)

<br/ >

사용자의 요청에 빠르게 응답할 수 있다는 장점을 가지고 있지만, 빌드 타임에 페이지를 생성해야 하기 때문에 어떤 데이터를 보여줘야 할지 미리 알 수 있는 경우 활용하기에 좋습니다. 
예를 들어 공식 문서 페이지, 관리자가 작성하는 블로그 페이지의 경우 어떤 데이터를 보여줘야 할지 빌드 타임에 알 수 있으며 사용자가 요청함에 따라 변하지 않기 때문에 정적 렌더링을 활용하기에 좋습니다.

## 동적 렌더링(Dynamic Rendering)

하지만 실제로 서비스를 개발하다 보면 빌드 타임에 페이지를 렌더링 하는데 필요한 모든 데이터를 미리 알 수 있는 경우는 많지 않습니다. 
예를 들어, 이커머스 서비스에서 사용자에 따라 맞춤화된 추천상품을 보여줘야 하는 경우 빌드 타임에는 사용자가 누구일지 알 수 없기 때문에 미리 페이지를 생성할 수 없습니다. 
이 경우에는 런타임에(혹은 사용자 요청 시) 페이지를 생성하는 동적 렌더링 전략을 활용해야 합니다.

서버를 하나만 사용했을 경우 다음과 같이 나타낼 수 있습니다.

![동적 렌더링은 런타임에 페이지를 생성합니다.](/static/images/next-js-server-rendering-strategies/dynamic-rendering.png)

<br/ >

런타임에 페이지를 생성하기 때문에 정적 렌더링보다는 지연 시간이 길지만 런타임만 알 수 있는 데이터 활용하여 페이지를 생성할 수 있습니다. 
예를 들어, 사용자가 누구인지 확인하고 해당 사용자가 좋아할 만한 추천 상품을 페이지에 포함하여 응답을 보내는 것이 가능해집니다.

## Next.js의 렌더링 전략

기본적으로 Next.js는 옵션을 따로 설정하지 않으면 자동으로 정적, 동적 렌더링중 더 적합한 전략으로 페이지를 생성해 줍니다.

### 정적 렌더링 - 디폴트

기본적으로 Next.js는 퍼포먼스를 위해 정적 렌더링을 기본 렌더링 전략으로 선택합니다.

### 동적 렌더링

**빌드 타임에 알 수 없는 값을 사용할 경우**

빌드 타임에 미리 알 수 없는 데이터를 사용하는 경우, 즉, 런타임에만 알 수 있는 값(동적 데이터)을 사용할 경우 동적 렌더링 전략을 사용하도록 변경합니다.

런타임에만 알 수 있는 값들은 다음과 같습니다.

1. [HTTP 쿠키](https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies)
2. [HTTP 헤더](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers)
3. [URLSearchParams](https://developer.mozilla.org/ko/docs/Web/API/URLSearchParams)

페이지를 렌더링하는 코드에 위 값을 읽는 코드가 포함되어 있을 경우 Next.js는 해당 페이지를 런타임에 생성하도록(동적 렌더링) 변경합니다.
실제로는 Next.js가 동적 데이터를 읽었는지 트레킹해야하기 때문에 다음과 같이 Next.js에서 제공하는 API를 사용해야 합니다.

1. [cookies](https://nextjs.org/docs/app/api-reference/functions/cookies)
2. [headers](https://nextjs.org/docs/app/api-reference/functions/headers)
3. [페이지 컴포넌트의 props](https://nextjs.org/docs/app/api-reference/file-conventions/page)

Next.js 코드에서 cookies 함수를 확인해 보면 trackDynamicDataAccessed 함수로 동적 데이터 접근을 트레킹하고 있다는 것을 확인해 볼 수 있습니다.

```ts
export function cookies() {
  // 생략

  if (staticGenerationStore) {
    if (staticGenerationStore.forceStatic) {
      // force-static 옵션을 사용했을 경우 cookies 함수를 사용해도 동적 데이터에 접근한 것을 트레킹하지 않음
      return RequestCookiesAdapter.seal(new RequestCookies(new Headers({})))
    } else {
      // 아닐 경우 동적 데이터에 접근 한 것을 트레킹 함
      trackDynamicDataAccessed(staticGenerationStore, callingExpression)
    }
  }

  // 생략
}
```

**[동적 라우트 (Dynamic Routes)](https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes)를 사용할 경우**

동적 라우트를 사용하는 페이지의 경우, 빌드 타임에는 어떠한 `categorySlug`가 있는지 모르기 때문에 동적 렌더링으로 페이지를 생성합니다.

```ts
// `/category/[categorySlug]/page.tsx`
export default function Page({ params }: { params: { `categorySlug`: string } }) {
  const category = await fetchCategory(params.categorySlug);

  return ...;
}

```

동적 라우트를 사용하면서 정적 렌더링으로 페이지를 생성하고 싶다 [generateStaticParams](https://nextjs.org/docs/app/api-reference/functions/generate-static-params)
를 사용하여 어떤 params로 정적 페이지를 생성할지 Next.js에게 알려줘야 합니다.

**캐시 되지 않은 데이터를 사용할 경우**

다음과 같이 fetch API를 no-store 라는 cache 옵션과 함께 사용할 경우 캐시를 저장하지도 않고 찾아보지도 않기 때문에 항상 서버에서 최신 리소스를 가져옵니다. 
만약 빌드 타임에 페이지를 생성한다면 최신 리소스를 가져올 수 없기 때문에 이 경우에도 Next.js는 자동으로 동적 렌더링 전략을 사용하도록 변경해 줍니다.

```ts
export default function Page() {
  const data = await fetch("https://jsonplaceholder.typicode.com/todos/1", { cache: "no-store" });

  return ...;
}
```

이 글은 JavaScript로 시작하여 TypeScript를 활용하여 객체 속성에 안전하게 접근하는 getByPath 함수를 구현하는 방법과, 타입 추론 및 성능 최적화에 대한 내용을 다룹니다.

TypeScript로 안전하게 객체 속성에 접근하기: getByPath 함수 구현과 타입 추론


이 글에서는 다음과 같이 객체와 path가 주어졌을 때 해당 path의 값을 반환하는 `getByPath` 함수를 TypeScript를 활용하여 구현해 보겠습니다.

```ts
const person = {
  name: {
    firstName: "Dongho",
    lastName: "Kim",
  },
  gender: "male",
};

const result = getByPath(person, "name.lastName");
// "Kim"
```

## JavaScript로 구현

우선 타입은 생각하지 않고 JavaScript로 기능만 구현해 보겠습니다. 

주어진 `path`를 `split` 메서드를 이용하여 `property`로 이루어진 배열로 만들 수 있습니다.
따라서 `properties`로 반복문을 돌리면 원하는 객체의 값을 깊이에 상관없이 가져올 수 있습니다.

```js
function getByPath(obj, path) {
  const properties = path.split(".");

  let result = obj;
  for (const property of properties) {
    result = result[property];
  }
  return result;
}
```

생각했던 대로 동작은 하지만 JavaScript로 작성했기 때문에 타입적 이점은 얻을 수 없습니다.

```js
const result = getByPath(person, "name.lastName");
// "Kim"

// 1. 잘못된 인자를 전달하는 것을 방지할 수 없다.
const result = getByPath("hello", "name.lastName") // 객체 대신 다른 값 전달 가능
const result = getByPath(person, "name.lastNaem") // `path`에 올바르지 않은 인자 전달 가능

// 2. 반환되는 타입을 알 수 없다.
const result = getByPath(person, "name.lastName");
// ^? any
```

## TypeScript로 구현

이제 적합한 인자만 전달할 수 있고 반환되는 타입도 올바르게 추론되도록
위 함수를 TypeScript를 이용하여 다시 작성해 보겠습니다.

우선 `obj` 파라미터의 경우 key의 타입은 `string`이고 value의 타입은 어떤 타입일지 모르기 때문에 `Record<string, unknown>`으로 선언할 수 있습니다.
또한 `path`의 경우 `string`으로 선언할 수 있습니다.

```ts
function getByPath(obj: Record<string, unknown>, path: string) {
  const properties = path.split(".");

  let result: any = obj; // result는 어떤 값이 올지 모르기 때문에 any로 선언해 줍니다.
  for (const property of properties) {
    result = result[property];
  }
  return result;
}
```

위와 같이 타입을 선언하면 잘못된 타입의 인자가 전달되는 것을 방지할 수 있습니다. 

```ts
const result = getByPath("hello", "name.lastName")
// 첫 번째 인자에 `Record<string, unknown>` 타입이 아닌 값 전달 시 TypeScript 에러 발생

const result = getByPath(person, 123)
// 두 번째 인자에 `string` 타입이 아닌 값 전달 시 TypeScript 에러 발생
```

하지만 오타를 내서 올바르지 않은 값이 `path`의 인자로 전달됐을 때는 에러가 발생하고 있지 않습니다.

```ts
const result = getByPath(person, "name.lastNaem") // TypeScript 에러 발생 X
```

이 부분을 해결하기 위해서는 2가지가 수행되어야 합니다.

1. `getByPath` 함수의 첫번째 인자로 전달받은 값의 타입을 추론한다.
2. 추론된 타입으로부터 `path`의 타입을 계산한다.

### 전달받은 인자로부터 타입 추론

다음과 같이 타입 파라미터 `T`를 선언하고 `Record<string, unknown>`에 할당 가능한 타입만 전달받을 수 있도록 제약 사항을 둡니다.
그리고 파라미터 `obj`의 타입을 `T`로 선언해 줍니다. 그러면 함수를 호출할 때 타입 인자를 전달해 주지 않더라도 TypeScript가 `obj`의 인자로 전달된 값으로부터 타입 `T`를 추론해 줍니다. 

```ts
function getByPath<T extends Record<string, unknown>>(obj: T, path: string) {
  const properties = path.split(".");

  let result: any = obj;
  for (const property of properties) {
    result = result[property];
  }
  return result;
}

// getByPath(person, "name.firstName")를 호출했을 때 추론된 `T`의 타입은 다음과 같습니다.
// {
//     name: {
//         firstName: string;
//         lastName: string;
//     };
//     gender: string;
// }
```

### `path` 타입 계산

`person`이 첫 번째 인자로 전달되었을 때 추론되길 원하는 `path`의 타입은 다음과 같습니다.

```ts
type Path = "name" | "name.firstName" | "name.lastName" | "gender";
```

추론된 타입 `T`로부터 `path`의 타입을 계산하기 위한 아이디어는 다음과 같습니다.

모든 키/값을 순회하면서
- 값의 타입이 `Record<string, unknown>`에 할당 가능한 경우 => 키의 타입을 반환 + 재귀 실행
- 값의 타입이 `Record<string, unknown>`에 할당 가능하지 않은 경우 => 키의 타입을 반환

이제 이 아이디어를 기반으로 추론된 타입 `T`로 부터 `path`의 타입을 계산하는 유틸리티 타입 `PropertyPath`를 구현해 보겠습니다. 

1. 타입 파라미터 T에는 `Record<string, unknown>`에 할당 가능한 타입만 인자로 전달받을 수 있도록 제약사항을 둡니다.

```ts
type PropertyPath<T extends Record<string, unknown>> = T;
```

2. 모든 키/값을 순회할 수 있도록 `T`를 리팩토링합니다.

```ts
type PropertyPath<T extends Record<string, unknown>> = {
  [K in keyof T]: T[K];
};
```

3. 목표는 객체 타입을 반환하는 것이 아닌 유니언 타입을 반환하는 것입니다.
따라서, 즉시 객체의 키 타입으로 접근하여 값의 타입으로 이루어진 유니언을 반환하도록 합니다.

```ts
type PropertyPath<T extends Record<string, unknown>> = {
  [K in keyof T]: T[K];
}[keyof T];

// person
// ^? 
// {
//     name: {
//         firstName: string;
//         lastName: string;
//     };
//     gender: string;
// }

// type Result = PropertyPath<typeof person>
// ^? { firstName: string; lastName: string; } | string
```

여기까지 했을 때 다음과 같이 객체의 값의 타입으로 이루어진 유니언이 반환됩니다.
즉, `T[K]`로 이루어진 유니언 타입이 반환되므로 지금부터 `T[K]` 부분을 적절히 변경하면 될 것입니다. 

4. 값의 타입이 객체인 경우 일단 임시로 "???"을 반환하고 아닌 경우 키의 타입을 반환합니다.

```ts
type PropertyPath<T extends Record<string, unknown>> = {
  [K in keyof T]: T[K] extends Record<string, unknown> ? "???" : K;
}[keyof T];

// person
// ^? 
// {
//     name: {
//         firstName: string;
//         lastName: string;
//     };
//     gender: string;
// }

// `name`의 값의 타입은 Record<string, unknown>에 할당 가능하기 때문에 "???"이 반환되고
// `gender`의 값의 타입은 Record<string, unknown>에 할당 가능하지 않기 때문에 "gender"(K)가 반환됩니다.
// type Result = PropertyPath<typeof person>;
// ^? "???" | "gender"
```

5. 목표는 `"???"` 대신에 `"name" | "name.firstName" | "name.lastName"` 을 반환하도록 하는 것입니다.
일단 `K` 또는 `"???"`을 반환하도록 하면 목표에 조금 더 다가갈 수 있습니다. 

```ts
type PropertyPath<T extends Record<string, unknown>> = {
  [K in keyof T]: T[K] extends Record<string, unknown> ? K | "???" : K;
}[keyof T];

// type Result = PropertyPath<typeof person>;
// ^? "???" | "name" | "gender"
```

6. 재귀와 템플릿 리터럴 타입을 활용하여 `"???"` 대신 `"name.firstName" | "name.lastName"`이 반환되도록 변경해 줍니다.

```ts
type PropertyPath<T extends Record<string, unknown>> = {
  [K in keyof T]: T[K] extends Record<string, unknown>
    ? K | `${K}.${PropertyPath<T[K]>}`
    : K;
}[keyof T];

type Result = PropertyPath<typeof person>;
// ^? "name" | "gender" | "name.firstName" | "name.lastName"
```

7. 6번까지 작성했다면 "Type 'K' is not assignable to type 'string | number | bigint | boolean | null | undefined'." 라는 TypeScript 에러가 발생합니다.
이는 타입 `K`가 `string | number | symbol`로 추론되며 `symbol` 타입으로는 템플릿 리터럴 타입을 작성할 수 없기 때문입니다. 

> 키값의 타입이 `string | number | symbol`인 경우에도 JavaScript는 객체를 인덱싱할 때 `string`으로 변환하기 때문에 `Record<string, unknown>`에 할당 가능합니다. 이러한 이유로 타입 `K`가 `string | number | symbol`로 추론됩니다.

이는 `string` 타입과 인터섹션 타입을 활용하여 다음과 같이 해결할 수 있습니다.

```ts
type PropertyPath<T extends Record<string, unknown>> = {
  [K in keyof T & string]: T[K] extends Record<string, unknown>
    ? K | `${K}.${PropertyPath<T[K]>}`
    : K;
}[keyof T & string];
```

이제 유틸리티 타입 `PropertyPath`을 활용하여 `getByPath` 함수의 타입을 선언해 주면
`path`의 타입을 정확하게 추론되므로 잘못된 인자를 전달할 경우 TypeScript 에러가 발생합니다. 

```ts
function getByPath<T extends Record<string, unknown>>(
  obj: T,
  path: PropertyPath<T>
) {
  const properties = path.split(".");

  let result: any = obj;
  for (const property of properties) {
    result = result[property];
  }
  return result;
}

getByPath(person,"name.firstNaem") // TypeScript 에러 발생
```

### 반환 타입 선언

아직 반환되는 타입은 `any`로 추론되고 있기 때문에 이를 개선해 보겠습니다.

```ts
const result = getByPath(person, "name.firstName");
// ^? any
```

`getByPath` 함수의 반환 타입을 계산해주는 유틸리티 타입을 `GetByPathReturn`이라는 이름으로 만들어줍니다.
반환 타입을 계산하기 위해서는 `obj`, `path`에 어떠한 인자가 전달되었는지 알아야 합니다. 따라서 2가지 타입을 전달받아야합니다.
이 2가지 타입을 각각 `T`, `U`라는 타입 파라미터를 만들어서 전달받도록 해줍니다.

```ts
type GetByPathReturn<T extends Record<string, unknown>, U extends PropertyPath<T>> = "???"
```

타입 `U`가 단일 속성을 포함하고 있는지 여러 속성을 포함하고 있는지에 따라 다른 타입을 반환하면 될 것이고
이는 타입 `infer`와 `.`을 이용하여 구현할 수 있습니다.

여러 속성을 포함하고 있다면 일단 "???"을 반환하고 단일 속성일 경우 `T[U]`을 통해 값의 타입을 반환해 줍니다.

```ts
type GetByPathReturn<
  T extends Record<string, unknown>,
  U extends PropertyPath<T>
> = U extends `${infer TProperty}.${infer TRestPropertyPath}` ? "???" : T[U];
```

이제 재귀를 이용하여 `path`가 여러 속성을 포함할 경우를 처리해 줍니다.

```ts
type GetByPathReturn<
  T extends Record<string, unknown>,
  U extends PropertyPath<T>
> = U extends `${infer TProperty}.${infer TRestPropertyPath}`
  ? GetByPathReturn<T[TProperty], TRestPropertyPath>
  : T[U];
```

위까지 했다면 "type `T[TProperty]` does not satisfy the constraint `Record<string, unknown>`"라는 TypeScript 에러가 발생합니다.

`PropertyPath<T>`에 의해서 `path`에는 값의 타입이 `Record<string, unknown>`을 만족시키는 경우에는 .을 통해 중첩된 속성을 입력할 수 있습니다.
따라서 `T[TProperty]`는 항상 `Record<string, unknown>`에 할당 가능합니다. 하지만 TypeScript는 이 사실을 모르기 때문에 발생하는 에러이므로 다음과 같이 처리해줄 수 있습니다.

```ts
type GetByPathReturn<
  T extends Record<string, unknown>,
  U extends PropertyPath<T>
> = U extends `${infer TProperty}.${infer TRestPropertyPath}`
  ? T[TProperty] extends Record<string, unknown>
    ? GetByPathReturn<T[TProperty], TRestPropertyPath>
    : never // T[TProperty]는 항상 Record<string, unknown>에 할당 가능하기 때문에 never에 도달하는 경우는 없습니다. 
  : T[U];
```

이제 `GetByPathReturn` 타입을 이용하여 `getByPath` 함수가 반환하는 타입을 선언해 주면
다음과 같이 반환된 값의 타입이 올바르게 추론됩니다.

```ts
function getByPath<
  T extends Record<string, unknown>,
  U extends PropertyPath<T>
>(obj: T, path: U): GetByPathReturn<T, U> {
  const properties = path.split(".");

  let result: any = obj;
  for (const property of properties) {
    result = result[property];
  }
  return result;
}

const result = getByPath(person, "name");
// ^? { firstName: string; lastName: string; }
```

## 성능 개선

재귀를 사용하는 타입의 경우 성능에 부정적인 영향을 줄 수 있습니다.
예를 들어 타입 검사 시간이 늘어나거나 IDE가 제공하는 자동 완성 기능이 지나치게 느려질 수 있습니다.
따라서 적절한 수만큼만 재귀가 일어나도록 변경하는 방법을 사용할 수 있습니다.

적절한 수만큼만 재귀가 일어나도록 하는 방법은 매우 간단합니다.
우선 숫자를 입력했을 때 입력받은 숫자보다 1만큼 작은 수를 반환하도록 튜플 타입을 선언합니다.

```ts
type Prev = [-1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
```

이러면 입력 및 반환 타입은 다음과 같습니다.

```ts
type Result = Prev[2];
// ^? 1

type Result = Prev[1];
// ^? 0

type Result = Prev[0];
// ^? -1
```

이제 타입이 `-1`일 경우 반복을 그만하고 아닐 경우 반복을 하도록 작성하면 됩니다.

```ts
// U의 기본값이 9이므로 10번만 실행되고 초과 시 never를 반환합니다.
type PropertyPath<
  T extends Record<string, unknown>,
  U extends Prev[number] = 9
> = U extends -1
  ? never
  : {
      [K in keyof T & string]: T[K] extends Record<string, unknown>
        ? K | `${K}.${PropertyPath<T[K], Prev[U]>}` // 여기서 Prev[U]를 통해 1 작은 값을 두 번째 인자로 전달해줍니다. 
        : K;
    }[keyof T & string];
```

`GetByPathReturn` 타입도 같은 방법으로 변경할 수 있습니다.

```ts
type GetByPathReturn<
  T extends Record<string, unknown>,
  U extends PropertyPath<T>,
  V extends Prev[number] = 9
> = V extends -1
  ? never
  : U extends `${infer TProperty}.${infer TRestPropertyPath}`
  ? T[TProperty] extends Record<string, unknown>
    ? GetByPathReturn<T[TProperty], TRestPropertyPath, Prev[V]>
    : never
  : T[U];
```

또는 다음과 같이 배열을 이용하여 구현할 수도 있습니다. 
이렇게 구현했을 경우 `Prev` 타입을 일일이 구현할 필요도 없고 extends 뒤에 나오는 숫자만큼만 실행되기 때문에 이해하기 쉽습니다.

```ts
type PropertyPath<
  T extends Record<string, unknown>,
  U extends unknown[] = []
> = U["length"] extends 10
  ? never
  : {
      [K in keyof T & string]: T[K] extends Record<string, unknown>
        ? K | `${K}.${PropertyPath<T[K], [...U, unknown]>}`
        : K;
    }[keyof T & string];

// U["length"] extends 0일 경우 => 실행되지 않음
type Result = PropertyPath<{ a: { b: { c: "d" } } }>;
// ^? never

// U["length"] extends 1일 경우 => 1번 실행
type Result = PropertyPath<{ a: { b: { c: "d" } } }>;
// ^? "a"

// U["length"] extends 2일 경우 => 2번 실행
type Result = PropertyPath<{ a: { b: { c: "d" } } }>;
// ^? "a" | "a.b"

// U["length"] extends 3일 경우 => 3번 실행
type Result = PropertyPath<{ a: { b: { c: "d" } } }>;
// ^? "a" | "a.b" | "a.b.c"
```

객체가 10번이 넘게 중첩되는 경우는 흔하지 않으므로 10번 정도만 실행하도록 타협을 하면 성능도 챙길 수 있고 불필요하게 코드를 반복해서 작성할 필요도 없게 됩니다.
만약 더 많은 중첩이 있는 경우 extends 뒤의 숫자만 적절히 변경해주면 됩니다.

실제로 재귀를 활용하는 타입으로 인해 성능 문제를 겪은 적이 있었고 이러한 방법을 통해 해결한 경험이 있습니다.
혹시 갑자기 타입 검사 또는 자동 완성 기능이 느려졌다면 재귀를 활용하는 타입에 문제가 있는 것은 아닌지 확인해 보는 것도 좋을 것 같습니다.


TypeScript에서의 {}, Object, object로 타입을 선언하는 방법과 각각의 차이점을 알아봅니다.

TypeScript에서의 {} vs Object vs object


이 글에서는 TypeScript에서 `{}`, `Object`, `object`를 이용하여 타입을 선언했을 때 어떠한 차이가 있는지 알아보겠습니다.

## `{}` 타입

`{}`으로 타입을 선언했을 경우 외형만으로는 비어있는 객체라고 오해하기 쉽지만 사실은 그렇지 않습니다.
TypeScript에서 `{}`는 any non-nullish value를 의미합니다. 즉, `undefined` 와 `null`을 제외한 모든 타입은 `{}` 타입에 할당 가능합니다.

```ts
// `undefined` 와 `null`은 할당 불가능
const test1: {} = undefined; // Type `undefined` is not assignable to type `{}`.
const test2: {} = null; // Type `null` is not assignable to type `{}`

// `undefined` 와 `null`을 제외한 모든 원시값 할당 가능
const test3: {} = true;
const test4: {} = 0;
const test5: {} = BigInt(0);
const test6: {} = "hello";
const test7: {} = Symbol();

// 모든 객체값 할당 가능
const test8: {} = () => {};
const test9: {} = new Date();
const test10: {} = new Set();
const test11: {} = new Map();
// ... 나머지 객체값 생략
```

> JavaScript에는 크게 원시값과 객체값이 있습니다..
> 원시값에는 `undefined`, `null`, `boolean`, `number`, `bigint`, `string`, `symbol` 타입의 값들이 포함됩니다.
> 객체값에는 원시값을 제외한 모든 값들이 포함됩니다.

이러한 사실을 이용해서 TypeScript가 기본적으로 제공해 주는 유틸리티 타입인 `NonNullable`은 다음과 같이 선언되어 있습니다.

```ts
type NonNullable<T> = T & {};
```

주어진 타입 `T`와 `null`, `undefined`를 제외한 모든 타입의 공통 타입이므로 `T`에서 `undefined`와 `null`이 제거된 타입이 반환되는 것입니다.

하지만 `{}`는 직관적이지 않고 이 사실을 모르는 사람의 입장에서 봤을 때 가독성이 좋지 않기 때문에 eslint에서는 `{}` 대신 `NonNullable<unknown>`을 사용하는 것을 권장하기도 합니다.

## `Object` 타입

`Object`도 `{}`로 타입을 선언하는 것과 동일하다고 보면 됩니다. 이 경우에도 `{}`와 마찬가지로 `undefined`, `null`을 제외한 모든 값이 할당 가능합니다.

```ts
// `undefined` 와 `null` 할당 불가능
const test1: Object = undefined; // Type `undefined` is not assignable to type `Object`.
const test2: Object = null; // Type `null` is not assignable to type `Object`

// `undefined` 와 `null`을 제외한 모든 원시값 할당 가능
const test3: Object = true;
const test4: Object = 0;
const test5: Object = BigInt(0);
const test6: Object = "hello";
const test7: Object = Symbol();

// 모든 객체값 할당 가능
const test8: Object = () => {};
const test9: Object = new Date();
const test10: Object = new Set();
const test11: Object = new Map();
// ... 나머지 객체값 생략
```

## `object` 타입

이번에는 `object`로 타입을 선언하는 경우를 알아보겠습니다. 위와는 다르게 `Object`가 아닌 `object`입니다.

위에서 JavaScript values는 원시값과 객체값으로 나누어진다는 것을 간략하게 설명했었습니다.
`object`로 타입을 선언했을 경우 모든 객체값이 할당이 가능하다고 생각하면 됩니다.

```ts
// 모든 원시값 할당 불가능
const test1: object = undefined; // Type `undefined` is not assignable to type `object`.
const test2: object = null; // Type `null` is not assignable to type `object`.
const test3: object = true; // // Type `boolean` is not assignable to type `object`.
const test4: object = 0; // Type `number` is not assignable to type `object`.
const test5: object = BigInt(0); // Type `bigint` is not assignable to type `object`.
const test6: object = "hello"; // Type `string` is not assignable to type `object`.
const test7: object = Symbol(); // Type `symbol` is not assignable to type `object`.

// 모든 객체값 할당 가능
const test8: object = () => {};
const test9: object = new Date();
const test10: object = new Set();
const test11: object = new Map();
```

만약 `object` 타입이 객체값을 의미하는 것이 아니라 "순수 JavaScript 객체"를 의미하는 것으로 오해한다면 적합한 타입 선언을 하지 못할 수도 있습니다.

> "순수 JavaScript 객체"는 `{ age: 20 }`와 같이 흔히 중괄호를 이용하여 생성하는 값을 표현하기 위해 사용하겠습니다.

예를 들어 어떠한 "순수 JavaScript 객체"도 허용하는 함수를 만들다고 했을 때 위와 같은 사실을 모른다면 다음과 같이 타입을 선언하게 될 것입니다.

```ts
function doSomething(obj: object) {
  //
}
```

그러면 다음과 같은 객체값을 입력해도 에러가 발생하지 않기 때문에 예상하지 못한 버그가 런타임에 발견될 수 있습니다. 

```ts
doSomething(() => {});
doSomething(new Date());
doSomething(new Set());
doSomething(new Map());
```

그렇기 때문에 "순수 JavaScript 객체"만 허용하고 싶은 경우 `object`를 사용하지 않고 `Record`를 이용해서 다음과 같이 타입을 선언할 수 있습니다.

```ts
function doSomething(obj: Record<string, unknown>) {
  //
}
```

또한 비어있는 객체만 허용하고 싶은 경우에는 `never`을 활용할 수 있습니다. 

```ts
const emptyObject: Record<string, never> = {};
```

## 결론 

이렇게 해서 오늘은 `{}`, `Object`, `object`를 이용해서 타입을 선언했을 때 어떤 것이 다른 지 알아봤습니다. 

- `{}` 타입: `undefined`, `null`을 제외한 모든 값이 할당 가능하다.
- `Object` 타입: `{}` 타입과 동일하다.
- `object` 타입: 원시값을 제외한 모든 값이 할당 가능하다.

Zod에서 객체를 어떻게 검증하는지 알아봅니다.

z.object() 구현하기


- [#1: z.string() 구현하기](/blog/implementing-zod-using-typescript-1)
- [#3: z.string() min, max 메서드 구현하기](/blog/implementing-zod-using-typescript-2)
- [#3: z.enum(), z.optional() 구현하기](/blog/implementing-zod-using-typescript-3)
- [#4: z.object() 구현하기](/blog/implementing-zod-using-typescript-4)

오늘은 Zod가 어떻게 객체를 검증하는지 `ZodObject`를 구현하면서 알아보자.

## 동작 확인하기

우선 다음과 같이 객체 스키마를 생성하고 데이터를 검증할 수 있다.

```ts
const personSchema = z.object({
  name: z.string(),
  age: z.number(),
});

personSchema.safeParse({
    name: 'zod',
    age: 22,
}) // 검증 성공
```

만약 타입이 다르거나 스키마에 있는 프로퍼티가 데이터에 없다면 검증에 실패한다.

```ts
personSchema.safeParse({
    name: 'zod',
    age: true,
}) // 검증 실패 - 숫자 대신 불리언이 들어옴

personSchema.safeParse({
    name: 'zod',
}) // 검증 실패 - age가 없음
```

여분의 키(데이터에는 있지만 스키마에는 없는 키)가 있다면 3가지 옵션이 있다.

1. 기본 값은 `strip`이다. 이 경우 여분의 키는 검증을 하지 않고 결과에도 포함시키지 않는다.

```ts
const result = personSchema.safeParse({
  name: "zod",
  age: 22,
  hobby: "축구",
});
if (result.success) {
  result.data;
  // { name: "zod", age: 22 }
}
```

2. 만약 여분의 키를 검증하지는 않지만 결과에 포함시키고 싶은 경우 `passthrough` 옵션을 사용할 수 있다.

```ts
const result = personSchema.passthrough().safeParse({
  name: "zod",
  age: 22,
  hobby: "축구",
});
if (result.success) {
  result.data;
  // { name: "zod", age: 22, hobby: "축구" }
}
```

3. 마지막으로 여분의 키를 허용하고 싶지 않은 경우 `strict` 옵션을 사용할 수 있다.

```ts
personSchema.strict().safeParse({
  name: "zod",
  age: 22,
  hobby: "축구",
}); // 검증 실패 - 여분의 키(hobby)가 포함되어 있음
```

## 구현해보기

이제 위에서 살펴본 대로 동작하도록 구현해 보자. 입력받는 객체 스키마를 `shape`이라는 변수에 저장하고
여분의 키를 어떻게 처리할지에 대한 옵션을 `extraKeyStrategy`라는 변수에 저장하면 다음과 같이 구현할 수 있다.

```ts
type ExtraKeyStrategy = "strip" | "passthrough" | "strict";

// shape은 어떤 것이 들어올지 모르기 때문에 타입 파라미터를 선언해 추론되도록 하고
// 키는 string, 값은 어떠한 ZodType 이어도 가능하도록 해주자.
// 또한 { name: ZodString.create() }으로 스키마를 생성했을 때 { name: string }이 추출되어야 하므로
// ZodType에 { [K in keyof T]: T[K]["_output"] }을 전달해 준다.
class ZodObject<T extends Record<string, ZodType<any>>> extends ZodType<{
  [K in keyof T]: T[K]["_output"];
}> {
  readonly shape: T;
  readonly extraKeyStrategy: ExtraKeyStrategy;

  constructor({
    shape,
    extraKeyStrategy,
  }: {
    shape: T;
    extraKeyStrategy: ExtraKeyStrategy;
  }) {
    super();
    this.shape = shape;
    this.extraKeyStrategy = extraKeyStrategy;
  }

  _parse(
    data: unknown
  ):
    | { isValid: false; reason?: string | undefined }
    | { isValid: true; data: { [K in keyof T]: T[K]["_output"] } } {
    // 타입이 객체가 아니라면 더 이상 확인할 필요가 없다.
    if (typeof data !== "object") {
      return {
        isValid: false,
      };
    }

    // typeof null === 'object'이므로 예외 처리를 해준다.
    if (data === null) {
      return {
        isValid: false,
      };
    }

    // 마찬가지로 다음과 같은 경우 typeof data === 'object'이므로 예외 처리를 해준다.
    // array, promise, date, set, map 일경우
    // (코드 생략)

    // shape key보다 data key가 적으면 더 이상 확인할 필요가 없다.
    const shapeKeys = Object.keys(this.shape);
    const dataKeys = Object.keys(data);
    if (shapeKeys.length > dataKeys.length) {
      return {
        isValid: false,
      };
    }

    // extraKeys => data에는 있지만 shape에는 없는 키
    const extraKeys = [];
    for (const key in data) {
      if (!(key in this.shape)) {
        extraKeys.push(key);
      }
    }

    // strict일 경우 여분의 키를 허용하지 않으므로 예외 처리를 해준다.
    if (this.extraKeyStrategy === "strict" && extraKeys.length > 0) {
      return {
        isValid: false,
      };
    }

    for (const key in data) {
      // 여분의 키가 아닌 것만 검증
      if (!extraKeys.includes(key)) {
        const result = this.shape[key]?._parse(data[key as keyof typeof data]);
        if (result && !result.isValid) {
          return {
            isValid: false,
          };
        }
      }
    }

    // strip일 경우 결과에 여분의 키를 포함시키지 않으므로 제거해 준다.
    if (this.extraKeyStrategy === "strip") {
      extraKeys.forEach((extraKey) => {
        delete data[extraKey];
      });
    }

    return {
      isValid: true,
      data,
    };
  }

  // 생성 시 extraKeyStrategy의 기본값을 strip으로 설정해 준다.
  static create<T extends Record<string, ZodType<any>>>(shape: T) {
    return new ZodObject({ shape, extraKeyStrategy: "strip" });
  }
}
```

마지막으로 `extraKeyStrategy`를 변경하는 메소드를 추가해 준다.

```ts
class ZodObject<T extends Record<string, ZodType<any>>> extends ZodType<{
  [K in keyof T]: T[K]["_output"];
}> {
  // 생략

  // strict, strip 과는 달리 여분의 키를 포함시키므로
  // Infer로 타입 추출 시 여분의 키를 포함시킨다.
  passthrough(): ZodType<
    {
      [K in keyof T]: T[K]["_output"];
    } & { [k: string]: unknown }
  > {
    return new ZodObject({
      shape: this.shape,
      extraKeyStrategy: "passthrough",
    });
  }

  strict() {
    return new ZodObject({
      shape: this.shape,
      extraKeyStrategy: "strict",
    });
  }

  strip() {
    return new ZodObject({
      shape: this.shape,
      extraKeyStrategy: "strip",
    });
  }
}
```

이제 기존에 만든 클래스를 통해 확인하면 다음과 같은 결과를 얻을 수 있다.

기본값(`strip`)인 경우 - 여분의 키를 검증하지 않고 결과에 포함 X

```ts
const personSchema = ZodObject.create({
  name: ZodString.create(),
  bloodType: ZodEnum.create(["A", "B", "AB", "O"]),
});

const result = personSchema.safeParse({
  name: "zod",
  bloodType: "A",
  extra: 1,
}); // 검증 성공 { name: 'zod', bloodType: 'A' }
```

`passthrough`인 경우 - 여분의 키를 검증하지 않고 결과에 포함 O

```ts
const personSchema = ZodObject.create({
  name: ZodString.create(),
  bloodType: ZodEnum.create(["A", "B", "AB", "O"]),
}).passthrough();

const result = personSchema.safeParse({
  name: "zod",
  bloodType: "A",
  extra: 1,
}); // 검증 성공 { name: 'zod', bloodType: 'A', extra: 1 }
```

`strict`인 경우 - 여분의 키를 허용하지 않음

```ts
const personSchema = ZodObject.create({
  name: ZodString.create(),
  bloodType: ZodEnum.create(["A", "B", "AB", "O"]),
}).strict();

const result = personSchema.safeParse({
  name: "zod",
  bloodType: "A",
  extra: 1,
}); // 검증 실패 - extra가 포함되어 있으므로
```

## 추가 기능 구현하기

### extend

위의 내용을 이해했다면 추가적인 기능을 구현하는 것은 어렵지 않다. 
예를 들어 기존의 스키마를 기반으로 새로운 스키마를 만들고 싶을 때 사용하는 `extend` 메서드는 다음과 같이 구현할 수 있다.

```ts
class ZodObject<T extends Record<string, ZodType<any>>> extends ZodType<{
  [K in keyof T]: T[K]["_output"];
}> {
  // 생략

  extend<T extends Record<string, ZodType<any>>>(shape: T) {
    return new ZodObject({
      // 새로운 shape을 기존의 shape에 추가해준다.
      shape: { ...this.shape, ...shape },
      extraKeyStrategy: this.extraKeyStrategy,
    });
  }  
}  
```

그러면 공통 스키마를 확장하여 사용할 수 있고 타입 추출까지 잘 되는 것을 확인할 수 있다.

```ts
const personSchema = ZodObject.create({
  name: ZodString.create(),
  bloodType: ZodEnum.create(["A", "B", "AB", "O"]),
});

const mySchema = personSchema.extend({
  username: ZodString.create(),
});

const result = mySchema.safeParse({
  name: "zod",
  bloodType: "A",
  username: "zod123",
}); // 검증 성공

Infer<typeof mySchema>;
// {
//   name: string;
//   bloodType: "A" | "B" | "AB" | "O";
//   username: string;
// }
```

### pick

이번에는 다음과 같이 스키마에서 원하는 프로퍼티만 선택하여 새로운 스키마를 생성하는 `pick` 메서드를 구현해 보자.

```ts
const mySchema = personSchema.pick({
  name: true,
});
```

```ts
class ZodObject<T extends Record<string, ZodType<any>>> extends ZodType<{
  [K in keyof T]: T[K]["_output"];
}> {
  // 생략

  // pick 메서드가 받는 인자를 mask라고 하자.
  // mask의 타입은 리턴 타입에서 활용되어야 하기 때문에 타입 파라미터(Mask)로 선언해 준다.
  // mask는 키가 shape의 키, 값은 true 여야 하고 일부만 입력되는 것이 허용되므로
  // Partial을 이용하여 다음과 같이 제약사항을 준다.
  pick<Mask extends Partial<Record<keyof T, true>>>(
    mask: Mask
  ): ZodType<
    // 리턴 타입의 경우 기존의 리턴 타입에서 주어진 Mask의 키만 뽑은 타입이 되어야한다. (Pick 사용)
    Pick<
      {
        [K in keyof T]: T[K]["_output"];
      },
      // Pick의 두 번째 인자에는 첫 번째 인자의 키(keyof T)에 할당 가능한 값만 입력할 수 있다.
      // 따라서 keyof Mask를 바로 전달할 수 없으므로 Extract를 활용하여 첫 번째 인자의 키(keyof T) 중
      // keyof Mask에 할당 가능한 값만 뽑아내서 전달한다.
      Extract<keyof T, keyof Mask>
    >
  > {
    const newShape: any = {};

    for (const key in mask) {
      newShape[key] = this.shape[key];
    }

    return new ZodObject({
      shape: newShape,
      extraKeyStrategy: this.extraKeyStrategy,
    }) as any;
  }
}  
```

결과

```ts
const personSchema = ZodObject.create({
  name: ZodString.create(),
  bloodType: ZodEnum.create(["A", "B", "AB", "O"]),
});

const mySchema = personSchema.pick({
  name: true,
});

type Result = Infer<typeof mySchema>;
// {
//   name: string;
// }
```

이렇게 해서 `ZodString`, `ZodOptional`, `ZodEnum`, `ZodObject`, `Infer` 등을 구현해 보면서 Zod가 내부적으로 어떻게 검증을 하고, 또
스키마로부터 타입을 추출할 수 있게 해주는지 알아보았다.


ZodEnum과 ZodOptional의 단순화 버전을 구현해봅니다.

z.enum(), z.optional() 구현하기


- [#1: z.string() 구현하기](/blog/implementing-zod-using-typescript-1)
- [#3: z.string() min, max 메서드 구현하기](/blog/implementing-zod-using-typescript-2)
- [#3: z.enum(), z.optional() 구현하기](/blog/implementing-zod-using-typescript-3)
- [#4: z.object() 구현하기](/blog/implementing-zod-using-typescript-4)

이전 글에서는 간단한 `string` 타입을 검증할 수 있는 `ZodString` 클래스를 구현해 봤습니다.
오늘은 `enum` 타입을 검증할 수 있는 `ZodEnum`과
선택적으로 인풋을 받기 위해 사용하는 `ZodOptional`을 구현해 보겠습니다.

## ZodEnum

[Zod enum](https://zod.dev/?id=zod-enums)을 사용하면 `enum` 스키마를 생성할 수 있다.

```ts
const FishEnum = z.enum(["Salmon", "Tuna", "Trout"]);
type FishEnum = z.infer<typeof FishEnum>;
// "Salmon" | "Tuna" | "Trout"
```

입력받은 data가 `FishEnum` 타입과 다르다면 다음과 같이 검증에 실패한다.

```ts
const result1 = FishEnum.safeParse("Salmon"); 
// { success: true, data: "Salmon" }
const result2 = FishEnum.safeParse("Salmon2");
// { success: false, error: Error }
```

### 구현해보기

이제 어떻게 사용하는지 파악했으므로 간단한 버전으로 구현해 보자.

```ts
// 2. values는(ex. ["Salmon", "Tuna", "Trout"]) 하나 이상의 string으로
// 이루어진 배열이므로 타입 파라미터 T를 다음과 같이 선언할 수 있다.
// 또한 추론되어야 하는 타입은 배열의 멤버이므로 ZodType의 파라미터에 T[number]를 인자로 전달해 준다.
class ZodEnum<T extends [string, ...string[]]> extends ZodType<T[number]> {
  // 1. 허용된 enum 값을 저장하는 변수
  readonly values: T;

  constructor(values: T) {
    super();
    this.values = values;
  }

  _parse(
    data: unknown
  ):
    | { isValid: false; reason?: string | undefined }
    | { isValid: true; data: T[number] } {
    // 3. data가 string이 아니라면 더 이상 확인하지 않는다.
    if (typeof data !== "string") {
      return {
        isValid: false,
      };
    }

    // 4. values에 data가 없다면 유효하지 않다.
    if (!this.values.includes(data)) {
      return {
        isValid: false,
      };
    }

    // 5. 위에서 걸러지지 않았다면 유효하다.
    return {
      isValid: true,
      data,
    };
  }

  static create<T extends [string, ...string[]]>(values: T) {
    return new ZodEnum(values);
  }
}
```

이렇게 구현을 하면 검증 로직이 잘 동작하는 것을 확인할 수 있다.

```ts
const FishEnum = ZodEnum.create(["Salmon", "Tuna", "Trout"]);

FishEnum.safeParse("Trout"); // 통과
FishEnum.safeParse("Trout!!"); // 실패
```

하지만 [지난 글](/blog/implementing-zod-using-typescript-1#%EC%8A%A4%ED%82%A4%EB%A7%88%EB%A1%9C%EB%B6%80%ED%84%B0-%ED%83%80%EC%9E%85-%EC%B6%94%EC%B6%9C%ED%95%98%EA%B8%B0)에서 만든 `Infer`로 타입을 추출해 보면
`string`으로 잘못 추론되고 있다. 우리가 원하는 타입 `"Salmon" | "Tuna" | "Trout"`과는 다르다.

```ts
type FishEnum = Infer<typeof FishEnum>;
// ^? string
```

이를 개선하기 위해 `create` 메서드의 타입을 변경해 보자. 현재는 단순히 `string`으로 이루어진 배열을 확장하는 타입으로 타입 파라미터가 선언되어 있기 때문에
타입스크립트가 멤버의 타입을 `string`으로 추론해 주었다.

```ts
static create<T extends [string, ...string[]]>(values: T) {
  return new ZodEnum(values);
}
```

하지만 우리는 `string`보다 더 구체적인 타입으로 추론해 주길 원하기 때문에 다음과 같은 트릭을 사용할 수 있다.
`string` 타입을 확장하는 새로운 타입 파라미터 `U`를 선언해 주고 기존의 `T`는 `U`로 이루어진 배열을 확장하도록 변경해 준다.

```ts
static create<U extends string, T extends [U, ...U[]]>(values: T) {
  return new ZodEnum(values);
}
```

그러면 타입스크립트가 배열의 멤버를 `string` 타입보다 조금 더 구체적인 타입으로 추론해 주기 때문에 원하는 결과를 얻을 수 있다. 

```ts
type FishEnum = Infer<typeof FishEnum>;
// ^? "Salmon" | "Tuna" | "Trout"
```

## ZodOptional

스키마를 선언하다 보면 있을 수도, 없을 수도 있는 필드를 검증하고 싶을 때가 있다.

예를 들면 사용자에게 주소를 선택적으로 입력하도록 만들고 해당 데이터를 검증한다고 하자.

```ts
const optionalAddress = z.string().optional(); // string | undefined

// 다음과 같이 선언할 수도 있다.
const optionalAddress = z.optional(z.string()); // string | undefined
```

그러면 `z.string()`으로 스키마를 선언했을 때와는 다르게 데이터가 입력되지 않았더라도(`undefined`여도)
검증이 실패하지 않는다.

```ts
optionalAddress.safeParse("서울특별시..."); // 통과
optionalAddress.safeParse(undefined); // 통과
```

### 구현 해보기

```ts
// 2. innerType에는 어떠한 값이 들어올지 모르기 때문에 타입 파라미터 T를 선언하고
// 이는 ZodType을 확장하는 값만 허용하도록 해준다.
// 또한 해당 스키마의 타입을 추출했을 때 ZodString 타입이 입력되었다면 string | undefined로
// 추론되어야 하므로 ZodType에 T["_output"] | undefined을 인자로 전달해 준다.
class ZodOptional<T extends ZodType<any>> extends ZodType<
  T["_output"] | undefined
> {
  // 1. 기존에 어떠한 타입인지를 저장하는 변수
  // ZodString, ZodEnum 등 ZodType을 확장한다면 모두 가능하다.
  readonly innerType: T;

  constructor(innerType: T) {
    super();
    this.innerType = innerType;
  }

  _parse(
    data: unknown
  ):
    | { isValid: false; reason?: string | undefined }
    | { isValid: true; data: T | undefined } {
    // 3. undefined이면 더이상 확인할 필요 없이 통과
    if (typeof data === "undefined") {
      return {
        isValid: true,
        data,
      };
    }

    // 4. undefined가 아니라면 innerType에게 역할을 넘김
    return this.innerType._parse(data);
  }

  static create<T extends ZodType<any>>(innerType: T) {
    return new ZodOptional(innerType);
  }
}
```

이러면 주어진 타입을 선택적으로 입력받도록 만들 수 있고

```ts
const optionalAddress = ZodOptional.create(ZodString.create());
optionalAddress.safeParse("서울특별시..."); // 통과
optionalAddress.safeParse(undefined); // 통과

const optionalFish = ZodOptional.create(
  ZodEnum.create(["Salmon", "Tuna", "Trout"])
);
optionalFish.safeParse("Salmon");
optionalFish.safeParse(undefined); // 통과
```

타입 추출 또한 잘 되게 만들 수 있다.

```ts
Infer<typeof optionalAddress>
// ^? string | undefined

Infer<typeof optionalFish>
// ^? "Salmon" | "Tuna" | "Trout" | undefined
```

주어진 타입을 선택적으로 받도록 만드는 기능은 모든 타입에서 공통적으로 사용할 수 있기 때문에 `ZodType`의 메서드에 추가하면
더 편하게 사용 가능하다.

```ts
abstract class ZodType<Output> {
  // 생략

  optional() {
    return ZodOptional.create(this);
  }
}

const optionalAddress = ZodString.create().optional();
const optionalFish = ZodEnum.create(["Salmon", "Tuna", "Trout"]).optional();
```

비록 매우 단순화시킨 코드지만 지금까지 코드를 이해한다면 `ZodNumber`, `ZodArray`, `ZodNullable` 등도
어떻게 구현되어 있을지 예상할 수 있을 것이다. 다음 글에서는 마지막으로 `ZodObject`를 어떻게 구현하는지 알아보자.

Zod string의 min, max 메서드를 구현하면서 어떻게 추가 검증이 동작하는지 알아봅니다.

z.string() min, max 메서드 구현하기


- [#1: z.string() 구현하기](/blog/implementing-zod-using-typescript-1)
- [#3: z.string() min, max 메서드 구현하기](/blog/implementing-zod-using-typescript-2)
- [#3: z.enum(), z.optional() 구현하기](/blog/implementing-zod-using-typescript-3)
- [#4: z.object() 구현하기](/blog/implementing-zod-using-typescript-4)

Zod를 활용하다 보면 `string`인 것을 확인하는 것뿐만 아니라 최소 길이, 최대 길이와 같이 추가적인 검증을 하고 싶은 경우가 있다.
오늘은 [지난 글](/blog/implementing-zod-using-typescript-1)에서 구현한 `ZodString` 클래스에 검증 로직을 추가해 주는 메서드를 구현해 보자.

## min, max 메서드

다음과 같이 `min` 또는 `max` 메서드를 사용하면 입력 값이 `string`인지 확인 후
길이까지 추가 검증을 해준다.

```ts
import { z } from 'zod';

const minFive = z.string().min(5, "5글자 이상이어야 합니다.");
minFive.parse(input); // input.length < 5 => 에러 발생
```

메서드 체이닝을 통해 두 가지 이상을 검증을 추가하는 것도 가능하다.

```ts
import { z } from 'zod';

const minFiveMaxTen = z
  .string()
  .min(5, "5글자 이상이어야 합니다.")
  .max(10, "10글자 이하여야 합니다.");
minFiveMaxTen.parse(input); // input.length < 5 또는 input.length > 10 => 에러 발생 
```

## 구현해보기

이제 `ZodString`을 보면서 어떠한 로직을 추가해야 할지 생각해보자.

```ts
class ZodString extends ZodType<string> {
  _parse(
    data: unknown
  ): { isValid: true; data: string } | { isValid: false; reason?: string } {
    if (typeof data === "string") {
      return {
        isValid: true,
        data,
      };
    } else {
      return {
        isValid: false,
        reason: `${data}는 string이 아닙니다.`,
      };
    }
  }
}
```

`min`, `max` 메서드를 호출하면 어떠한 검증이 추가로 필요한지를 변수(`checks`라고 하자)에 저장하고 실제 검증 로직은 `_parse` 메서드에서 해당 변수를 읽어서 구현하면 될 것 같다.
예시에서 봤던 것처럼 여러 검증 로직을 추가할 수 있기 때문에 이를 배열로 관리하면 좋을 것이다. 
또한 이러한 검증은 `string`에만 존재하기 때문에 변수는 `ZodString` 클래스 내부에 있어야 한다.

```ts
class ZodString extends ZodType<string> {
  checks: unknown[]

  _parse(data: unknown){
    // this.checks 반복문을 통해 추가 검증 로직 구현
  }
}
```

`min`, `max`의 경우 숫자와 메시지를 함께 제공하면 `_parse`에서 검증 로직을 구현할 수 있으므로
다음과 같이 타입을 작성할 수 있을 것이다.

```ts
class ZodString extends ZodType<string> {
  checks: (
    | { kind: "min"; value: number; message?: string }
    | { kind: "max"; value: number; message?: string }
  )[];

  _parse(data: unknown) {
    // this.checks 반복문을 통해 추가 검증 로직 구현
  }
}
```

이제 `this.checks`에 접근하여 추가 검증 로직을 구현해보자.

```ts
class ZodString extends ZodType<string> {
  checks: (
    | { kind: "min"; value: number; message?: string }
    | { kind: "max"; value: number; message?: string }
  )[];

  _parse(
    data: unknown
  ):
    | { isValid: false; reason?: string | undefined }
    | { isValid: true; data: string } {
    // string이 아니면 더 이상 확인할 필요도 없다.
    if (typeof data !== "string") {
      return {
        isValid: false,
        reason: `${data}는 string이 아닙니다.`,
      };
    }

    // 배열을 순회하며 추가 검증을 시도한다.
    for (const check of this.checks) {
      if (check.kind === "min") {
        if (data.length < check.value) {
          return {
            isValid: false,
            reason: check.message,
          };
        }
      } else if (check.kind === "max") {
        if (data.length > check.value) {
          return {
            isValid: false,
            reason: check.message,
          };
        }
      }
    }

    // 위에서 어떠한 케이스에도 걸리지 않았다면 유효한 string이다.
    return {
      isValid: true,
      data,
    };
  }
}
```

이제 `min`, `max` 메서드를 구현해 보자.
각각의 메서드가 호출되면 `checks`에 무엇이 확인되어야 할지 추가되고
이 `checks`를 기반으로 새로운 `ZodString`이 생성된다.

```ts
type ZodStringCheck =
  | { kind: "min"; value: number; message?: string }
  | { kind: "max"; value: number; message?: string };

class ZodString extends ZodType<string> {
  checks: ZodStringCheck[];

  constructor(checks: ZodStringCheck[]) {
    super();
    this.checks = checks;
  }

  // _parsed 생략

  min(value: number, message?: string) {
    // 검증 로직을 this.checks에 추가하고
    this.checks.push({ kind: "min", value, message });

    // 다시 새로운 ZodString 인스턴스를 생성해 메서드 체이닝이 가능하도록 구현한다.
    return new ZodString(this.checks);
  }

  max(value: number, message?: string) {
    this.checks.push({ kind: "max", value, message });

    return new ZodString(this.checks);
  }
}
```

이렇게 만들고 확인을 위해 스키마를 만들려고 하면 이전과 다르게 타입 에러가 발생한다.

```ts
const mySchema = new ZodString(); // Expected 1 arguments, but got 0.
```

이유는 생성자에서 `checks`를 받도록 하였고 이는 반드시 입력되어야 하도록 했기 때문이다.

세부 구현 사항을 몰라도 편하게 인스턴스를 생성할 수 있도록 `create`라는 static 메서드를 생성해 보자.

```ts
class ZodString extends ZodType<string> {
  // 생략

  static create() {
    return new ZodString([]);
  }
}

const mySchema = ZodString.create(); // z.string()과 동일
```

이러면 기대했던 대로 길이까지 추가 검증을 할 수 있고

```ts
const mySchema = ZodString.create().min(5, "5글자 이상이어야 합니다.");
const result = mySchema.safeParse("hell");
// {
//   success: false,
//   error: Error: 5글자 이상이어야 합니다. ...
// }
```

메서드 체이닝까지 할 수 있게 되었다.

```ts
const mySchema = ZodString.create()
  .min(5, "5글자 이상이어야 합니다.")
  .max(10, "10글자 이하여야 합니다.");
const result = mySchema.safeParse("helloworld!");
// {
//   success: false,
//   error: Error: 10글자 이하여야 합니다. ...
// }
```

## 결론

오늘은 Zod의 메서드가 어떻게 동작하는지 `ZodString` 클래스에 `min`, `max`를 추가하면서 알아보았다.
2가지만 구현하였지만 나머지 비슷한 메서드들도 이와 같이 동작하기 때문에 동작 원리를 이해하기에는 충분할 것이다.


TypeScript로 input을 그대로 리턴하는 함수를 만들며 제네릭 함수에 대해 이해해 봅니다.

TypeScript와 제네릭 함수


TypeScript로 `input`을 그대로 반환하는 함수를 만든다면 어떻게 구현할 수 있을까?

## 타입 파라미터 없이 구현해보기

### unknown 사용해보기

`input`에는 어떠한 타입이 들어올지 모르기 때문에 `unknown` 타입으로 선언해 주었다고 하자.
그러면 다음과 같이 작성할 수 있다.

```typescript
function returnWhatIPassIn(input: unknown) {
  return input;
}

const result = returnWhatIPassIn("hello");
// ^? unknown
```

이렇게 작성하면 `input`의 타입은 `unknown`이고 이 함수는 `input`을 그대로 리턴해주고 있음으로 리턴 타입도 `unknown` 타입으로 추론된다.
그러면 리턴된 값을 `result`라는 변수에 할당했을 때 `result` 또한 `unknown` 타입으로 추론되기 때문에
타입스크립트의 이점을 활용할 수 없다.

### any 사용해보기

`input`의 타입을 `any`로 선언한다고 해도 `result`가 `any`로 추론되는 것 이외에는 바뀌는 것이 없다.

```typescript
function returnWhatIPassIn(input: any) {
  return input;
}

const result = returnWhatIPassIn("hello");
// ^? any
```

## 타입 파라미터 사용해서 구현해보기

### 타입 파라미터를 제대로 활용하지 못 한 경우

이번에는 타입 파라미터를 사용하여 함수를 다시 작성해 보자.
`T`라는 타입 파라미터를 선언하고 함수가 리턴하는 타입을 `T`라고 선언해 주었다.

> 타입 파라미터를 1개 이상 선언하여 만든 함수를 제네릭 함수라고 한다.

```typescript
function returnWhatIPassIn<T>(input: any): T {
  return input;
}

const result = returnWhatIPassIn("hello");
// ???
```

이렇게 작성했을 때 변수 `result`의 타입은 어떤 타입으로 추론될까?

코드를 살펴보면 타입 파라미터 `T`를 선언하고 이를 리턴 타입으로 사용하였지만 어떠한 타입 인자도 넘겨주고 있지 않다.
따라서 이럴 경우에 타입스크립트는 `T`의 타입을 `unknown` 타입으로 추론하므로 변수 `result` 또한 `unknown` 타입으로 추론된다.

```typescript
function returnWhatIPassIn<T>(input: any): T {
  return input;
}

const result = returnWhatIPassIn("hello");
// ^? unknown
```

이번에는 타입 파라미터에 타입 인자를 전달해 보자.
리턴 타입을 `"hello"` 라는 `string` 리터럴 타입으로 선언해주기 위해서 타입 파라미터 T에 타입 인자 `"hello"`를 전달해 주자.

```typescript
function returnWhatIPassIn<T>(input: any): T {
  return input;
}
const result = returnWhatIPassIn<"hello">("hello");
// ^? "hello"
```

그러면 타입 파라미터 `T`에 타입 인자 `"hello"`를 전달해 주었기 때문에 `T`의 타입은 `"hello"`라는 `string` 리터럴 타입이 되었고
이 함수는 이를 리턴 타입으로 선언해두었기 때문에 리턴 타입 또한 `"hello"` 타입이 된다.
따라서 변수 `result`의 타입을 확인해 보면 올바르게 추론이 된 것을 확인할 수 있다.

### 문제 파악하기

하지만 아직 아쉬운 점이 있다. 이런 방식으로 함수를 사용한다면 
1. 함수를 호출할 때마다 항상 타입 인자를 전달해 줘야 하고
2. 현재 `input`의 타입을 `any`로 선언해 주었기 때문에 `input`에는 어떠한 값도 들어갈 수 있다.

2번에 대해 조금 더 설명하자면 타입 인자에 `"hello"`를 전달해 주더라도 `input`의 타입은 `any`이기 때문에 
`"hello world"`와 같은 다른 값을 전달해 줄 수 있고 이 때도 `result`는 `"hello"`로 추론된다.
전달해 주는 타입 인자와 `input`의 인자를 신경 써서 동기화시켜 주어야야하고 실수를 했을 때 어떠한 경고도 받을 수 없으므로
이렇게 선언된 함수를 사용하는 사람의 입장에서는 실수를 할 가능성이 크다.

```typescript
const result = returnWhatIPassIn<"hello">("hello world");
// ^? "hello"
```

이러한 문제가 발생한 이유는 타입 파라미터 `T`의 타입과 `input`의 타입이 다를 수 있도록 타입이 선언되어 있었기 때문이다.
즉, 두 타입 사이에 어떠한 연결도 되어있지 않았기 때문이다. 이 함수에서 두 타입은 항상 같은 타입이어야만 하는데도 말이다.
이 두 타입을 연결시킨다면 이 문제를 해결할 수 있지 않을까?

### 타입 파라미터를 제대로 활용한 경우

다음과 같이 함수를 재작성해 보았다. 타입 파라미터 `T`를 선언하고 타입 인자가 입력되었을 때 해당 타입은 항상 `input`의 타입과 같아야 하므로
`input`의 타입을 `T`로 선언하였다. 그리고 `input`을 그대로 리턴하기 때문에 리턴 타입은 선언하지 않아도 `T`로 추론될 것이다.

```typescript
function returnWhatIPassIn<T>(input: T) {
  return input;
}
```

이렇게 했을 때의 장점은 타입 인자 `"hello"`를 전달해 주었을 때 타입 파라미터 `T`의 타입은 `"hello"`가 되고 이러면 `input`의 타입도 `"hello"`가 되기 때문에
`"hello"`라는 인자만을 전달해 줄 수 있다.

```typescript
const result = returnWhatIPassIn<"hello">("hello world");
// "hello"를 전달해 주지 않았기 때문에 타입스크립트 에러가 발생한다.
// `input`의 타입을 `any`로 했을 때와는 다르게 실수를 미리 방지할 수 있다.
```

사실은 타입 인자를 전달해 줄 필요도 없다. 타입 파라미터 `T`를 선언하고 `input`의 타입을 `T`로 선언해두었기 때문에
타입 인자를 전달해 주지 않았을 경우 타입스크립트가 `input`으로 전달된 인자로부터 `T`의 타입을 추론해 주기 때문이다. 

```typescript
const result = returnWhatIPassIn("hello");
// ^? "hello"
```

위와 같이 함수를 호출하면 타입 인자를 입력하지 않았으므로 타입스크립트가 `input`으로 전달된 인자 `"hello"`를 확인하고
이로부터 타입 파라미터 `T`의 타입을 추론한다. `T`의 타입은 `"hello"`라는 `string` 리터럴 타입이 되었고
이 함수의 `input`을 그대로 리턴하므로 `"hello"`가 리턴 타입으로 추론된다. 결과적으로 `result`라는 변수는 `"hello"` 타입으로 추론된다.

## 요약

타입 파라미터를 선언하여 만든 제네릭 함수를 잘 활용한다면 타입 인자를 전달해 주지 않더라도
런타임 인자로부터 타입 파라미터의 타입이 추론되게 만들 수 있기 때문에 입력에 따라 다르게 추론되어야 하는 함수를 만들어야 할 경우 유용하게 사용할 수 있다.

## 레퍼런스

https://www.totaltypescript.com/mental-model-for-typescript-generics
https://www.totaltypescript.com/no-such-thing-as-a-generic

ZodType과 ZodString 클래스를 간단히 구현하면서 zod가 어떻게 문자열을 검증하는지 알아봅니다.

z.string() 구현하기


- [#1: z.string() 구현하기](/blog/implementing-zod-using-typescript-1)
- [#3: z.string() min, max 메서드 구현하기](/blog/implementing-zod-using-typescript-2)
- [#3: z.enum(), z.optional() 구현하기](/blog/implementing-zod-using-typescript-3)
- [#4: z.object() 구현하기](/blog/implementing-zod-using-typescript-4)

## Zod 기본 동작 확인하기

[Basic usage](https://zod.dev/?id=basic-usage)를 보면 Zod는 다음과 같이 스키마를 생성하고
`parse` 또는 `safeParse` 메서드를 사용하여 올바른 input이 들어왔는지 검증한다.

```typescript
import { z } from "zod";

// creating a schema for strings
const mySchema = z.string();

// parsing
mySchema.parse("tuna"); // => "tuna"
mySchema.parse(12); // => throws ZodError

// "safe" parsing (doesn't throw error if validation fails)
mySchema.safeParse("tuna"); // => { success: true; data: "tuna" }
mySchema.safeParse(12); // => { success: false; error: ZodError }

```

## ZodType 클래스 생성하기

일단 `parse`, `safeParse`와 같은 공통 메서드는 부모 클래스(`ZodType`)에서 구현하고
`ZodString`은 이를 상속하여 구현해 보자.
`parse` 메서드의 경우 내부적으로 `safeParse` 메서드를 이용하여 구현되어 있기 때문에 `safeParse`만 구현해 보겠다.
`safeParse`가 받는 인자는 검증하고 싶은 데이터이고 어떤 데이터 타입인지 알 수 없으므로 다음과 같이 정의할 수 있다.

```tsx
class ZodType {
  safeParse(data: unknown) {}
}
```

이제 코드를 작성하기 전에 로직을 주석으로 작성해 보자.

```tsx
class ZodType {
  safeParse(data: unknown) {
    // 검증이 성공했다면
    // return { success: true, data };
    // 검증이 실패했다면
    // return { success: false, error: new Error("검증 실패") };
  }
}
```

검증이 성공했는지 확인하는 로직은 특정 타입(string인지, number인지...)에 따라 다를 텐데 이 로직을 `ZodType` 클래스에서 어떻게 구현할 수 있을까?
[추상 메서드](https://yamoo9.gitbook.io/typescript/classes/abstract-class) 활용하면 이를 구현할 수 있다. 추상 메서드는 정의만 있을 뿐 몸체는 구현되어 있지 않다. 몸체는 해당 추상 클래스를 상속받은 클래스에서 구현하면 된다.
즉, ZodType을 추상 클래스로 만들고(추상 메서드는 추상 클래스에서만 사용할 수 있다.) `_parse`를 추상 메서드로 만들어 정의만 작성한 후, 몸체는 추후 `ZodType`을 상속받은 `ZodString`에서 구현하면 된다.

그러면 검증 성공 여부를 확인하는 로직을 `_parse`라는 내부 추상 메서드에서 하도록 하고 정의를 작성해 보자.
(클래스 내부에서만 사용되는 프로퍼티 또는 메서드임을 나타내기 위해 관습적으로 변수명 앞에 _를 붙이곤 한다.)

```tsx
abstract class ZodType {
  abstract _parse() {}

  // 생략
}
```

어떤 인자를 받고 어떤 값을 리턴해야 할까?
우선 데이터를 검증해야 하므로 `data`를 인자로 받고

- 검증이 성공했다면 성공했다는 것을 알려주고 해당 데이터를 반환한다.
- 검증이 실패했다면 실패했다는 것을 알려주고 왜 실패했는지를 반환한다.

추상 메서드에서는 정의만 작성하면 되므로 다음과 같이 작성할 수 있다.

```tsx
abstract class ZodType {
  abstract _parse(
    data: unknown
  ): { isValid: true; data: unknown } | { isValid: false; reason?: string };

  safeParse(data: unknown) {
    // 검증이 성공했다면
    // return { success: true, data };
    // 검증이 실패했다면
    // return { success: false, error: new Error("검증 실패") };
  }
}
```

이제 해당 정의를 바탕으로 주석을 코드로 변경해 보자.

```tsx
abstract class ZodType {
  abstract _parse(
    data: unknown
  ): { isValid: true; data: unknown } | { isValid: false; reason?: string };

  safeParse(data: unknown) {
    const result = this._parse(data);

    if (result.isValid) {
      return { success: true, data: result.data };
    } else {
      return { success: false, error: new Error(result.reason ?? "검증 실패") };
    }
  }
}
```

## ZodString 클래스 생성하기

이제 `ZodType`을 상속받은 `ZodString` 클래스를 만들고 추상 메서드 `_parse` 를 구현해 보자.

```tsx
class ZodString extends ZodType {
  _parse(
    data: unknown
  ):
    | { isValid: true; data: unknown }
    | { isValid: false; reason?: string } {
    if (typeof data === "string") {
      return {
        isValid: true,
        data,
      };
    } else {
      return {
        isValid: false,
        reason: `${data}는 string이 아닙니다.`,
      };
    }
  }
}
```

이제 string을 검증할 수 있게 되었으니 결과를 확인해 보자.

```tsx
const mySchema = new ZodString();

// 올바른 데이터가 들어왔을 경우
const result = mySchema.safeParse("1");
// ^? { success: true, data: '1' }

// 올바르지 않은 데이터가 들어왔을 경우
const result = mySchema.safeParse(1);
// ^? { success: false, error: Error: 1는 string이 아닙니다. ... }
```

위와 같이 주어진 데이터가 string 인지 아닌지를 잘 검증하고 있는 것을 확인할 수 있다.

## safeParse 메서드의 타입 문제 해결하기

### 타입이 좁혀지지 않는 이슈

현재는 `result.success: true`인 경우에도 타입이 좁혀지지 않고 있다. 
이러면 컴파일 타임에 어떤 필드가 있는지 정확하게 확인할 수 없기 때문에 실수할 가능성이 커진다.
컴파일 타임에 미리 방지할 수 있는 버그를 런타임이 되어서야 발견하는 일을 방지하기 위해 해당 코드를 개선해 보자.

```typescript
const mySchema = new ZodString();

const result = mySchema.safeParse("1");
if (result.success) {
  // 이전에는 `safeParse`의 리턴 타입을 명시하지 않았기 때문에
  // 타입스크립트가 자동으로 추론해 주고 있었다.
  result
  // ^? 
  // { success: boolean; data: unknown; error?: undefined; } 
  // | { success: boolean; error: Error; data?: undefined; }
}
``` 

성공했을 경우 `data`만 반환하고 실패했을 경우 error를 반환할 것이므로
[discriminated union](https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions)을 이용하여 다음과 같이 리턴 타입을 작성할 수 있다.

```tsx
abstract class ZodType {
  // 생략

  safeParse(
    data: unknown
  ): // success라는 공통 필드를 리터럴 타입(true 또는 false)으로 작성해주고
     // 각각의 경우 어떠한 필드와 타입를 반환할 것인지 작성해준다.
  { success: true; data: unknown } | { success: false; error: Error } {
   // 생략
  }
}
```

그러면 다음과 같이 `result.success`가 `true`인 스코프에서는 `data`만 있다고 알려준다.

```typescript
const mySchema = new ZodString();

const result = mySchema.safeParse("1");
if (result.success) {
  result
  // ^? { success: true; data: unknown }
}
```

### data의 타입이 올바르게 추론되지 않는 이슈

하지만 아직 해결해야 할 문제가 남아있다.
`“1”`을 입력하였고 성공 시 해당 데이터를 그대로 반환해 주므로 `data` 는 `string` 타입으로 추론되어야 하지만 `unknown` 타입으로 추론되고 있다.

그 이유는 당연하게도 성공했을 시 `data` 필드를 반환하고 이 필드는 `unknown` 타입이라고 선언해 주었기 때문이다. 조금 더 구체적인 타입을 반환하려면 어떻게 타이핑을 해야 할까?

```tsx
safeParse(
    data: unknown
  ): { success: true; data: unknown } | { success: false; error: Error }{
  // 생략
}
```

`ZodType` 클래스에서는 반환하는 `data`가 어떤 타입인지 알 수 없다.
하지만 `ZodString` 클래스에서는 반환하는 `data`가 `string` 임을 알고 있다. 
그러면 `ZodString` 클래스를 생성할 때 `ZodType` 에게 반환하는 값을 알려주면 될 것 같다.

```tsx
// Output이라는 이름으로 타입 파라미터를 선언하고 반환하는 data가 Ouput 타입임을 알려준다.
abstract class ZodType<Output> {
  abstract _parse(
    data: unknown
  ): { isValid: true; data: Output } | { isValid: false; reason?: string };

  safeParse(
    data: unknown
  ): { success: true; data: Output } | { success: false; error: Error } {
    // 생략
  }
}

// ZodString 클래스는 반환하는 값이 string 타입임을 알고있다. 따라서 타입 인자 string을 넘겨준다.
class ZodString extends ZodType<string> {
  _parse(
    data: unknown
  ):
    | { isValid: true; data: string }
    | { isValid: false; reason?: string | undefined } {
    // 생략
  }
}
```

이러면 `data`가 `unknown`으로 추론되는 문제도 해결되었다. 

```typescript
const mySchema = new ZodString();

const result = mySchema.safeParse("1");
if (result.success) {
  result
  // ^? { success: true; data: string }
}
```

## 스키마로부터 타입 추출하기

이번 글의 마지막으로 [z.infer](https://zod.dev/?id=type-inference)처럼 스키마로부터 타입스크립트 타입을 추출할 수 있도록 도와주는 유틸리티 타입을 구현해 보자.

```tsx
import { z } from "zod";

const mySchema = z.string();

type MySchemaType = z.infer<typeof mySchema>
// ^? string
```

타입 파라미터 `T`는 `ZodType`을 확장한다는 것을 이용하면 다음과 같이 `Output` 타입을 추출할 수 있다. 

```tsx
type Infer<T extends ZodType<unknown>> = Extract<
  ReturnType<T["_parse"]>,
  { isValid: true }
>["data"];
```

실제 Zod는 훨씬 복잡도가 높기 때문에 위와 같이 구현되어 있지 않고 `ZodType` 클래스에 `_output` 이라는 `readonly` 프로퍼티를 만들고 이 프로퍼티의 타입을 `Output` 으로 설정해 준다. 특이한 점은 해당 프로퍼티는 타입을 저장하고 읽기 위해서만 사용하고 실제로 값을 저장하지는 않는다.

```tsx
abstract class ZodType<Output> {
  // 타입을 Output으로 입력해주었지만 실제로 생성자에서 값을 할당하지는 않는다.
  // 따라서 다음과 같은 타입스크립트 에러가 발생한다.
  // Property '_output' has no initializer and is not definitely assigned in the constructor.
  readonly _output: Output;
  
  // 생략
}
```

코드 작성자가 의도적으로 타입만 저장하기 위해 작성한 코드이기 때문에 [non-null 단언 사용자](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html#non-null-assertion-operator)를 통해 해당 프로퍼티는 `null`이 아님을 알려준다.

```tsx
abstract class ZodType<Output> {
  // 타입스크립트는 해당 프로퍼티가 null이 아니라고 생각하기 때문에 생성자에서 값을 할당해주지 않아도 에러가 발생하지 않는다.
  readonly _output!: Output;

  // 생략
}
```

이러면 아까 만들었단 Infer 타입을 다음과 같이 간단하게 변경할 수 있다.
(해당 프로퍼티는 실제로는 어떠한 값도 할당되어 있지 않기 때문에 타입을 얻기 위해서만 사용해야 한다.)

```tsx
type Infer<T extends ZodType<unknown>> = T['_output'];
```



React와 SSR


## SSR은 무엇일까요?

개발자는 사용자가 애플리케이션을 로드(다운로드 및 실행) 할 때 100% 상호작용이 가능한 페이지를 최대한 빠르게 보여주고 싶어 합니다.
다음과 같이 말이죠.

![100% 상호작용이 가능한 페이지 - 해당 부분이 상호작용이 가능하다는 것을 나타내기 위해 초록색을 사용했습니다. 다시 말해 초록색 부분은 JavaScript의 이벤트 핸들러가 이미 부착되어 있고 버튼을 클릭하면 상태가 변경될 것입니다.](/static/images/react-and-ssr/interactive-page.png)

<br/ >

하지만 페이지에 해당하는 JavaScript 코드를 로드하기 전에는 상호작용할 수 없습니다. 간단한 애플리케이션이 아니고 코드 스플리팅도 제대로 이루어지지 않았을 경우 해당 페이지를 보기 위해서는 애플리케이션 코드 전부를 다운로드해야 하기 때문에 로딩하는데 더 많은 시간이 걸릴 것입니다.

만약 SSR을 사용하지 않을 경우 JavaScript를 로드하기 전까지 사용자는 빈 페이지를 보게 될 것입니다.

![빈 페이지 - 순수 React만 사용할 경우에 사용자는 보통 콘텐츠가 비어있는 HTML을 전달받는다. 이후 HTML의 script 태그에 명시된 JavaScript 파일이 로드되어야만 사용자가 빈 페이지에서 탈출할 수 있다.](/static/images/react-and-ssr/empty-page.png)

<br/ >

이러면 사용자는 빈 페이지를 보는 시간이 길어지기 때문에 좋지 않으며 이러한 상황을 방지하기 위해서는 SSR을 사용하는 것이 권장됩니다. SSR은 서버에서 React 컴포넌트로 HTML을 미리 생성하여 사용자에게 전달합니다. HTML 자체는 input이나 a 태그와 같이 내장된 요소를 제외하고는 상호작용이 가능하지는 않습니다. 하지만 적어도 이는 사용자가 JavaScript를 로드하기 전에 무언가를 볼 수 있도록 해줍니다.

![서버에서 생성된 HTML -  각 부분이 상호작용이 가능하지 않다는 것을 나타내기 위해 회색을 사용했습니다. JavaScript 코드가 로드된 상태가 아니기 때문에 버튼을 클릭해도 아무일도 일어나지 않습니다. 그러나 콘텐츠가 많은 웹사이트인 경우 SSR은 매우 유용합니다. 사용자가 네트워크 환경이 좋지 않아 JavaScript를 오랜 시간 기다리는 동안 서버에서 미리 렌더링된 콘텐츠를 미리 볼 수 있기 때문입니다.](/static/images/react-and-ssr/non-interactive-page.png)

<br/ >

모든 React 및 애플리케이션 코드가 로드되면 HTML이 상호작용 가능하도록 만들고 싶을 것입니다. "여기 HTML을 서버에서 생성한 `App` 컴포넌트가 있어. 이 HTML에 이벤트 핸드러를 부착해 줘"라고 React에게 말하면 React는 메모리에서 컴포넌트 트리를 렌더링할 것이며 이에 대한 DOM 노드를 생성하는 대신 이미 존재하는 HTML에 모든 로직을 부착시킵니다.

이렇게 컴포넌트를 렌더링하고 이벤트 핸들러를 부착시키는 과정을 하이드레이션(hydration)이라고 부릅니다. 이를 마치 마른 HTML에 상호작용, 이벤트 핸들러라는 물을 주는 과정이라고 표현하기도 합니다.

하이드레이션 과정이 끝나면 우리가 아는 일반적인 React가 됩니다: 컴포넌트가 상태를 변경하거나 클릭에 반응합니다. 

![서버에서 생성된 HTML은 상호작용이 가능하지 않기 때문에 하이드레이션 과정까지 끝나야 온전히 상호작용이 가능한 페이지가 됩니다.](/static/images/react-and-ssr/interactive-page.png)

<br/ >

이와 같이 SSR은 단지 눈속임의 한 종류라는 것을 알 수 있습니다. SSR은 100% 상호작용이 가능한 페이지를 빠르게 만들어주지는 않습니다. 단지 상호작용이 불가능한 페이지를 최대한 빠르게 보여줘서 사용자가 JavaScript를 기다리는 동안 정적 콘텐츠를 볼 수 있도록 해줍니다. 하지만 이러한 트릭은 네트워크 상태가 좋지 않은 사용자에게는 아주 큰 차이를 만들어 내며 체감상 엄청난 성능을 향상시켜줍니다. 또한 인덱싱이 쉽고 속도가 빠르기 때문에 검색 엔진 순위에도 도움을 줍니다.

## 결론

- CSR의 경우 사용자의 네트워크 상태가 좋지 않거나 다운받아야할 애플리케이션 코드의 크기가 클 때 빈 페이지를 보는 시간이 길어진다.
- 이를 해결하기 위해 SSR을 사용할 수 있고 이는 자바스크립트가 로드되는 동안 서버에서 렌더링된 HTML을 보여주는 방법이다.
- 이를 통해 사용자에게 정적 콘텐츠를 빠르게 제공하고 체감 성능을 높일 수 있다.

## 레퍼런스

[New Suspense SSR Architecture in React 18](https://github.com/reactwg/react-18/discussions/37)


yarn이 제공하는 workspace 기능이 왜 등장하게 되었는지, 어떤 문제를 해결해 주는지 알아봅니다.

Yarn Workspaces 기능 알아보기


yarn이 제공하는 workspaces 기능을 소개하기 앞서 어떤 과정을 통해 등장하게 되었는지 알아보겠습니다.

## 멀티레포

어느 날 모듈화된 패키지 A를 개발하고 레포지토리 A에 이를 저장했습니다.
A의 개발이 끝난 후 패키지 B를 개발하게 되었고 새로운 레포지토리 B를 만들어 이를 저장했습니다.
이와 같이 각각의 모듈화된 패키지를 개별 레포지토리에서 관리하는 방식을 **멀티레포**라고 합니다.

개발 전에는 미처 몰랐지만 막상 패키지 A와 B를 모두 개발하고 나니 공통된 패키지 C가 있었습니다.
그래서 두 패키지를 일관성 있게 관리하려면 패키지 C에 새로운 버전이 나올 때마다 패키지 A와 B에서 최신버전의 패키지 C를 npm으로 부터 다운받아 사용하도록 업데이트해야 하는 문제가 발생합니다.
또한 새로운 패키지를 생성할 때마다 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인를 다시 반복해서 구축해야 하는 문제점을 발견하게 됩니다.

![각각의 모듈화된 패키지를 개별 레포지토리에서 관리하는 방식을 멀티레포라고 한다.](/static/images/workspaces-in-yarn/multi-repo.png)

## 모노레포

많은 사람들이 이러한 문제에 공감하고 해결 방법을 생각한 끝에
하나의 레포지토리에 두 개 이상의 서로 의존성을 갖는 모듈화된 패키지를 관리하는 방식인 **모노레포**라는 접근 방식이 새롭게 등장하게 됩니다.

이에 따라 공통으로 사용되는 패키지를 업데이트하고 테스트하는 일이 훨씬 쉬워졌으며
패키지가 추가될 때마다 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인를 다시 반복해서 구축해야 하는 문제가 해결되었습니다.
또한 의존하는 패키지를 npm에 등록하지 않아도 다른 패키지에서 사용할 수 있게 되었습니다.

![하나의 레포지토리에 서로 의존성을 갖는 두 개 이상의 모듈화된 패키지를 관리하는 방식을 모노레포라고 한다.](/static/images/workspaces-in-yarn/mono-repo-without-workspaces.png)

## Lerna

모노레포가 등장함에 따라 하나의 레포지토리에서 여러 패키지들을 관리하게 되면서 생기는 많은 불편함이 있었고 이를 해결하기 위해
여러 패키지를 관리하는데 최적화된 툴인 [Lerna](https://lerna.js.org/)가 등장하게 됩니다.

Lerna를 이용하여 패키지를 설치하면 내부적으로 [Yarn](https://engineering.fb.com/2016/10/11/web/yarn-a-new-package-manager-for-javascript/) 또는 npm CLI를 사용하여
각각의 패키지에 들어가 `yarn/npm install`을 호출하고 패키지가 서로를 참조하는 경우에 [symlinks](https://classic.yarnpkg.com/lang/en/docs/cli/link/)를 생성해 줍니다.

하지만 이 당시의 Lerna도 내부적으로 Yarn과 같은 패키지 매니저를 사용하고 있었기 때문에 효과적으로 node_modules을 관리하는 데에는 한계가 있었습니다.
결국 불편함이라는 문제는 해결할 수 있었지만 같은 패키지가 여러 패키지에서 사용되는 경우에는 여러 번 다운로드 되는 문제가 있었습니다.

## Yarn Workspaces의 등장

이러한 이슈들을 보면서 패키지 매니저 개발자들은 Yarn 자체에서 이러한 문제를 해결해야겠다고 생각하게 되었고 Yarn Workspaces라는 기능을 개발하게 됩니다.

Yarn Workspaces는 하나의 레포지토리에서 여러 패키지들을 편리하고 효율적으로 관리할 수 있게 해주는 기능입니다.
최상단의 package.json에 workspaces를 정의하고 `yarn install`을 실행하게 되면 최상단의 패키지, 그리고 workspaces에 정의된 패키지들을 설치하게 됩니다.
또한 패키지가 중복되는 경우 호이스팅을 통해 최상위의 node_modules에 설치하여 중복 설치를 방지합니다.

![Yarn Workspaces 기능이 생김에 따라 중복되는 의존성을 효율적으로 관리할 수 있게 되었다.](/static/images/workspaces-in-yarn/mono-repo.png)

## Yarn Workspaces 사용해보기

이제는 yarn workspaces 기능을 활용하여 다음과 같은 구조를 갖는 모노레포를 구성해 보겠습니다.
(*yarn 1.22.19*)

```json
| jest/
| ---- package.json
| ---- packages/
| -------- jest-matcher-utils/
| ------------ package.json
| -------- jest-diff/
| ------------ package.json
...
```

### 최상단 package.json 생성

우선 jest라는 이름으로 패키지를 생성하고 `yarn init -y` 명령어를 실행하여 *package.json*을 생성한 후 다음과 같이 작성합니다.

- root의 경우 외부로 노출되지 않아야 하므로 private을 true로 설정합니다.
- packages 폴더에 있는 패키지들을 workspaces로 지정합니다.

```json line=6-9
{
  "name": "jest",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "workspaces": [
    "packages/*"
  ],
  "dependencies": {
    "chalk": "^2.0.1"
  }
}
```

### package 폴더 하위 package.json 생성

다음은 packages 폴더를 만들고 그 안에 *jest-matcher-utils*와 *jest-diff*라는 패키지를 생성하고 각각 *package.json*을 작성합니다.

```json line=6-9
{
  "name": "jest-matcher-utils",
  "version": "20.0.3",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "chalk": "^1.1.3",
    "pretty-format": "^20.0.3"
  }
}
```

```json line=6-11
{
  "name": "jest-diff",
  "version": "20.0.3",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "chalk": "^1.1.3",
    "diff": "^3.2.0",
    "jest-matcher-utils": "^20.0.3",
    "pretty-format": "^20.0.3"
  }
}
```

### 결과

1. 우선 *pretty-format*, *diff*같은 패키지와 jest-matcher-utils에 대한 symlinks는 최상단 node_modules 폴더로 호이스팅됨으로써 설치 사이즈를 줄이고 빠르게 설치됩니다.

2. *jest-matcher-utils*와 *jest-diff*는 공통적으로 *chalk*(^1.1.3)라는 의존성을 갖고 있고
최상단에서도 버전은 다르지만 *chalk*(^2.0.1)라는 의존성을 갖고 있습니다.
이 경우 최상단 node_modules에는 *chalk*(^2.0.1)가 설치되며 *jest-matcher-utils*와 *jest-diff* 각각의 node_modules에는 *chalk*(^1.1.3)가 설치됩니다.

```json
| jest/
| ---- node_modules/
| -------- chalk/
| -------- diff/
| -------- pretty-format/
| -------- jest-matcher-utils/  (symlink) -> ../packages/jest-matcher-utils
| ---- package.json
| ---- packages/
| -------- jest-matcher-utils/
| ------------ node_modules/
| ---------------- chalk/
| ------------ package.json
| -------- jest-diff/
| ------------ node_modules/
| ---------------- chalk/
| ------------ package.json
...
```

## 레퍼런스
- [Workspaces in Yarn](https://classic.yarnpkg.com/blog/2017/08/02/introducing-workspaces/)

- [nohoist in Workspaces](https://classic.yarnpkg.com/blog/2018/02/15/nohoist/)

- [모던 프론트엔드 프로젝트 구성 기법 - 모노레포 개념 편](https://d2.naver.com/helloworld/0923884)

변수명을 네이밍 할 때 고려해 볼 만한 몇 가지 규칙들을 소개합니다.

네이밍에 대하여


이 글은 [TkDodo](https://tkdodo.eu)의
[On naming things](https://tkdodo.eu/blog/on-naming-things) 포스트를 번역한 글입니다.

> 컴퓨터 과학에서 어려운 것은 오직 두 가지입니다: 캐시 무효화와 네이밍

<Author>Phil Karlton</Author>

이 두 가지 중에서 네이밍이야말로 가장 어려운 것이라 믿습니다.
왜냐하면 네이밍은 단순히 어려울 뿐만이 아니라 매우 주관적인 영억이기 때문입니다.
좋은 변수명이라고 생각하는 것이 다른 사람에게는 그렇지 않을 수도 있고
사소한 네이밍 문제에 대해 과도하게 신경을 쓰다가 더 크고 복잡한 문제를 놓칠 수 있기 때문에
때로는 이에 대한 논쟁이 무의미하기도 합니다.
좋은 변수명은 수치화시킬 수도 없기 때문에 팀이 커지게 될수록 일관성 있는 변수명을 유지하는 것이란 쉽지 않습니다.

## 왜 중요한가요?

> 누구라도 컴퓨터가 이해할 수 있는 코드는 작성할 수 있습니다.
> 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 작성합니다.

<Author>Martin Fowler, 2008</Author>

변수명은 프로그램을 이해하기에 있어 매우 중요한 부분입니다. 코드를 읽은 누구라도 어떤 것이 무엇을 의미하는지 알 수 있도록 상수, 함수, 파라미터에 변수명을 부여합니다.

컴퓨터는 실제로 이에 대해 신경 쓰지 않습니다. 사실, 프론트엔드 프로그래밍에서 많은 코드들은 브라우저에게 전달되기 전에 압축됩니다.

컴퓨터는 단순히 코드를 해석할 뿐 이해할 필요가 없습니다. 그러나 우리 같은 사람은 버그를 고치고 새로운 기능을 추가해야 할 필요가 있기에
코드에서 어떤 일이 벌어지고 있는지 이해하는 것은 가장 중요한 부분입니다.

그러면 어떤 것을 할 수 있을까요?

일관성 있는 코드 베이스를 지향하는 것이 이상적이라면 모든 팀들이 그들에게 맞는 네이밍 체계에 대해 고안하고 그것을 가능한 잘 시행해야 한다고 생각합니다.
개발자가 코드를 작성하는 것보다 더 많은 시간을 읽는데 사용하는 것이 잘 알려져 있으므로 항상 가독성과 유지 보수성을 위해 최적화하는 것이 좋습니다.

개인적으로 좋아하는 규칙 몇 가지를 알려드리겠습니다. 아마 이해가 되지 않을 수도 있는 주관적인 규칙도 있고 객관적을 봤을 때도 옳아 보이는 규칙도 있습니다.

## 줄여서쓰지 마세요

줄여서 쓰는 것은 흔하게 사용되는 것이더라도 (거의 항상) 선호하지 않습니다. 비개발자에게 PR(pull request)이라는 용어를 사용한다면
그들은 대부분 그것이 public relations(대인 관계)를 의미한다고 생각할 것입니다.
트위터는 작성할 수 있는 글자가 제한되어 있기 때문에 많은 사람들이 줄임말을 사용하게 만들었고 이는 가독성을 매우 안 좋게 만듭니다.
심지어 때로는 사람들이 줄임말에 오타를 작성해서 이해하는 것이 거의 불가능한 말을 만들어 냅니다.

그렇기에 저는 다음과 같이 가정하는 마인드셋을 가지고 있습니다:

> 줄임말이 사용될 때마다 적어도 팀에서 그것을 이해하지 못 하는 사람이 한 명은 있다.

<Author>TkDodo, 2020</Author>

최근에 OTOH(on the other hand - 반면에)가 무엇을 의미하는지 배웠습니다. 
다른 사람이 무엇을 모르는지 당신은 모르기 때문에 가독성을 위해서 가능한 줄임말은 피해주세요.

스코프가 작을 경우라면 괜찮습니다.

```jsx
posts.map((p) => p.id)
```

하지만 개인적으로는 *p* 대신에 *post*를 사용한다고 해서 어떤 해로운 점도 없다고 생각하기에 이것조차 하지 않습니다.

줄임말을 어쩔 수 없이 사용해야 하는 상황이 있기 때문에 가능한 한 피하려고 합니다. 
예를 들면, 대부분의 회사는 사업과 관련된 줄임말들이 있으며
리액트 같은 외부 라이브러리를 사용할 경우 props라는 줄임말을 어쩔 수 없이 사용해야 합니다.

[eslint-plugin-unicorn](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prevent-abbreviations.md)
처럼 이에 대해 알려주는 룰이 있기는 하지만 이 문제에 관해서는 관습과 상식을 따르는 것이 더 쉽다고 생각합니다.

## 인라인

사용되는 곳에 바로 작성하는 인라인 함수들은 몇 가지 장점이 있습니다.
첫 번째, 네이밍을 할 필요가 없습니다. 네이밍은 어렵기에 이는 매우 좋은 장점입니다.

두 번째, 변수명을 부여하는 것이 어렵고 가독성을 높여주지도 않을 때 함수를 인라인 합니다.
좋은 변수명이 떠오르지 않는다면 인라인을 사용하는 것도 좋습니다.

마지막, *TypeScript*를 사용한다면 타입이 자동으로 추론되며 많은 복잡도를 줄여줍니다.

```tsx
type Post = { id: string; title: string }

const getPostId = (post: Post) => post.id

// extracted
posts.map(getPostId)

// inlined
posts.map((post) => post.id)
```

이런 상황에서는 함수를 인라인 하는 것을 권장합니다:
- 자주 사용되지 않을 때
- 작을 때
- 의미 있는 변수명이 생각나지 않을 때

이는 리액트에서 이벤트 핸들러를 작성할 때 매우 효과적이고 성는에 부정적인 영향을 끼치지도 않습니다.

```jsx
<button onClick={() => login({ username, password })}>Login</button>
```

## 의미하는 것을 네이밍하기

```js
export const TWENTY = 20
```

초심자는 종종 마법의 숫자(예시의 20)를 사용하지 말라는 말을 듣곤 합니다. (모든 것은 반복하지 말아야 한다며)
만약 코드에서 마법의 숫자를 사용해야 한다면 상수로 추출하는 것을 잊지 마세요.
한곳만 수정하면 모든 곳이 수정될 수 있도록 진실의 원천은 단 하나여야 합니다.

위 상수의 문제점은 무엇을 의미하는지가 아닌 무엇인지를 네이밍 했다는 것입니다.
TWENTY가 다른 의미를 가지고 있을 수 있기 때문에 다양한 함수에서 사용할 수 없습니다.

```js
const calculateTaxes = (amount) => amount * percentage(TWENTY)
const sessionTimeout = minutes(TWENTY)
```

반복을 하지 않기 위해 같은 상수를 사용했는데도 그렇게 좋아 보이진 않습니다.

인라인 하는 것과 마찬가지로 표현하고자 하는 것이 두 번 이상 필요할 때 상수로 추출하세요.
비슷해 보인다고 해서 추상화를 하면 안 됩니다. - 실제로 나타내고자 하는 것이 같은 것이어야 합니다.

이렇게 표현하는 것이 더 좋은 변수명이 될 것이라고 생각합니다.

```js
const SALES_TAX = 20
const calculateTaxes = (amount) => amount * percentage(SALES_TAX)
```

이제서야 20이라는 숫자가 무엇을 의미하는지 알 수 있습니다.

이번에는 다른 예시로 다음과 같은 상태 값을 네이밍 해야 한다고 가정해 봅시다.

```jsx
const ??? = status === 'fetching' && !data

...

??? && <LoadingSpinner />
```

어떻게 네이밍을 하시겠어요?

a) *showLoading*

b) *isFetchingAndHasNoData*

c) *isInitializing*

## 현재 쓰임에 맞게 네이밍하기

a)처럼 로딩 스피너를 보여줄 것이므로 상태 값을 *showLoading*, *renderLoader*, 또는 *hasLoadingSpinner*로 네이밍 하는 방법입니다.

그러나 언젠가는 *Overlay*나 *Button* 같이 다른 무언가 보여주고 싶을지도 모르고 그렇게 된다면 이 변수명은 더 이상 유효하지 않습니다.
물론 모든 것을 미래를 예측하고 할 수는 없지만 약간의 변화가 생겨도 변수명에 타격이 없다는 것은 좋은 변수명이라는 증거입니다.

게다가 JSX를 읽으면 언제 스피너가 보이는지 알 방법이 없습니다. 코드는 이렇게 말하고 있기 때문이죠:

*로딩 스피너를 보여줘야만 한다면 로딩 스피너를 보여줍니다.*

구현 사항을 보지 않고는 무슨 상태 값인지 이해할 수 없기 때문에 이는 나쁜 변수명이라고 생각합니다.

## 구현사항에 맞게 네이밍하기

b)는 단언컨대 가장 나쁜 변수명 후보라고 할 수 있습니다. 이 상태 값의 구현 사항을 바꿀 때마다 변수명을 변경시켜야 하며 이는
이전의 *twenty* 예시와 매우 유사합니다.

## isInitializing

이것이 제가 생각하기에 가장 좋은 변수명입니다. 무엇이 발생하는지 가장 잘 묘사하고 있으며 이때 무엇이든 렌더링 할 수 있습니다. 
이 변수명은 쓰임과 강하게 결합되어 있지 않기 때문에 네이밍을 변경하지 않고도 initializing이 의미하는 것을 변경할 수 있습니다.

## 리액트 이벤트 핸들러

위와 같은 것이 리액트 이벤트 핸들러를 만들 때도 적용됩니다.

```jsx
const handleClick = () => {
  login(
    { userName, password },
    {
      onSuccess: (url) => routes.push(url),
      onError: () => showToast('Could not login'),
    }
  )
}

<button onClick={handleClick}>Login</button>
```

저 역시도 이렇게 몇 년간을 써왔지만 위에서 언급했던 것과 같은 문제를 가지고 있습니다: *handleClick*이 무엇이 발생할지에 대해 어떠한 정보도 알려주지 않으며
클릭 이벤트와 강하게 결합되어 있습니다.

만약 UX를 변경하기 위해 폼이 제출되었을 때 로그인하기를 원한다면 이벤트 핸들러의 변수명을 *handleSubmit*과 같이 변경해야 할 것입니다.

이벤트 핸들러를 *loginUser* 또는 *performLogin*처럼 네이밍 하는 것이 작은 차이지만 훨씬 더 정확하고 잘 함수를 설명해 줍니다.

## 핵심 내용

두 가지 중요 요점은 다음과 같습니다:

- 구현 사항이 변경되면 변수명이 바뀌어야 하는가? (a)
- 쓰임이 변경되면 변수명이 바뀌어야 하는가? (b)

만약 그렇다면 매우 좋은 변수명은 아닐 것입니다.


state를 관리할 때, 상황에 따라 useState와 useReducer 중 어떤 것을 사용하면 좋을지 알아봅니다.

useState vs useReducer


이 글은 [TkDodo](https://tkdodo.eu)의
[useState vs useReducer](https://tkdodo.eu/blog/use-state-vs-use-reducer) 포스트를 번역한 글입니다.

## useState의 함정

- [#1: useState를 남용하지 마세요](/blog/dont-over-use-state)
- [#2: props를 useState에 전달하기](/blog/putting-props-to-use-state)
- [#3: useState에 대해 알아야 할 것들](/blog/things-to-know-about-use-state)
- [#4: 일회성 초기화를 위한 useState](/blog/use-state-for-one-time-initializations)
- <b>#5: useState vs useReducer</b>

---

어떤 state 관리 솔루션을 사용해야지에 대한 질문은 아마도 react가 탄생한 시점부터 (어쩌면 그 이전부터) 존재해왔고
그에 대한 답변은 다양합니다. 저에게는 오직 하나의 좋은 답변이 존재하며 어떠한 복잡한 질문에도 동일합니다.

> 상황에 따라 다릅니다.

<Author>TkDodo</Author>

state의 유형, 변경 주기 그리고 범위에 따라서 다를 수 있습니다.

## 클라이언트 state

hook이 탄생하기 이전에 클라이언트 지역 state를 관리하는 방법은 단 하나였습니다: 클래스 컴포너트에서의 *this.setState*.
state는 반드시 객체여야 했으며 변경 함수는 state의 일부분만 받는 것을 허용했습니다.

hook은 근본적인 방식을 바꿨습니다. 함수형 컴포넌트에서 state를 관리할 수 있게 했을 뿐만 아니라 *useState* 와 *useReducer*라는 두 가지 다른 선택지를 제공했습니다.

클래스 기반에서 hook 기반 state 관리로 바꿀 때 대부분의 사람들의 접근 방법은 하나의 객체를 각각의 필드를 값으로 하는 *useState*로 변경하는 것입니다.

이전:

```jsx
class Names extends React.Component {
  state = {
    firstName: '',
    lastName: '',
  }

  render() {
    return (
      <div>
        <input
          value={this.state.firstName}
          onChange={(event) =>
            this.setState({ firstName: event.target.value })
          }
        />
        <input
          value={this.state.lastName}
          onChange={(event) =>
            this.setState({ lastName: event.target.value })
          }
        />
      </div>
    )
  }
}
```

이후:

```jsx
const Names = () => {
  const [firstName, setFirstName] = React.useState('')
  const [lastName, setLastName] = React.useState('')

  return (
    <div>
      <input
        value={firstName}
        onChange={(event) => setFirstName(event.target.value)}
      />
      <input
        value={lastName}
        onChange={(event) => setLastName(event.target.value)}
      />
    </div>
  )
}
```

마치 책에 나올 것만 같은 예시지만 여기서는 실제로 말이 됩니다.
두 개의 필드들이 자체적으로 변경되므로 자급자족할 수 있기 때문입니다.

그러나 항상 이런 경우만 있는 건 아닙니다. 때로는 같이 변경되어야 하는 state가 있으며
이런 상황에서는 여러 개의 *useState*로 분리시키는 것이 적합하다고 생각하지 않습니다.

한 예시로 마우스의 좌표(x, y)를 저장하는 것을 들 수 있습니다.
항상 동시에 변경되는 것에 두 개의 *useState*를 사용하는 것은 너무 이상하다고 생각하기에 이럴 경우에는 하나의 state 객체를 사용합니다:

```jsx
const App = () => {
  const [{ x, y }, setCoordinates] = React.useState({ x: 0, y: 0 })

  return (
    <button
      onClick={(event) => {
        setCoordinates({ x: event.screenX, y: event.screenY })
      }}
    >
      Click, {x} {y}
    </button>
  )
}
```

## 폼 state

사용할 때마다 구조가 다르고 한 번에 한 필드만 변경하는 일반적인 폼의 경우에는
하나의 state 객체를 사용하는 것 또한 잘 동작합니다.
몇 개의 필드가 들어갈지 모르기에 여러 개의 *useState*를 사용할 수 없으므로 기본적인 커스텀 hook은
다음과 같이 구현할 수 있습니다.

```tsx
const useForm = <State extends Record<string, unknown>>(
  initialState: State
) => {
  const [values, setValues] = React.useState(initialState)
  const update = <Key extends keyof State>(name: Key, value: State[Key]) =>
    setValues((form) => ({ ...form, [name]: value }))

  return [values, update] as const
}
```

그래서 *useState*의 경우 state를 분리할지 말지 결정할 때 다음 규칙을 적용합니다.

<Mark>동시에 변경되는 state는 같이 있어야 합니다.</Mark>

## Batching

여러 state를 만들어서 변경 함수를 연달아 호출하지 않고 하나의 state 객체를 만들어 변경 함수를 한 번 호출하는 것을 고려해 보세요.
react는 동기 이벤트 핸들러에서 state를 한꺼번에 변경하는 것을 매우 잘 하지만 비동기 함수에서는 문제가 있습니다.
이 이슈는 [react 18에서의 자동 batching](https://github.com/reactwg/react-18/discussions/21)에 의해 해결됐지만 
성능과는 상관없이 어떤 state가 함께 변경되는지, 안 되는지를 추론할 수 있도록 코드를 구조화하는 것은 장기적인 측면에서 가독성과 유지 보수에 많은 도움이 됩니다.

## useReducer

[useReducer](https://ko.reactjs.org/docs/hooks-reference.html#usereducer)가 너무 적게 사용되고 있다고 생각합니다.
대다수의 사람들이 *useReducer*를 "복잡한 state"를 관리할 때만 필요로 하다고 생각하고 있지만
이전에 말했듯이 [state를 토글](https://tkdodo.eu/blog/things-to-know-about-use-state#bonus2-toggling-state-with-usereducer)하는 상황에서도 활용할 수 있습니다.

```jsx
const [value, toggleValue] = React.useReducer(previous => !previous, true)

<button onClick={toggleValue}>Toggle</button>
```

또한 *forceUpdate*(거의 모든 전역 state 관리 라이브러리는 state가 react 외부에서 관리되고 있다면 구독자에게 state 변경을 알리기 위해 이를 필요로 합니다.)를 구현하는데도 사용할 수 있습니다.

```jsx
const forceUpdate = React.useReducer((state) => state + 1, 0)[1]
```

**변경사항**: React 18부터 [useSyncExternalStore](https://ko.reactjs.org/docs/hooks-reference.html#usesyncexternalstore) hook을 제공하게 돼서
전역 state 관리 라이브러리는 *forceUpdate*를 사용하지 않기 시작했습니다.

위 구현 사항은 복잡하지 않으며 *useReducer*의 유연성을 잘 보여준다고 생각합니다.
이와 더불어 state의 여러 부분을 다른 "액션"에 따라 변경할 때도 빛을 발합니다.
예를 들어 여러 단계가 있는 무언가를 구현할 때 두 번째 단계에서는 첫 번째 단계의 데이터를 기반으로 값을 초기화하거나
세 번째 단계의 데이터를 두 번째 단계로 돌아갔을 때 버리기도 합니다.

독립적인 *useState*가 있을 때(한 단계에 하나씩) 이러한 state 사이의 의존성이 있다면 
*setState*를 여러 차례 연달아 호출해야 합니다.


### useReducer 팁

*useReducer*를 사용할 때면 [리덕스 스타일 가이드](https://redux.js.org/style-guide/)를 적용하려고 합니다.

완전히 추천할 수 있는 훌륭한 글이며 대부분의 요점이 *useReducer*에 잘 적용됩니다.
예를 들어
- [Do Not Mutate State](https://redux.js.org/style-guide/#do-not-mutate-state)
- [Reducers Must Not Have Side Effects](https://redux.js.org/style-guide/#reducers-must-not-have-side-effects)
- [Model Actions as Events, not Setters](https://redux.js.org/style-guide/#model-actions-as-events-not-setters)

#### 이벤트 주도 reducer

대부분의 사람들은 reducer에서 불변성을 유지하고 부수효과를 가지지 않는 것을 자연스레 적용합니다. (react 자체에서 요구하는 것과 동일하기에)

액션을 이벤트로써 모델링 하는 것은 reducer의 가장 큰 장점이기에 매우 강조하고 싶습니다. 
그렇게 함으로써 모든 어플리케이션 로직을 ui의 다양한 부분에 펼쳐놓는 대신 reducer 내부에서 관리할 수 있습니다.
이는 state 변화를 추론하기 쉽게 만들 뿐만 아니라 로직을 테스트하기 매우 쉽게 만들어줍니다. (순수 함수는 테스트하기 가장 쉽기 때문입니다.)

이 컨셉을 보여주기 위해 전형적인 *counter* 예시를 보여드리겠습니다.

```jsx
const reducer = (state, action) => {
  // ✅ ui는 이벤트만 전달하며 로직은 reducer 내부에 존재하게 됩니다.
  switch (action) {
    case 'increment':
      return state + 1
    case 'decrement':
      return state - 1
  }
}

function App() {
  const [count, dispatch] = React.useReducer(reducer, 0)

  return (
    <div>
      Count: {count}
      <button onClick={() => dispatch('increment')}>Increment</button>
      <button onClick={() => dispatch('decrement')}>Decrement</button>
    </div>
  )
}
```

정교하지는 않으나 (1을 추가 또는 1을 빼기) 이 또한 로직입니다.
얼마를 추가하거나 뺄지 결정할 수 있도록 만들 수도 있습니다.

모든 것은 reducer *내부에서* 이뤄집니다.
그것을 오직 새로운 숫자만 받는 "어리석은" reducer 예시와 비교해 보세요.

```jsx
const reducer = (state, action) => {
  switch (action.type) {
    // 🚨 새로운 숫자만 받는 "어리석은" reducer
    case 'set':
      return action.value
  }
}

function App() {
  const [count, dispatch] = React.useReducer(reducer, 0)

  return (
    <div>
      Count: {count}
      <button onClick={() => dispatch({ type: 'set', value: count + 1 })}>
        Increment
      </button>
      <button onClick={() => dispatch({ type: 'set', value: count - 1 })}>
        Decrement
      </button>
    </div>
  )
}
```

동작은 하지만 이전 예시처럼 확장 가능하지는 않습니다. 그러니 일반적으로 *set*이라는 이름을 가진 액션들은 피하도록 하세요.

#### reducer에 props 전달하기

reducer의 또 다른 좋은 특성은 인라인 하거나 클로져를 통해 props에 접근할 수 있다는 것입니다.
이 방법은 reducer *내부에서* props 또는 서버 state(예. [useQuery](https://tanstack.com/query/v4/?from=reactQueryV3&original=https://react-query-v3.tanstack.com/) hook이 리턴하는 state)에 접근할 때 매우 유용합니다.
state 초기화를 통해 이러한 값들을 "복사"하지 않고도 reducer 함수에 전달할 수 있습니다.

```jsx
const reducer = (data) => (state, action) => {
  // ✅ 항상 최신 서버 state에 접근할 수 있습니다.
}

function App() {
  const { data } = useQuery(key, queryFn)
  const [state, dispatch] = React.useReducer(reducer(data))
}
```

이것은 [서버와 클라이언트 state를 분리](https://tkdodo.eu/blog/practical-react-query#keep-server-and-client-state-separate) 시켜야 한다는 컨셉과 매우 잘 맞습니다.
그리고 만약에 data를 *초기값*으로 전달한다고 해도 reducer가 처음 실행될 때는 data가 *undefined*이므로 동작하지 않을 것입니다.

그러면 state 동기화를 위해 useEffect 만드려고 할 것이며 이는 background update와 관련된 모든 종류의 문제가 발생할 수 있습니다.

이 접근법으로 이벤트 주도 counter 예시를 서버에서 받아온 amount 만큼 더하거나 빼도록 확장시켜 보겠습니다.
커스텀 hook을 이용해 보겠습니다.

```jsx
const reducer = (amount) => (state, action) => {
  switch (action) {
    case 'increment':
      return state + amount
    case 'decrement':
      return state - amount
  }
}

const useCounterState = () => {
  const { data } = useQuery(['amount'], fetchAmount)
  return React.useReducer(reducer(data ?? 1), 0)
}

function App() {
  const [count, dispatch] = useCounterState()

  return (
    <div>
      Count: {count}
      <button onClick={() => dispatch('increment')}>Increment</button>
      <button onClick={() => dispatch('decrement')}>Decrement</button>
    </div>
  )
}
```

커스텀 hook으로 로직을 명확하게 분리했기 때문에 ui 쪽에는 변경사항이 없다는 것을 주목해 주세요.

## 경험에 따른 법칙

경험상 언제 무엇을 써야 할지는 다음과 같습니다:

- 만약 state 변경이 독릭접으로 이뤄진다면 - 여러 *useState*로 분리하세요.
- 동시에 변경되거나 한 번에 하나의 필드만 변경(ex. 폼) 된다면 - 하나의 *useState*와 객체를 사용하세요.
- 사용자의 인터렉션이 state의 다른 부분을 변경한다면 (state가 서로 의존한다면) - *useReducer*를 사용하세요.


앱이 실행되고 종료될 때까지 단 한 번만 초기화하고 싶은 값이 있을 때 어떤 방법이 좋을지 알아봅니다.

일회성 초기화를 위한 useState


이 글은 [TkDodo](https://tkdodo.eu)의
[useState for one-time initializations](https://tkdodo.eu/blog/use-state-for-one-time-initializations) 포스트를 번역한 글입니다.

## useState의 함정

- [#1: useState를 남용하지 마세요](/blog/dont-over-use-state)
- [#2: props를 useState에 전달하기](/blog/putting-props-to-use-state)
- [#3: useState에 대해 알아야 할 것들](/blog/things-to-know-about-use-state)
- <b>#4: 일회성 초기화를 위한 useState</b>
- [#5: useState vs useReducer](/blog/use-state-vs-use-reducer)

---

메모이제이션과 참조 값 안정성(렌더 시 함수, 객체 등이 변하지 않았다면 동일한 참조 값을 유지하는 것)에 대해 얘기할 때 가장 먼저 떠오르는 생각은 보통 *useMemo*입니다.
오늘은 많은 글을 쓰고 싶은 기분이 아니라서 바로 본론으로 넘어가서 이번 주에 제가 경험한 문제를 예시로 보여드리겠습니다.

## 예시

앱이 실행되고 단 한 번만 초기화하고 싶은 *resource*가 있다고 가정해 봅시다.
권장되는 패턴은 보통 *Component* 외부에 인스턴스를 생성하는 것입니다.

```jsx
// ✅ 정적 인스턴스가 단 한 번 생성됩니다.
const resource = new Resource()

const Component = () => (
  <ResourceProvider resource={resource}>
    <App />
  </ResourceProvider>
)
```

상수 *resource*는 자바스크립트 번들이 평가될 때 단 한 번 생성되며 *ResourceProvider*에 의해 *App* 내부에서 접근할 수 있습니다.
이것은 보통 [리덕스 스토어](https://react-redux.js.org/api/provider#example-usage)처럼 앱에서 단 하나인 *resource*에 대해 잘 동작합니다.

그러나 [마이크로 프론트엔드](https://micro-frontends.org/)의 경우 *Component*를 여러 번 마운트하며
각각 고유한 *resource*를 필요로합니다. 동일한 *resource*를 공유한다면 문제가 되므로 이를 *Component* 내부로 이동시켜야만 합니다.

```jsx
const Component = () => {
  // 🚨 유의: 매 렌더 시 새로운 인스턴스가 생성됩니다.
  const resource = new Resource()
  return (
    <ResourceProvider resource={new Resource()}>
      <App />
    </ResourceProvider>
  )
}
```

확실히 좋은 방법은 아니라고 생각합니다. 렌더 함수가 이제는 새로운 *resource*를 매 렌더 시 생성하니까요!
*Component*를 한 번 렌더 하는 경우에는 동작하겠지만 좋은 방법은 아닙니다. 
언젠가는 리렌더가 발생할 수 있으므로 이에 준비해야 합니다.

머릿속에 가장 먼저 떠오른 해결 방법은 *useMemo*입니다.
*useMemo*는 의존성이 변경되었을 때만 다시 계산되고 여기서는 의존성을 가질 필요가 없으니 다음과 같이 우아하게 작성해 볼 수 있습니다.

```jsx
const Component = () => {
  // 🚨 여전히 불안정적
  const resource = React.useMemo(() => new Resource(), [])
  return (
    <ResourceProvider resource={resource}>
      <App />
    </ResourceProvider>
  )
}
```

때로는 잘 동작할 수 있지만 [react 공식 문서](https://ko.reactjs.org/docs/hooks-reference.html#usememo)에서 *useMemo*에 대해 어떻게 말하는지 인용해 보겠습니다:

> **useMemo는 성능 최적화를 위해 사용할 수는 있지만 의미상으로 보장이 있다고 생각하지는 마세요.**<br/>
> 가까운 미래에 React에서는, 이전 메모이제이션된 값들의 일부를 “잊어버리고” 다음 렌더링 시에 그것들을 재계산하는 방향을 택할지도 모르겠습니다.
> 예를 들면, 오프스크린 컴포넌트의 메모리를 해제하는 등이 있을 수 있습니다.
> useMemo를 사용하지 않고도 동작할 수 있도록 코드를 작성하고 그것을 추가하여 성능을 최적화하세요

*useMemo*를 사용하지 않고도 동작할 수 있도록 코드를 작성해야 한다면 사용한다고 해서 더 좋은 코드를 작성한 것이 아닙니다.
우리는 참조 값 유지를 원하는 것이지 퍼포먼스에 관심이 있는 것이 아닙니다.
그러기 위해서는 무엇이 최선의 방법일까요?

## 우리를 구출해줄 state

이를 위한 해결 방법은 결국 state입니다.
state는 갱신 함수를 호출했을 때만 변경되는 것이 보장됩니다.
해야 할 일은 단순히 갱신 함수를 호출하지 않는 것이고 이는 *useState* 반환 값의 두 번째 인자이므로 이를 구조 분해 할당하지 않으면 됩니다.
*resource* 생성자가 마운트 시에만 호출되는 것을 보장하기 위해 [지연 초기화](/blog/things-to-know-about-use-state#2-지연-초기화)를 같이 사용할 수도 있습니다.

```jsx
const Component = () => {
  // ✅ 완전히 안정적
  const [resource] = React.useState(() => new Resource())
  return (
    <ResourceProvider resource={resource}>
      <App />
    </ResourceProvider>
  )
}
```

이 방법을 사용하면 *resource*가 단 한 번만 생성되는 것을 보장할 수 있습니다.

## ref를 사용하는 건 어떤가요?

[useRef](https://ko.reactjs.org/docs/hooks-reference.html#useref)를 사용해도 동일한 목적을 달성할 수 있다고 생각합니다.
그리고 [React의 규칙](https://gist.github.com/sebmarkbage/75f0838967cd003cd7f9ab938eb1958f)에 따르면 이 방법이 렌더 함수의 순수성을 파괴하는 것도 아닙니다.

```jsx
const Component = () => {
  // ✅ 여전히 동작합니다. 그런데 음...
  const resource = React.useRef(null)
  if (!resource.current) {
    resource.current = new Resource()
  }
  return (
    <ResourceProvider resource={resource.current}>
      <App />
    </ResourceProvider>
  )
}
```

하지만 솔직히 말하자면 이렇게 사용해야 할 이유가 없습니다. - 이건 복잡해 보이기도 하고 *resource.current*가 null 일 수 있으니 타입스크립트가 좋아하지 않을 것 같습니다.
그래서 저는 단순히 *useState*를 사용하는 것을 선호합니다.


매일 유용하게 써먹을 수 있는 5가지 useState 팁을 소개합니다.

useState에 대해 알아야 할 것들


이 글은 [TkDodo](https://tkdodo.eu)의
[Things to know about useState](https://tkdodo.eu/blog/things-to-know-about-use-state) 포스트를 번역한 글입니다.

## useState의 함정

- [#1: useState를 남용하지 마세요](/blog/dont-over-use-state)
- [#2: props를 useState에 전달하기](/blog/putting-props-to-use-state)
- <b>#3: useState에 대해 알아야 할 것들</b>
- [#4: 일회성 초기화를 위한 useState](/blog/use-state-for-one-time-initializations)
- [#5: useState vs useReducer](/blog/use-state-vs-use-reducer)

---

[React.useState](https://ko.reactjs.org/docs/hooks-reference.html#usestate)는 매우 사용하기에 직관적입니다.
초기값을 전달하면 값과 그 값을 갱신하는 함수를 반환합니다.
어떤 보석 같은 정보가 여기 숨어 있을까요?
매일 유용하게 써먹을 수 있는 5가지 팁을 소개하겠습니다.

## 1: 함수적 갱신

react 클래스 컴포넌트에서의 *setState*가 그렇듯 *useState* 또한 [함수적 갱신](https://ko.reactjs.org/docs/hooks-reference.html#functional-updates)이 가능합니다.
*useState*가 반환한 갱신 함수에는 새로운 값을 전달하는 대신 함수를 전달할 수 있습니다.
react는 이전 값으로 새로운 값을 계산할 수 있도록 이전 값을 받아 갱신된 값을 반환하는 함수를 호출할 것입니다.

```jsx
const [count, setCount] = React.useState(0)

// 🚨 다음 값을 계산하기위해 현재의 count에 의존
<button onClick={() => setCount(count + 1)}>Increment</button>

// ✅ 다음 값을 계산하기위해 previousCount 사용
<button onClick={() => setCount(previousCount => previousCount + 1)}>Increment</button>
```

어떤 방식이든 큰 차이가 없는 것처럼 보이지만 일부 상황에서는 미묘한 버그가 발생할 수 있습니다.

## 갱신 함수 여러 번 호출하기

<Sandpack 
  files={{'/App.js':`import React from 'react';

function App() {
  const [count, setCount] = React.useState(0);

  return (
    <button
      onClick={() => {
        setCount(count + 1);
        setCount(count + 1);
      }}
    >
      🚨 예상대로 동작하지 않음, count: {count}
    </button>
  );
}

export default App;`}}
/>

두 *setCount* 모두 같은 값(*count*)을 바라보고 있기 때문에 각각의 클릭이 숫자를 하나씩만 증가시킬 것입니다.
*setCount*는 *count*를 즉시 갱신하지 않음을 아는 것은 매우 중요합니다.
*useState*의 갱신 함수는 단지 갱신을 계획합니다.
react에게 이렇게 말합니다:

> 이 값을 새 값으로 갱신해 줘, 언젠가

위 예시에서는 react에게 같은 말을 두 번 했습니다:
> count를 2로 갱신해 줘<br/>
> count를 2로 갱신해 줘

위는 말하고자 의도했던 바가 아닙니다. 표현하고자 했던 바는 다음과 같습니다.
> 현재 값을 증가시켜줘<br/>
> 현재 값을 증가시켜줘(다시)

함수적 갱신은 이를 보장해 줍니다.

<Sandpack
  files={{'/App.js':`import React from 'react';

function App() {
  const [count, setCount] = React.useState(0);

  return (
    <button
      onClick={() => {
        setCount((previousCount) => previousCount + 1);
        setCount((previousCount) => previousCount + 1);
      }}
    >
      ✅ 2씩 증가, count: {count}
    </button>
  );
}

export default App;`}}
/>

## 비동기 액션이 포함되었을 때

Kent C. Dodds이 이에 대한 긴 포스트를 [여기](https://kentcdodds.com/blog/use-state-lazy-initialization-and-function-updates) 작성했습니다.
그리고 결론은 다음과 같습니다:
> 새로운 state를 이전 state를 기반으로 계산해야 할 때마다 함수적 갱신을 사용합니다.

<Author>Kent C. Dodds</Author>

위의 결론에 동의하며 해당 포스트를 자세히 읽어보는 것을 추천합니다.

## 보너스: 의존성 피하기

함수적 갱신을 잘 이용하면 *useEffect*, *useMemo*, *useCallback*의 의존성 배열을 입력하지 않아도 됩니다.
메모이제이션된 자식 컴포넌트에 증가함수를 전달하려 한다고 생각해 보세요.
*useCallback*을 사용해 함수가 너무 자주 재생성되지 않도록 할 수는 있지만 여전히 count가 변할 때마다 새로운 참조 값을 갖는 함수를 재생성할 것입니다.
함수적 갱신을 이용하면 이 문제를 해결할 수 있습니다.

```jsx
function Counter({ incrementBy = 1 }) {
  const [count, setCount] = React.useState(0)

  // 🚨 count가 갱신될 때마다 새로운 함수를 생성
  const increment = React.useCallback(() => setCount(count + incrementBy), [
    incrementBy,
    count,
  ])

  // ✅ count를 사용하지 않음으로써 위 문제 해결
  const increment = React.useCallback(
    () => setCount((previousCount) => previousCount + incrementBy),
    [incrementBy]
  )
```

## 보너스 2: useReducer로 state 토글 하기

이전에 한두 번쯤은 boolean state를 토글 해봤을 겁니다.

```jsx
const [value, setValue] = React.useState(true)

<button onClick={() => setValue(previousValue => !previousValue)}>Toggle</button>
```

단순히 state 토글을 하려고 한다면 *useReducer*가 더 나은 선택이 될 수 있습니다. 왜냐면:
- 토글 로직을 hook을 호출하는 곳으로 옮길 수 있고
- 토글 함수의 이름을 직접 정할 수 있고(그저 값을 갱신하는 함수가 아닙니다)
- 토글 함수를 여러 번 사용한다면 반복적인 코드를 줄여줍니다.

```jsx
const [value, toggleValue] = React.useReducer(previous => !previous, true)

<button onClick={toggleValue}>Toggle</button>
```

이 예시는 *useReducer*가 "복잡한" state를 다룰 때만 좋은 것은 아니라는 것과 굳이 이벤트를 dispatch 않아도 됨을 보여준다고 생각합니다.

## 2: 지연 초기화

*useState*에 초기값을 전달할 때 해당 값은 항상 생성되지만 react는 첫 번째 렌더에만 그 값을 사용합니다.
예를 들어 문자열을 초기값으로 전달할 때와 같이 대부분의 경우에는 이것이 문제가 되지 않습니다.
그러나 때로는 state를 복잡한 값으로 초기화할 필요가 있습니다.
그런 상황에서는 *useState*의 초기값 자리에 함수를 전달할 수 있습니다.
그러면 react는 컴포넌트가 마운트 됐을 때만 함수를 호출합니다.

```jsx
// 🚨 매 렌더마다 불필요하게 계산
const [value, setValue] = React.useState(
  calculateExpensiveInitialValue(props)
)

// ✅ 아주 조금 달라보이지만 함수가 오직 마운트 됐을 때 한 번만 호출됨
const [value, setValue] = React.useState(() =>
  calculateExpensiveInitialValue(props)
)
```

## 3: 갱신되지 않는 경우

값을 갱신하는 함수를 호출한다고 항상 react가 컴포넌트를 리렌더하지는 않습니다.
현재 state와 같은 값으로 갱신을 하려는 경우 렌더링 되지 않습니다.
react는 값이 다른지 확인하기 위해 [Object.is](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is#description)를 사용합니다.
라이브 예시로 확인해 보세요.

<Sandpack 
  files={{'/App.js':`import React from 'react';

function App() {
  const [name, setName] = React.useState("Elias");

  // 🤯 이 버튼을 클릭해도 컴포넌트가 리렌더되지 않습니다.
  return (
    <button onClick={() => setName("Elias")}>
      Name is: {name}, Date is: {new Date().getTime()}
    </button>
  );
}

export default App;`}}
/>

## 4. 편리한 오버로드

이번에는 Typescript 사용자를 팁입니다. *useState*는 보통 타입 추론을 잘 지원하지만
*undefined* 또는 *null*로 초기화하려는 경우 명시적으로 제네릭 파라미터를 입력해야 합니다.
그렇지 않으면 Typescript는 제대로 동작하기 위한 충분한 정보를 알 수 없습니다.

```tsx
// 🚨 age는 `undefined`로 추론될 것이며 이는 쓸모없습니다.
const [age, setAge] = React.useState(undefined)

// 🆗 짧지 않지만...
const [age, setAge] = React.useState<number | null>(null)
```

*useState*에는 초기값을 완전히 생략하면 전달한 타입에 *undefined*를 추가해 주는 [편리한 오버로드](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/7a0d9c019f2b48b36b88691247870e6885b97a02/types/react/v16/index.d.ts#L921-L928)가 있습니다.
파라미터를 전달하지 않으면 *undefined*를 명시적으로 전달하는 것과 동일하므로 런타임에 *undefined*가 될 것입니다.

```tsx
// ✅ age는 `number | undefined`
const [age, setAge] = React.useState<number>()
```

물론 *null*로 초기화할 경우에는 편리한 오버로드가 없으므로 긴 버전을 사용해야 합니다.

## 5: 세부 구현사항

*useState*는 *useReducer*로 구현되어 있습니다. react [소스 코드](https://github.com/facebook/react/blob/1a7472624661270008011fd77f097d71e6249de9/packages/react-reconciler/src/ReactFiberHooks.new.js#L1242-L1246)에서 확인해 볼 수 있습니다.
또한 Kent C. Dodds가 [어떻게 useReducer로 useState를 구현하는지](https://kentcdodds.com/blog/how-to-implement-usestate-with-usereducer)에 대해 작성한 좋을 글이 있습니다.

## 결론

5개의 팁 중 처음부터 3개는 글의 도입부에 링크된 react 공식 문서의 Hooks API Reference에 언급되어 있습니다.
이전까지는 이 팁들에 대해 모르고 있었다면 - 이제는 알고 있습니다!


props로 받은 값으로 state를 초기화하는 상황에 대해 다룹니다.

props를 useState에 전달하기


이 글은 [TkDodo](https://tkdodo.eu)의
[Putting props to useState](https://tkdodo.eu/blog/putting-props-to-use-state) 포스트를 번역한 글입니다.

## useState의 함정

- [#1: useState를 남용하지 마세요](/blog/dont-over-use-state)
- <b>#2: props를 useState에 전달하기</b>
- [#3: useState에 대해 알아야 할 것들](/blog/things-to-know-about-use-state)
- [#4: 일회성 초기화를 위한 useState](/blog/use-state-for-one-time-initializations)
- [#5: useState vs useReducer](/blog/use-state-vs-use-reducer)

---

useState의 함정 시리즈의 [첫 번째 파트](/blog/dont-over-use-state)에서는 파생된 state를 다룰 때 또 다른 state를 선언하는 것을 피하라고 말했습니다.

이번 파트는 props로 받은 값으로 state를 초기화하는 상황에 대해 다룹니다. 아마 흔하게 이용하는 방법이고 그 자체로 잘못된 방법은 아니지만 이 방법에는 우리가 알고 있어야 할 잠재적인 문제가 있습니다.

## 예시

전형적인 목록 / 상세 사용 사례를 예시로 들도록 하겠습니다. 사람들로 이루어진 목록이 있고 그들 중 한 명을 선택하면 그 사람에 대한 정보로 채워진 상세 폼이 나오는 방식입니다.
상세 폼에서는 사람의 이메일 주소를 보여주고 apply 버튼을 클릭하면 데이터를 변경하려고 합니다.

인터렉티브한 예시이니 마음껏 클릭해 보세요(코드를 변경할 수도 있습니다🚀)

<Sandpack
  files={{'/App.js':`import React from 'react';
import DetailView from './DetailView';

const persons = [
  {
    id: 1,
    name: "Dominik",
    email: "dominik@dorfmeister.cc",
  },
  {
    id: 2,
    name: "John",
    email: "john@doe.com",
  },
];

function App() {
  const [selected, setSelected] = React.useState(persons[0]);

  return (
    <div>
      {persons.map((person) => (
        <button
          type="button"
          key={person.id}
          onClick={() => setSelected(person)}
        >
          {person.id === selected.id ? person.name.toUpperCase() : person.name}
        </button>
      ))}
      <DetailView initialEmail={selected.email} />
    </div>
  );
}

export default App;
`,
"/DetailView.js":`import React from 'react';

function DetailView({ initialEmail }) {
  const [email, setEmail] = React.useState(initialEmail);

  return (
    <div>
      <input
        type="text"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
      />
      <button type="button" onClick={() => alert(email)}>
        Apply
      </button>
    </div>
  );
}

export default DetailView;
`}}
/>

## useState 초기값

위 예시가 동작하지 않음을 바로 눈치채셨을 겁니다.
이메일 주소를 변경하고 John을 클릭해도 입력 요소는 변경되지 않습니다.

리액트가 state에 관해서라면 생명주기가 아닌 [hook으로 생각하기](https://wattenberger.com/blog/react-hooks)를 기대하는 만큼
첫 번째 렌더(마운트) 그리고 추가 렌더(리렌더) 사이에는 큰 차이가 있습니다.

리렌더 시에는 useState hook의 초기값이 항상 버려집니다 - 초기값은 오직 컴포넌트가 마운트 될 때만 사용됩니다.

John을 클릭했을 때 DetailView 컴포넌트는 리렌더될 것이며(이미 스크린에 존재했기 때문에)
이는 John의 이메일이 초기값으로서 state에 담기지 않을 것임을 의미합니다.
여전히 이메일 주소를 변경하기 위해 지역 state를 필요로 하기 때문에 사람으로 이뤄진 배열을 직접 변경하기를 원하진 않습니다.
(apply 버튼을 눌렀을 때만 배열의 값이 변경되길 원하므로)

이런 경우 또는 비슷한 경우를 다루기 위한 3가지 방법이 있습니다.

## 1. DetailView 컴포넌트 조건부 렌더

모달 또는 스크린에 나타나는 다른 컴포넌트들을 사용할 때 이 방식을 많이 사용합니다.

모달 안에서 DetailView 컴포넌트를 보여준다면 조건부로 렌더링 되기 때문에 마법처럼 위의 코드 예시가 동작할 것입니다.
John을 클릭하면 Modal과 DetailView가 마운트 되면서 useState 초기값이 사용될 것입니다.
모달을 닫으면 언마운트 될 것이고 다음에 사람이 클릭되면 다시 마운트 될 것입니다.

어떻게 그렇게 할 수 있을지 보여드리겠습니다. 

<Sandpack
  files={{'/App.js':`import React from 'react';
import DetailView from './DetailView';

const persons = [
  {
    id: 1,
    name: "Dominik",
    email: "dominik@dorfmeister.cc",
  },
  {
    id: 2,
    name: "John",
    email: "john@doe.com",
  },
];

function App() {
  const [selected, setSelected] = React.useState();

  const close = () => setSelected(undefined);

  return (
    <div>
      {persons.map((person) => (
        <button
          type="button"
          key={person.id}
          onClick={() => setSelected(person)}
        >
          {person.name}
        </button>
      ))}
      {selected && (
        <div
          style={{
            position: "fixed",
            top: "0",
            left: "0",
            paddingTop: "100px",
            width: "100%",
            height: "100%",
            backgroundColor: "rgba(0,0,0,0.4)",
          }}
        >
          <div
            style={{
              display: "flex",
              justifyContent: "center",
              width: "80%",
              height: "50vh",
              margin: "auto",
              backgroundColor: "white",
            }}
          >
            <DetailView initialEmail={selected.email} close={close} />
            <span style={{ cursor: "pointer", color: "black" }} onClick={close}>
              &times;
            </span>
          </div>
        </div>
      )}
    </div>
  );
}

export default App;
`,
"/DetailView.js":`import React from 'react';

function DetailView({ initialEmail, close }) {
  const [email, setEmail] = React.useState(initialEmail);

  return (
    <div>
      <input
        type="text"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
      />
      <button
        style={{
          color: "black",
        }}
        type="button"
        onClick={() => {
          alert(email);
          close();
        }}
      >
        Apply
      </button>
    </div>
  );
}

export default DetailView;
`}}
/>

css는 양해 부탁드립니다. 웹 개발에서 가장 약한 부분입니다. 😅

모달이 조건부로 DetailView를 렌더 하기 때문에(리렌더가 아닌 마운트 시키기 때문에) 위 예시가 이제 잘 동작합니다.

많은 분들이 이렇게 해왔다고 생각하며 유효한 해결 방법이라고 확신합니다. 그러나 이 방법은 모달 안에서 DetailView를 렌더링 할 때만 동작합니다.
만약에 DetailView가 어디에서나 렌더 가능하게 하려면 다른 해결 방법이 필요합니다.

## 2. State 끌어올리기

아마 이 구절을 들어보셨을 겁니다. React 공식 문서에서도 [이 주제에 대한 섹션](https://ko.reactjs.org/docs/lifting-state-up.html)이 있습니다.

이 예시에서는 DetailView에 있던 초안(draft) state를 App으로 끌어올려서 DetailView를 완전히 [제어 컴포넌트](https://ko.reactjs.org/docs/forms.html#controlled-components)로 만듭니다.
DetailView는 이제 지역 state가 필요하지 않기 때문에 더 이상 props를 state에 넣어서 문제가 생길 일이 없습니다.

<Sandpack
  files={{'/App.js':`import React from 'react';
import DetailView from './DetailView';

const persons = [
  {
    id: 1,
    name: "Dominik",
    email: "dominik@dorfmeister.cc",
  },
  {
    id: 2,
    name: "John",
    email: "john@doe.com",
  },
];

function App() {
  const [selected, setSelected] = React.useState(persons[0]);
  const [email, setEmail] = React.useState(selected.email);

  return (
    <div>
      {persons.map((person) => (
        <button
          type="button"
          key={person.id}
          onClick={() => {
            setSelected(person);
            setEmail(person.email);
          }}
        >
          {person.id === selected.id ? person.name.toUpperCase() : person.name}
        </button>
      ))}
      <DetailView email={email} setEmail={setEmail} />
    </div>
  );
}

export default App;
`,
"/DetailView.js":`import React from 'react';

function DetailView({ email, setEmail }) {
  return (
    <div>
      <input
        type="text"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
      />
      <button type="button" onClick={() => alert(email)}>
        Apply
      </button>
    </div>
  );
};

export default DetailView;
`}}
/>

이제 App은 모든 state를 제어할 수 있으며 DetailView는 이제 멍청한 컴포넌트(보여주기만 할 수 있는 컴포넌트)입니다.
이 접근 방법은 많은 상황에서 구현 가능하지만 결점이 없지는 않습니다.

이제 입력 요소에 타이핑을 할 때마다 App이 리렌더될 것입니다. 물론 지금처럼 작은 규모의 예시에서는 문제가 되지 않지만
더 큰 규모의 앱의 경우 문제가 될 수 있습니다. 
사람들은 종종 불필요한 리렌더를 줄이기 위해 전역 state 관리에 의존합니다.

누군가는 이메일 초안 state의 스코프가 너무 크다고 말할 수 있습니다. App에서는 오직 사용자가 Apply 버튼을 눌렀을 때의 새로운 이메일에만 관심이 있는데
왜 유저가 타이핑하는 순간순간의 state에 대해 신경을 쓸 필요가 있냐고 말하면서 말이죠.

세 번째 접근 방법은 앞서 설명드릴 두 가지 방법의 중간이라고 할 수 있습니다: 동일한 ux를 유지하고 이메일 초안 state의 스코프를 작게 유지하지만 원할 때 폼을
다시 마운트 할 수 있는 방법입니다.

## 3. key 속성을 이용한 완전히 제어되지 않는 컴포넌트

<Sandpack
  files={{'/App.js':`import React from 'react';
import DetailView from './DetailView';

const persons = [
  {
    id: 1,
    name: "Dominik",
    email: "dominik@dorfmeister.cc",
  },
  {
    id: 2,
    name: "John",
    email: "john@doe.com",
  },
];

function App() {
  const [selected, setSelected] = React.useState(persons[0]);

  return (
    <div>
      {persons.map((person) => (
        <button
          type="button"
          key={person.id}
          onClick={() => setSelected(person)}
        >
          {person.id === selected.id ? person.name.toUpperCase() : person.name}
        </button>
      ))}
      <DetailView key={selected.id} initialEmail={selected.email} />
    </div>
  );
}

export default App;
`,
"/DetailView.js":`import React from 'react';

function DetailView({ initialEmail }) {
  const [email, setEmail] = React.useState(initialEmail);

  return (
    <div>
      <input
        type="text"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
      />
      <button type="button" onClick={() => alert(email)}>
        Apply
      </button>
    </div>
  );
};

export default DetailView;
`}}
/>

이 예시는 다음 한 줄만 제외하면 첫 번째 예시와 완전히 같은 코드입니다.

```diff
- <DetailView initialEmail={selected.email} />
+ <DetailView key={selected.id} initialEmail={selected.email} />
```

### React keys

React 컴포넌트에서 key는 특별한 속성입니다. key들은 대부분 목록(리스트)에서 React의 안정성을 보장하기 위해 사용됩니다.
key가 있어야 react 재조정기(reconciler)가 어떤 엘리먼트인지 식별할 수 있고 리렌더 시 같은 엘리먼트를 효율적으로 재사용할 수 있기 때문입니다.

그러나 위와 같은 용도 이외에도 React에게 "이봐 key 속성이 동일하면 컴포넌트를 리렌더를 시켜주고, 바뀌면 마운트 시켜줘"라고 말하기 위해서 사용할 수 있습니다.

이것은 useEffect Hook의 의존성 배열과 비슷하다고 생각할 수 있습니다. 이전 렌더와 비교해서 변경되었다면 React는 컴포넌트를 다시 마운트 할 것입니다.

만약 더 자세히 알고 싶다면 [재조정에 대한 설명](https://ko.reactjs.org/docs/reconciliation.html)을 읽어보세요.

## 해결 방법이 아닌 것

아마 이 문제를 useEffect를 사용해 props와 state를 동기화 시키는 방법으로 해결하려고 했을 수도 있습니다. 

```jsx
function DetailView({ initialEmail }) {
    const [email, setEmail] = React.useState(initialEmail)

    React.useEffect(() => {
        setEmail(initialEmail)
    }, [initialEmail])

    return (...)
}
```

useEffect를 이런 방식으로 사용하는 것은 안티 패턴이라고 생각합니다. 만약 useEffect가 동기화를 위해 사용된다면
react state와 react 외부의 무언가(예. 로컬 스토리지)와 사용되어야 합니다.

그러나 여기에서는 react 내부에 있는 무언가(initialEmail)와 react state(email)를 동기화하기 위해 사용하고 있습니다.
게다가 동기화되는 조건이 원하는 바와 다르게 되어있습니다: 이메일이 변경됐을 때가 아니라 사람이 선택됐을 때마다 state를 초기화하기를 원하기 때문입니다.

첫 번째 방법은 조건부 렌더링을 이용해서,
두 번째는 사람을 선택하는 버튼이 클릭 됐을 때 명시적으로 state를 설정하면서,
세 번째는 안정적인 key(선택된 사람의 id)를 이용해 문제를 해결합니다.

이메일은 각각이 고유하기 때문에 최선의 예시가 아닐 수 있습니다. 만약 두 사람이 이름처럼 같은 데이터를 가지고 있다면 어떨까요?
두 사람의 이름이 같다면 다른 사람을 선택해도 데이터는 변경되지 않았기 때문에 useEffect가 동작하지 않고 의도한 동작이 이뤄지지 않을 것입니다.

유사한 예로 부모 컴포넌트에서 데이터가 변경되었지만 (예. [react-query](https://tanstack.com/query/v4/docs/guides/window-focus-refetching?from=reactQueryV3&original=https://react-query-v3.tanstack.com/guides/window-focus-refetching)의 refetch로 인해)
사용자가  이미 입력 요소를 변경했다면 어떨까요? 정말 이런 상황에서 사용자의 입력 요소를 받아온 데이터로 덮어쓰고 싶으신가요?

결론적으로 이러한 방식으로 사용한 useEffect는 골치 아프고 추적하기 어려운 많은 버그의 길로 이끕니다.

## 핵심 내용

개인적으로, 선호하는 해결 방법은 없으며 상황에 따라 세 가지 접근 방법을 모두 사용해왔습니다.

초안 state를 가지고 있는 DetailView는 몇 가지 이점이 있지만 언마운트에는 큰 비용이 따릅니다.
안정적인 key가 없을 수도 있고 언제 컴포넌트가 초기화되어야 하는지가 모호할 수도 있습니다.

state를 끌어올리는 것 또한 이점이 있지만 완전히 제어되는 컴포넌트들은 보통 추론하기 쉽지만 큰 규모의 앱에서 항상 수용 가능하지만은 않습니다.

어떤 해결 방법을 선택해서 적용해도 상관없지만 useEffect를 이용해 state와 props를 동기화시키는 방법은 사용하지 말아주세요.
이 접근 방법은 prop와 state를 동기화시키기 위해 사용했던 _componentWillReceiveProps_ 생명주기와 유사합니다.
[여기](https://ko.reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html)에 [Brian Vaughn](https://twitter.com/brian_d_vaughn)이 
2018년에 작성한 이 안티 패턴에 대한 좋은 글이 있습니다.  


state 변경 함수가 effect 내부에서 오직 동기화를 위해서만 사용된다면 그 state를 제거하세요!

useState를 남용하지 마세요


이 글은 [TkDodo](https://tkdodo.eu)의
[Don't over useState](https://tkdodo.eu/blog/dont-over-use-state) 포스트를 번역한 글입니다.

## useState의 함정

- <b>#1: useState를 남용하지 마세요</b>
- [#2: props를 useState에 전달하기](/blog/putting-props-to-use-state)
- [#3: useState에 대해 알아야 할 것들](/blog/things-to-know-about-use-state)
- [#4: 일회성 초기화를 위한 useState](/blog/use-state-for-one-time-initializations)
- [#5: useState vs useReducer](/blog/use-state-vs-use-reducer)

---

`useState`는 React에서 제공하는 가장 기본적인 Hook으로 여겨지며 `useEffect`와 함께 가장 많이 사용되는 Hook 중 하나입니다.

Hook 자체는 간단하지만 state를 관리한다는 것은 쉽지 않기에 지난 몇 달 동안 잘못된 방식으로 사용되는 경우를 많이 봤습니다.

이 포스트는 제가 _useState의 함정_ 이라고 부르는 시리즈의 첫 번째 파트이며 `useState` Hook을 사용하는 일반적인 시나리오를 보여주고 어떻게 이를 더 좋은 다른 방식으로 해결할 수 있는지 설명하려 합니다.

## state란 무엇일까요?

모든 것은 state가 무엇인지 이해하는 것으로 귀결된다고 생각합니다. 더 정확하게는 무엇이 state가 아닌지 이해하는 것으로요!
이를 이해하기 위해서는 [React 공식 문서](https://ko.reactjs.org/docs/thinking-in-react.html#step-3-identify-the-minimal-but-complete-representation-of-ui-state)에 적힌 내용만 제대로 이해하면 됩니다.

```
각 데이터에 대해 아래의 세 가지 질문을 통해 결정할 수 있습니다.
```

```
1. 부모로부터 props를 통해 전달됩니까? 그러면 확실히 state가 아닙니다.
2. 시간이 지나도 변하지 않나요? 그러면 확실히 state가 아닙니다.
3. 컴포넌트 안의 다른 state나 props를 가지고 계산 가능한가요? 그렇다면 state가 아닙니다.
```

props를 state에 할당하는 것(1)은 [두 번째 파트](https://tkdodo.eu/blog/putting-props-to-use-state)에서 다룰 내용이고 setter를 사용하지 않는다면(2) state가 아니라는 사실은 명백합니다.

그러면 이제 세 번째 질문인 파생된 state만 남습니다. state로부터 계산된 값은 그 자체로 state가 아니라는 것은 매우 명백한 것처럼 보이지만 최근에 많은 코드를 리뷰했을 때 주니어, 시니어 관계없이 가장 많이 봤던 패턴입니다.

## 예시

원격 엔드 포인트로부터 데이터를 불러오고(카테고리 리스트) 사용자가 카테고리를 필터링할 수 있도록 하는 코드입니다.

state 관리가 되는 방식은 대부분의 경우 다음과 같았습니다.

```jsx
import { fetchData } from "./api";
import { computeCategories } from "./utils";

const App = () => {
  const [data, setData] = React.useState(null);
  const [categories, setCategories] = React.useState([]);

  React.useEffect(() => {
    async function fetch() {
      const response = await fetchData();
      setData(response.data);
    }

    fetch();
  }, []);

  React.useEffect(() => {
    if (data) {
      setCategories(computeCategories(data));
    }
  }, [data]);

  return <>...</>;
};
```

처음 이 코드를 본다면 아마 이렇게 생각할 겁니다. 데이터를 불러오는 effect가 있고 카테고리를 데이터와 동기화하는 effect가 있구나. 이게 정확히 useEffect Hook이 나온 이유(동기화를 시키는 것)인데 이 접근 방식에 무엇이 나쁜 거지?

## 동기화 해제

이 코드는 실제로 잘 동작할 것이고 사실 잘 읽히지 않거나 추론하기 어려운 것도 아닙니다.
문제는 `setCategories` 함수가 미래의 개발자에 의해 잘못된 방식으로 사용될 수 있다는 것입니다.

만약 카테고리가 오로지 데이터에만 의존하도록 하는 것이 의도였다면 이것은 문제가 될 수 있습니다.

```jsx line=2,26
import { fetchData } from "./api";
import { computeCategories, getMoreCategories } from "./utils";

const App = () => {
  const [data, setData] = React.useState(null);
  const [categories, setCategories] = React.useState([]);

  React.useEffect(() => {
    async function fetch() {
      const response = await fetchData();
      setData(response.data);
    }

    fetch();
  }, []);

  React.useEffect(() => {
    if (data) {
      setCategories(computeCategories(data));
    }
  }, [data]);

  return (
    <>
      ...
      <Button onClick={() => setCategories(getMoreCategories())}>
        Get more
      </Button>
    </>
  );
};
```

그러면 이제 무엇이 카테고리인지 예측할 수 있는 방법이 없습니다.

- 페이지가 로드되면 카테고리는 X
- 사용자가 버튼을 클릭하면 카테고리는 Y
- [react-query](https://tanstack.com/query/v4/?from=reactQueryV3&original=https://react-query-v3.tanstack.com/)를 사용할 경우 탭을 포커스 하거나 네트워크를 재연결하면 자동 재조회되는 기능에 의해 데이터가 재조회되고 카테고리는 X

이렇게 되면 매우 추적하기 어려운 버그를 만들어내게 되는 것입니다.

## 불필요한 state는 사용하지 마세요

사실 위 내용은 `useState`보다는 `useEffect`에 대한 잘못된 이해로부터 시작되었습니다.
`useEffect`는 state를 react 외부의 무언가와 동기화시키기 위해서 사용되어야 하는데 이를 서로 다른 두 개의 react state와 동기화 시키는 데 이용하는 것은 거의 옳지 않습니다.

그래서 이렇게 말하고 싶습니다.

```
state 변경 함수가 effect 내부에서 오직 동기화를 위해서만 사용된다면 그 state를 제거하세요!
— TkDodo
```

이것은 @sophiebits가 최근 트위터에 올린 [트윗](https://twitter.com/sophiebits/status/1293710971274289152?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1293710971274289152%7Ctwgr%5Eda7b5c0823912e3fd69db2efec9212ecf1bca4b0%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Ftkdodo.eu%2Fblog%2Fdont-over-use-state)과도 어느정도 관련이 있습니다.

여기에 첨언을 하자면 계산의 비용이 크지 않다면 `useMemo`를 통한 메모이제이션도 하지 않을 것입니다. 섣불리 최적화를 하려고 하지 말고 일단 측정을 먼저 하세요. 최적화를 하기 전에 무언가가 느리다는 증거가 있어야 합니다. 이 토픽에 대한 더 자세한 내용은 [@ryanflorence의 아티클](https://reacttraining.com/blog/react-inline-functions-and-performance/)을 추천드립니다.

```diff
import { fetchData } from './api'
import { computeCategories } from './utils'

const App = () => {
   const [data, setData] = React.useState(null)
-  const [categories, setCategories] = React.useState([])
+  const categories = data ? computeCategories(data) : []

   React.useEffect(() => {
     async function fetch() {
       const response = await fetchData()
         setData(response.data)
       }

       fetch()
     }, [])

-  React.useEffect(() => {
-    if (data) {
-      setCategories(computeCategories(data))
-    }
-  }, [data])

   return <>...</>
}
```

effect의 사용을 절반으로 줄임으로써 복잡도를 낮췄고 이제 명백하게 카테고리는 데이터로부터 파생되었음을 확인할 수 있습니다.
만약 미래에 이 코드를 수정할 개발자가 카테고리를 다른 방식으로 계산하기를 원한다면 `computeCategories` 함수 내부를 수정하려고 할 것이며
그로 인해 우리는 항상 카테고리가 무언인지 어디로부터 왔는지 명백하게 알 수 있을 것입니다.

진실의 원천은 단 하나여야 합니다.


Nextjs에서 서로 다른 웹 렌더링 방식을 사용해서 데이터를 가져올 때 어떻게 되는지, 어떤 차이가 있는지 알아봅니다.

Nextjs data Fetching 이해하기 (CSR, SSR, SSG, ISR)


이 글은 [Theodorus Clarence](https://theodorusclarence.com)의
[Understanding Next.js Data Fetching (CSR, SSR, SSG, ISR)](https://theodorusclarence.com/blog/nextjs-fetch-method) 포스트를 번역한 글입니다.

## 개요

제가 Next.js를 배우기 시작했을 때 비슷해 보이는 많은 용어(CSR, SSR, SSG, ISR)들에 압도되었고 각각이 무엇을 의미하는지, 서로 어떤 차이가 있는지에 대해 이해하지 못했습니다.
Create React App을 사용했을 때만 해도 `useEffect`를 이용해서 데이터를 가져오는 방법밖에 없었기에 이는 너무 헷갈렸습니다.

Next.js에서는 많은 방법을 통해 데이터를 가져올 수 있습니다. Next.js가 서버 사이드 렌더링 프레임워크라고 알려지긴 했지만 데이터를 가져올 수 있는 방법이 4가지(CSR, SSR, SSG, ISR)나 있습니다.
본격적으로 시작하기 앞서 위에서 설명한 용어에 조금은 익숙해질 수 있도록 간략하게 설명해 드리겠습니다.

- CSR - Client-Side Rendering, `useEffect`를 이용해 데이터를 가져오는 평범한 방법이며, 각 페이지 요청마다 **클라이언트측**에서 데이터를 가져옵니다
  (페이지가 렌더링 된 후 데이터를 가져오는 함수가 실행됩니다).
- SSR - Server-Side Rendering, 각 페이지 요청마다 **서버측**에서 데이터를 가져오는 **특별한 함수**를 실행합니다
  (페이지가 로드되기 전에 특별한 함수가 먼저 실행되고 잠깐의 딜레이 후에 페이지가 렌더링됩니다).
- SSG - Static Site Generation, 어플리케이션이 빌드될 때 **한 번** 데이터를 가져오기 위해 특별한 함수를 실행합니다.
- ISR – Incremental Static Regeneration, 새로운 렌더링 방식으로 기본적으로 SSG이지만 **특정 시간과 특정 조건에**따라 해당 페이지만 리빌드하고 데이터를 가져오는 함수를 실행합니다.

제가 앞으로 더 구체적으로 설명을 할 거기 때문에 위 내용을 정확하게 이해하지 못했더라도 걱정하실 필요는 없습니다. 여기서는 우선 단어에 익숙해지는 것만으로도 충분합니다.

제가 이제 위에서 언급한 특별한 함수가 무엇인지 보여드릴테니 주의깊게 봐주세요.

앞으로 보여드릴 코드 예시는 axios를 이용해서 날짜-시간 데이터를 가져온 후 페이지에 렌더링 할 것입니다. 날짜-시간 데이터를 유심히 관찰하면 언제 API가 호출되었는지 알 수 있을 것입니다.

## Client-Side Rendering (CSR)

특별한 함수: `useEffect`

[데모 사이트](https://next-render.theodorusclarence.com/render/csr)

### 코드 예시

```tsx
export default function CSRPage() {
  const [dateTime, setDateTime] = React.useState<string>();

  React.useEffect(() => {
    axios
      .get("https://worldtimeapi.org/api/ip")
      .then((res) => {
        setDateTime(res.data.datetime);
      })
      .catch((error) => console.error(error));
  }, []);

  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}
```

### 데모

용어:

- PT -> Preview Time, API를 통해 가져온 날짜-시간 데이터, 화면 중간에서 확인할 수 있습니다.
- RT -> Real-Time, 매초마다 업데이트되는 현재 시간, 화면 오른쪽 아래 코너에서 확인할 수 있습니다.

비디오 설명:

1. RT가 15:46:03일 때 새로고침 되고 로딩 표시를 보여줍니다.
2. 1초 후에 PT 15:46:04가 보여집니다.

### 키포인트

1. **useEffect 함수**, 이 함수는 해당 페이지에서 CSR을 사용하고 있음을 나타냅니다.
2. **로딩 표시**, 페이지가 렌더링 된 후에 데이터를 가져오기 때문에 날짜-시간 데이터를 즉시 볼 수 없으며, 그동안 로딩 표시를 보여줍니다.
3. **각 페이지 요청마다 데이터 Fetching**, 그렇기 때문에 새로고침을 할 때마다 다른 시간이 나오는 것을 확인할 수 있습니다.

## Server Side Rendering (SSR)

특별한 함수: `getServerSideProps`

[데모 사이트](https://next-render.theodorusclarence.com/render/ssr)

### 코드 예시

```tsx
export default function SSRPage({ dateTime }: SSRPageProps) {
  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

export const getServerSideProps: GetServerSideProps = async () => {
  const res = await axios.get("https://worldtimeapi.org/api/ip");

  return {
    props: { dateTime: res.data.datetime },
  };
};
```

비디오 설명:

1. 16:32:38(RT)에 링크를 클릭하면 2초 정도 멈췄다가 16:02:40(PT)를 보여주면서 페이지가 로드됩니다.

### 키포인트

1. **getServerSideProps 함수**, 이 함수는 해당 페이지에서 SSR을 사용하고 있음을 나타냅니다.
2. **선딜레이 그리고 사라진 로딩 표시**, 페이지가 렌더링 되기 전에 데이터를 가져오기 때문에 API가 호출되는 동안 잠깐의 딜레이가 있다가 로딩 표시 없이 바로 데이터와 함게 페이지를 보여줍니다.
3. **각 페이지 요청마다 데이터 Fetching**, 그렇기 때문에 새로고침을 할 때마다 다른 시간이 나오는 것을 확인할 수 있습니다.

## CSR vs SSR

CSR 과 SSR의 차이점을 보여드리겠습니다. 딜레이와 로딩 표시에 주목해 주세요.

비디오 설명:

1. CSR을 클릭하면 딜레이 없이 Loading이라는 텍스트가 바로 보이며, 몇 초 뒤에 가져온 데이터가 표시됩니다.
2. SSR을 클릭하면 잠깐의 딜레이 후에 가져온 데이터와 함께 페이지가 로드됩니다.

### 키포인트

1. CSR은 페이지가 로드된 후에 API를 호출합니다.
2. SSR은 페이지가 로드되기 전에 API를 호출합니다.

## Static Site Generation (SSG)

특별한 함수: `getStaticProps`

[데모 사이트](https://next-render.theodorusclarence.com/render/ssg)

### 코드 예시

```tsx
export default function SSGPage({ dateTime }: SSGPageProps) {
  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

export const getStaticProps: GetStaticProps = async () => {
  const res = await axios.get("https://worldtimeapi.org/api/ip");

  return {
    props: { dateTime: res.data.datetime },
  };
};
```

### 데모

비디오 설명:

1. PT는 13:39:36인데 RT는 16:16:59로 3시간이나 지연되어 나타나고 있습니다.
2. 새로고침을 하거나 페이지를 재방문해도 아무런 변화가 일어나지 않고 있습니다.

### 키포인트

1. **getStaticProps 함수**, 이 함수는 해당 페이지에서 SSG을 사용하고 있음을 나타냅니다.
2. **빌드 시 Fetching 함수 실행**, API는 오직 앱 빌드 시에만 호출됩니다. 그렇기 때문에 위와 같이 3시간의 차이(빌드한 후 3시간 뒤에 페이지 확인)가 나오게 됩니다. ([개발 환경에서는 getStaticProps가 매 요청시마다 실행됩니다.](https://nextjs.org/docs/basic-features/data-fetching/get-static-props#runs-on-every-request-in-development))
3. **변하지 않는 데이터**, 그렇기 때문에 새로고침을 해도 같은 날짜-시간 데이터를 보게 됩니다.

## Incremental Static Regeneration (ISR)

특별한 함수: `getStaticProps` + `revalidate`

[데모 사이트](https://next-render.theodorusclarence.com/render/isr-20)

### 코드 예시

```tsx
export default function ISR20Page({ dateTime }: ISR20PageProps) {
  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

export const getStaticProps: GetStaticProps = async () => {
  const res = await axios.get("https://worldtimeapi.org/api/ip");

  return {
    props: { dateTime: res.data.datetime },
    revalidate: 20,
  };
};
```

### 데모

안내 사항: `revalidate`가 20초로 설정되었습니다.

비디오 설명:

1. 첫 PT가 16:40:12, 16:40:25(RT), 16:40:29(RT) 두 번의 새로고침을 했지만 PT에는 변함이 없었습니다.
2. 첫 PT 16:40:12로 부터 20초가 지난 뒤 16:40:36(RT)일 때 첫 번째 새로고침, 16:40:40(RT)일 때 두 번째 새로고침을 진행하였습니다.
   두 번째 새로고침을 하였을 때 PT가 16:40:37로 업데이트 되었습니다.

### 키포인트

조금은 헷갈릴 수 있지만 주목하면 좋을 것 같은 키포인트는 다음과 같습니다.

쿨다운 상태 - 어떤 기능을 이미 실행해서 특정 시간 동안 재실행을 할 수 없는 상태를 말합니다. 게임으로 치면 스킬 쿨타임(재사용 대기시간)이라고 생각할 수 있습니다. 스킬을 한 번 사용하면 몇 초 동안 해당 스킬은 다시 사용할 수 없습니다.
여기서는 페이지가 이미 리빌드되어서 새로고침을 해도 빌드되지 않는 상태를 말하고 있습니다.

1. **20초 동안 16:40:12(RT) ~ 16:40:32(RT)**, 새로고침을 해도 아무런 변화가 일어나지 않습니다. 16:40:12(PT)에 페이지 리빌드가 발생함에 따라 20초 동안 (`revalidate: 20`) 페이지가 쿨다운 상태에 들어갔기 때문입니다.
2. **20초 지난 후 16:40:32(RT)~**, 2번의 새로고침을 진행했습니다.
   1. 쿨 다운 상태 종료 후 첫 번째 새로고침 16:40:36(RT), 쿨다운 상태가 종료된 후 첫 방문은 페이지 리빌드를 야기합니다.
      이때는 전체 페이지를 빌드하지 않고 해당 페이지만 빌드합니다. 내부적으로 API 호출이 진행되지만 화면에 보이는 PT에는 변함이 없습니다.
   2. 쿨 다운 상태 종료 후 두 번째 새로고침 16:40:40(RT), 16:40:37(PT)으로 업데이트됩니다. 정확하게 페이지 리빌드 된 시간 - 첫 번째 새로고침 16:40:36(RT) 보다 1초 늦은 것으로 보아 리빌드하는데 1초정도 소요 됐다는 것을 알 수 있습니다.
      이 두 번째 새로고침은 첫 번째 새로고침에 의해 리빌드된 페이지를 보여줍니다.

### 페이지 재방문 vs 페이지 새로고침

용어:

1. 페이지 재방문 -> 다른 페이지 이동 후 다시 돌아오기
2. 페이지 새로고침 -> 새로고침 또는 페이지 첫(재) 접속

비디오 설명:

1. 페이지 재방문은 - 18:38:45(RT) 페이지 리빌드를 야기하지만 홈 이동 후 다시 페이지 방문 시에도 PT가 업데이트되지 않습니다.
2. 페이지 새로고침을 해야만 PT가 18:38:45로 업데이트됩니다.

노트:

1. **페이지 재방문 시에도 페이지 리빌드**, 쿨다운 상태가 아니라면 첫 번째 페이지 재방문은 페이지 리빌드를 야기합니다.
2. **리빌드된 화면을 보려면 페이지를 새로고침 필요** 두 번째로 페이지 재방문을 해도 리빌드된 페이지를 볼 수 없습니다.

여기서는 오직 한 명의 사람이 웹사이트를 사용할 것이라고 가정했지만 실제로는 모든 사람에 의해 페이지 새로고침이 됩니다.

### 그러면 20초마다 리빌드가 진행될까요?

**아닙니다.**

쿨다운 상태가 종료되고 아무도 페이지를 방문하지 않으면 해당 페이지는 리빌드되지 않습니다.

그러나 쿨다운 상태가 종료되고 방문자가 있으면 해당 페이지는 리빌드되고 그다음에 페이지 새로고침을 한 사람만이 새로운 페이지를 볼 수 있습니다.

## 결론

여기까지가 준비한 글의 전부입니다.

여기까지의 내용을 이해했다면 [How to choose between them](https://theodorusclarence.com/blog/nextjs-fetch-usecase)도 읽어보세요.
어떤 렌더링 방식을 사용할지 고려할 때 읽으면 좋은 글을 준비했습니다.


2개 이상의 컴포넌트를 조합해서 한 가지 기능을 수행하는 컴포넌트를 만드는 기법에 대해 소개합니다.

React Hooks: Compound Components


이 글은 [Kent C. Dodds](https://kentcdodds.com)의
[React Hooks: Compound Components](https://kentcdodds.com/blog/compound-components-with-react-hooks) 포스트를 번역한 글입니다.

몇 주 전에 저는 [DevTips with Kent](https://www.youtube.com/playlist?list=PLV5CVI1eNcJgCrPH_e6d57KRUTiDZgs0u)라는 라이브 방송을 진행하면서
클래스 컴포넌트로 작성된 Compound 컴포넌트 패턴을 리액트 훅을 사용한 함수 컴포넌트로 리팩토링하는 것을 보여드렸습니다.

<ResponsiveIFrame src="https://www.youtube.com/embed/415EfGPuhSo" />

Compound 컴포넌트에 익숙하지 않다면 [egghead.io](https://egghead.io/courses/react-class-component-patterns)
또는 [Frontend Masters](https://frontendmasters.com/courses/advanced-react-patterns)에 준비된 저의 고급 리액트 컴포넌트 패턴 강의를 확인해 보세요.

의미 있는 기능을 수행하기 위해 2개 이상의 컴포넌트를 조합해서 제공하는 API를 Compound 컴포넌트라고 합니다.
주로 한 컴포넌트는 부모로, 나머지 컴포넌트는 자식으로 이루어져 더 기가막히고 유연한 API를 제공합니다.

`<select>` 와 `<option>` 태그의 관계를 한 번 생각해보세요.

```html
<select>
  <option value="value1">key1</option>
  <option value="value2">key2</option>
  <option value="value3">key3</option>
</select>
```

여기서 두가지 태그 중 하나를 제외하고 사용하려고 한다면 제대로 동작하지 않을겁니다.
만약에 옵션 기능을 만들기위해 하나의 태그만 사용해야한다면 어떻게될까요?

```html
<select options="key1:value1;key2:value2;key3:value3"></select>
```

다른 방식으로도 표현할 수 있겠지만... 이러한 방식으로 API를 제공한다면 각각의 옵션에는 어떻게 disabled 속성을 부여할 수 있을까요?
구현은 할 수 있겠지만 미친짓아닐까요?

그래서 이러한 문제를 해결하기위해 Compound 컴포넌트가 등장하게 되고(물론 위 예시는 HTML태그입니다), 이는 컴포넌트의 관계를 표현할 수 있는 나이스한 API를 제공합니다.

Compound 컴포넌트가 가진 다른 중요한 개념은 "암묵적 state" 입니다.
`select`엘리먼트는 암묵적으로 어떠한 옵션이 선택되었는지에 대한 state를 저장하고 이를 자식(`option`엘리먼트)에게 공유합니다. 자식은 공유받은 state에 따라 스스로의 랜더링 여부를 결정하게 됩니다.
그러나 첫번째 HTML 코드를 보면 알 수 있듯이 state에 접근하는 코드는 하나도 작성되어있지 않습니다. 이렇기 때문에 이를 "암묵적 state"라고 합니다.

이제 여태까지 학습한 개념을 이해하기 위해 React로 작성된 Compound 컴포넌트를 살펴보겠습니다.
여기 Compound 컴포넌트 API를 제공하는 [Reach UI의 `Menu` 컴포넌트](https://reach.tech/menu-button) 예시가 있습니다.

```tsx
function App() {
  return (
    <Menu>
      <MenuButton>
        Actions <span aria-hidden>▾</span>
      </MenuButton>
      <MenuList>
        <MenuItem onSelect={() => alert("Download")}>Download</MenuItem>
        <MenuItem onSelect={() => alert("Copy")}>Create a Copy</MenuItem>
        <MenuItem onSelect={() => alert("Delete")}>Delete</MenuItem>
      </MenuList>
    </Menu>
  );
}
```

예시에서 `Menu` 컴포넌트는 "암묵적 state"를 자식에게 전달합니다.
그러면 `<MenuButton>`, `<MenuList>` 그리고 `<MenuItem>` 컴포넌트는 암묵적으로 공유받은 state를 필요에따라 가공을 한 후 사용하게 됩니다.
"암묵적 state" 공유의 결과물로 인상적인 API가 탄생하게됩니다.

어떻게 가능했을까요? [저의 강의](https://egghead.io/courses/react-class-component-patterns)를 봤다면 아시겠지만 2가지 방법이 있습니다.
`React.cloneElement`를 사용하는 방법과 React Context를 사용하는 방법입니다. (제 강의에 아직 훅을 사용하는 방법은 업데이트 되어있지 않습니다.)
여기에서는 Context를 사용해 간단한 Compound 컴포넌트를 만드는 것을 보여드리겠습니다.

저는 새로운 컨셉을 가르칠 때 먼저 간단한 예시를 사용하는 것을 선호합니다. 그래서 제가 가장 좋아하는 `<Toggle>` 컴포넌트를 예시로 보여드리겠습니다.

먼저 `<Toggle>` 컴포넌트가 어떻게 사용될지를 보여드리겠습니다.

```tsx
function App() {
  return (
    <Toggle onToggle={(on) => console.log(on)}>
      <Toggle.On>The button is on</Toggle.On>
      <Toggle.Off>The button is off</Toggle.Off>
      <Toggle.Button />
    </Toggle>
  );
}
```

아마 컴포넌트 이름에 .이 들어간 것을 눈치채셨을텐데요. 이는 자식 컴포넌트가 `<Toggle>` 컴포넌트의 static properties로 추가되었기 때문입니다.
주의하실 점은 이게 Compound 컴포넌트의 필수 조건이 아니라는 것입니다. (위의 `<Menu>` 컴포넌트는 이를 사용하지 않았습니다.)
저는 Compound 컴포넌트라는 것을 한 눈에 알 수 있도록 컴포넌트 사이의 관계를 명시적으로 표현하는 것을 좋아하기 때문에 이렇게 했습니다.

드디어 기다리고 기다다던 순간입니다. Context와 Hook을 이용해서 어떻게 Compound 컴포넌트를 구현했는지 보여드리겠습니다.

```tsx
import * as React from "react";
// this switch implements a checkbox input and is not relevant for this example
import { Switch } from "../switch";

const ToggleContext = React.createContext();

function useEffectAfterMount(cb, dependencies) {
  const justMounted = React.useRef(true);
  React.useEffect(() => {
    if (!justMounted.current) {
      return cb();
    }
    justMounted.current = false;
  }, dependencies);
}

function Toggle(props) {
  const [on, setOn] = React.useState(false);
  const toggle = React.useCallback(() => setOn((oldOn) => !oldOn), []);
  useEffectAfterMount(() => {
    props.onToggle(on);
  }, [on]);
  const value = React.useMemo(() => ({ on, toggle }), [on]);
  return (
    <ToggleContext.Provider value={value}>
      {props.children}
    </ToggleContext.Provider>
  );
}

function useToggleContext() {
  const context = React.useContext(ToggleContext);
  if (!context) {
    throw new Error(
      `Toggle compound components cannot be rendered outside the Toggle component`
    );
  }
  return context;
}

function On({ children }) {
  const { on } = useToggleContext();
  return on ? children : null;
}

function Off({ children }) {
  const { on } = useToggleContext();
  return on ? null : children;
}

function Button(props) {
  const { on, toggle } = useToggleContext();
  return <Switch on={on} onClick={toggle} {...props} />;
}

// for convenience, but totally not required...
Toggle.On = On;
Toggle.Off = Off;
Toggle.Button = Button;
```

실제 동작을 확인해보세요.

<Sandpack
  files={{
    '/App.js':`import Toggle from './toggle'

function App() {
  return (
    <Toggle onToggle={on => console.log(on)}>
      <Toggle.On>The button is on</Toggle.On>
      <Toggle.Off>The button is off</Toggle.Off>
      <Toggle.Button />
    </Toggle>
  )
}

export default App
`,
'/toggle.js':`import React from 'react'
// this switch implements a checkbox input and is not relevant for this example
import {Switch} from './switch'

const ToggleContext = React.createContext()

function useEffectAfterMount(cb, dependencies) {
  const justMounted = React.useRef(true)
  React.useEffect(() => {
    if (!justMounted.current) {
      return cb()
    }
    justMounted.current = false
  }, dependencies)
}

function Toggle(props) {
  const [on, setOn] = React.useState(false)
  const toggle = React.useCallback(() => setOn(oldOn => !oldOn), [])
  useEffectAfterMount(
    () => {
      props.onToggle(on)
    },
    [on],
  )
  const value = React.useMemo(() => ({on, toggle}), [on])
  return (
    <ToggleContext.Provider value={value}>
      {props.children}
    </ToggleContext.Provider>
  )
}

function useToggleContext() {
  const context = React.useContext(ToggleContext)
  if (!context) {
    throw new Error(
      'Toggle compound components cannot be rendered outside the Toggle component'
    );
  }

  return context
}

function On({children}) {
  const {on} = useToggleContext()
  return on ? children : null
}

function Off({children}) {
  const {on} = useToggleContext()
  return on ? null : children
}

function Button(props) {
  const {on, toggle} = useToggleContext()
  return <Switch on={on} onClick={toggle} {...props} />
}

// for convenience, but totally not required...
Toggle.On = On
Toggle.Off = Off
Toggle.Button = Button

export default Toggle
`,
'switch.js':`import './switch.styles.css'
import React from 'react'

// STOP! You should not have to change anything in this file to
// make it through the workshop. If tests are failing because of
// this switch not having properties set correctly, then the
// problem is probably in your implementation. Tip: Check
// your 'render' method or the 'getTogglerProps' method
// (if we've gotten to that part)

// this is here to fill in for the onChange handler
// we're not using onChange because it seems to behave
// differently in codesandbox and locally :shrug:
const noop = () => {}

class Switch extends React.Component {
  render() {
    const {
      on,
      className = '',
      'aria-label': ariaLabel,
      onClick,
      ...props
    } = this.props
    const btnClassName = [
      className,
      'toggle-btn',
      on ? 'toggle-btn-on' : 'toggle-btn-off',
    ]
      .filter(Boolean)
      .join(' ')
    return (
      <label aria-label={ariaLabel || 'Toggle'} style={{display: 'block'}}>
        <input
          className="toggle-input"
          type="checkbox"
          checked={on}
          onChange={noop}
          onClick={onClick}
          data-testid="toggle-input"
        />
        <span className={btnClassName} {...props} />
      </label>
    )
  }
}

export {Switch}
`,
'switch.styles.css':`/*
toggle styles copied and modified from
https://codepen.io/mallendeo/pen/eLIiG
by Mauricio Allende (https://mallendeo.com/)
 */
.toggle-btn {
  box-sizing: initial;
  display: inline-block;
  outline: 0;
  width: 8em;
  height: 4em;
  position: relative;
  cursor: pointer;
  user-select: none;
  background: #fbfbfb;
  border-radius: 4em;
  padding: 4px;
  transition: all 0.4s ease;
  border: 2px solid #e8eae9;
}
.toggle-input:focus + .toggle-btn::after,
.toggle-btn:active::after {
  box-sizing: initial;
  box-shadow: 0 0 0 2px rgba(0, 0, 0, 0.1), 0 4px 0 rgba(0, 0, 0, 0.08),
    inset 0px 0px 0px 3px #9c9c9c;
}
.toggle-btn::after {
  left: 0;
  position: relative;
  display: block;
  content: '';
  width: 50%;
  height: 100%;
  border-radius: 4em;
  background: #fbfbfb;
  transition: all 0.3s cubic-bezier(0.175, 0.885, 0.32, 1.275),
    padding 0.3s ease, margin 0.3s ease;
  box-shadow: 0 0 0 2px rgba(0, 0, 0, 0.1), 0 4px 0 rgba(0, 0, 0, 0.08);
}
.toggle-btn.toggle-btn-on::after {
  left: 50%;
}
.toggle-btn.toggle-btn-on {
  background: #86d993;
}
.toggle-btn.toggle-btn-on:active {
  box-shadow: none;
}
.toggle-btn.toggle-btn-on:active::after {
  margin-left: -1.6em;
}
.toggle-btn:active::after {
  padding-right: 1.6em;
}
.toggle-input {
  /* visually hidden but still accessible */
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  white-space: nowrap;
}
`
  }}
/>

React Context를 생성해 state와 state 변경 메커니즘을 저장하고
`<Toggle>` 컴포넌트는 Context 값을 자식에게 공유하고 있습니다.

저의 다음 React 컴포넌트 패턴 강의에서 이에 대해 다루고 설명할 예정이니 지켜봐주세요.

이 글이 유용한 컴포넌트를 만들 수 있도록 많은 도움을 주었으면 좋겠습니다. 행운을 빕니다!

관련 글인 [Inversion of Control](https://kentcdodds.com/blog/inversion-of-control)에 대해서도 읽어보세요!


Blog

프론트엔드 엔지니어링