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

프론트엔드 엔지니어링