
이 글은 [goidle 님의 리액트 톺아보기](https://goidle.github.io/react/in-depth-react-intro/), [보아즈 님의 리액트 까보기 시리즈](https://youtu.be/JadWu4Ygnyc?si=bb149nca5g9dV1Nw)
를 참고하여 공부하며 정리한 글입니다.
소중한 배움을 나눠주신 두분께 진심으로 감사드립니다.
이 장은 특히 goidle 님의 [리액트 톺아보기](https://goidle.github.io/react/in-depth-react-scheduler_1)를 주제로 합니다.
work 스케줄링을 위해 reconciler가 처리하는 사전 작업들과
scheduler가 어떻게 Work를 우선순위대로 스케줄링하고 적절한 타이밍에 실행하는지를 다룹니다.

## Work 스케줄링을 위한 사전작업

지난 장의 idle update 문단에서 리액트는 update를 적용하고자 scheduleWork 함수를 통해 Work를 스케줄링한다고 했다.
이 함수를 호출하는 reconciler는 `fiber.expirationTime` 속성을 통해 scheduler에게 Work의 스케줄을 알려준다.
`scheduleWork(fiber, expirationTime)` 함수는 아래의 일들을 한다.

1. 이벤트 발생을 알려주는 expirationTime 할당
2. 이벤트 발생 컴포넌트의 VDOM root를 가져옴
3. root에 스케줄링 정보를 기록

`react-reconciler/src/ReactFiberWorkLoop.js` 코드를 살펴보자.

![markUpdateTime 소스](/images/blog/23/markUpdateTime.png)

scheduleWork(`scheduleUpdateOnFiber`) 함수 내 `markUpdateTimeFromFiberToRoot` 함수를 보면
위 사전 작업들을 행하는 로직을 볼 수 있다.

### root

`ReactDOM.render()`로 컴포넌트를 삽입하는 부모 태그가 root이다. (`<div id='root'></>`)
한 root엔 한 VDOM이 있으며 root는 VDOM을 대표하는 변하지 않는 객체이다.
root는 한번에 Work 하나씩을 처리하는데,
그렇기에 여러 update가 발생해 여러 work를 스케줄링해야할 때, 작업의 우선순위 판단을 위해
스케줄링 정보(expirationTime)을 VDOM의 root에 기록해둔다.

### expirationTime

코드를 보면 expirationTime이 클수록 먼저 발생한 이벤트이고, 우선순위가 높다.
위 이미지 452번째 줄에서도 `fiber.expirationTime`과 인자 `expirationTime`을 비교해
만약 `expirationTime`이 더 크다면 그 값으로 할당(교체)한다.
먼저 발생한 이벤트를 먼저 처리할 수 있도록 값을 업데이트하는 것이다.
또 while 문 안에서 root 노드가 아닌 경우 `node.childExpirationTime` 속성을 사용하는데, 이 속성은
리액트 18의 concurrent 모드에서 유용히 사용된다.

또 `expirationTime`은 주어진 work가 없는 경우 `NoWork`, 동기로 처리되어야하는 work인 경우 `Sync`라는 상수로 표현된다.

## 버전16에서 대부분의 update를 처리하는 방법

![scheduleUpdateOnFiber 소스](/images/blog/23/scheduleUpdateOnFiber.png)

root까지 마킹이 끝난 후, reconciler는 expirationTime의 값으로 분기를 해 `ensureRootIsScheduled`를 실행한다.
동기적으로 호출해야하는 Work인 경우 VDOM을 처음 생성하는 시기가 아닐 때,
비동기적으로 호출해야하는 Work인 경우 바로 ensureRootIsScheduled를 실행한다.



work 스케줄링을 위해 reconciler가 처리하는 사전 작업들과 스케줄링

리액트 톺아보기 - Scheduler


[goidle 님의 리액트 톺아보기](https://goidle.github.io/react/in-depth-react-intro/), [보아즈 님의 리액트 까보기 시리즈](https://youtu.be/JadWu4Ygnyc?si=bb149nca5g9dV1Nw)를 참고하여 공부하며 정리한 글입니다.
이 글은 그중에서도 goidle 님의 [React 톺아보기 - 03. Hooks_1](https://goidle.github.io/react/in-depth-react-hooks_1)를 주제로
공부한 내용입니다.
리액트를 더 잘 이해할 수 있도록 자세히 설명해주신 두분께 리액트 개발자로서 진심으로! 감사드립니다.
이 글은 위 두 리소스에 맞춰 리액트 버전 16을 기준으로 하고 있으며, 18 코드와 비교해 볼 수 있는 부분도 중간중간 언급됩니다.

## VDOM

Virtual DOM은 일종의 programming concept다.
메모리 안에 저장되어있으며 ReactDOM 등의 라이브러리에 의해 실제 DOM과 동기화된다.

<img alt='Virtual dom' src='/images/blog/23/vdom.png' width='400px'/>

VDOM은 fiber 노드들로 구성된 **트리** 형태로 구현되어있고, **더블 버퍼링** 구조로
DOM에 마운트된 fiber를 의미하는 **current** 트리와 render phase에서 작업중인 fiber인 **workInProgress**를 가진다.
workInProgress에 있는 fiber는 commit phase를 지나서 current 트리에 속하게 된다.
각 노드는 하나의 child를 가지고, 부모는 return으로 참조한다.

위 이미지에서 보듯 workInProgress 트리의 노드는 current 트리에서 자기복제를 해서 만들어지고, 이 노드들은 서로를 alternate으로 참조한다.

### fiber

**fiber**란 VDOM의 노드 객체인데, react element의 내용이 DOM에 반영되기 위해서는 먼저 VDOM에 추가되어야한다.
이를 위해 확장한 객체가 바로 fiber다. fiber는 컴포넌트의 상태, 라이프사이클, 훅 등을 관리한다.

## 리액트 라이프사이클

### render phase

VDOM을 재조정(reconciliation)하는 단계로, element(Fiber)가 추가/수정/삭제되면 reconciler가 work를 스케줄러에 등록한다.
이때 말하는 work란 reconciler가 컴포넌트의 수정사항을 DOM에 적용하기 위해 수행하는 일을 말한다.
스케줄러는 등록된 work를 타이밍에 맞춰 수행한다.

이때 reconciler의 설계가 리액트 V16부터는 stack에서 fiber architecture로 바뀌었다.
Stack 아키텍처를 사용할 경우 스택의 LIFO 특성상 렌더링 순서를 조정할 수 없는데, Fiber 아키텍처를 도입하면서, 순서 조정이 가능해져
순서가 유연한 렌더링을 할 수 있게 되었다.

### commit phase

재조정한 VDOM을 동기적으로 DOM에 적용(동기화)하고 라이프사이클을 실행하는 단계다.
DOM에 적용을 일괄 처리한 후 리액트가 콜 스택을 비우고 브라우저가 paint한다.
브라우저가 paint를 하기 위해선 리액트 DOM 조작이 완전히 끝난 상태여야한다.

## 컴포넌트를 호출하면 일어나는 일

JSX로 만들어진 컴포넌트를 호출하면 babel이 `React.createElement()`를 해 리액트 엘리먼트를 반환한다.
이 React element는 type, key, props, ref 등을 가진다. 이후 변화가 있는 부분을 VDOM에 새로 적용(reconcile)하는 과정까지를 렌더링이라고 한다.
이후 renderer가 컴포넌트 정보를 DOM에 삽입하는데, 이것을 mount된다고 한다.
이후 브라우저가 DOM을 페인트한다.

## Hook을 호출하면 일어나는 일

Hook을 호출하면 Scheduler와도 상호작용을 한 후 reconciler와 상호작용을 한다.

리액트는 Task를 비동기적으로 실행한다. 스케줄러(Scheduler)가 그 Task들의 실행 타이밍을 아는 패키지이다.

Reconciler는 Fiber architecture에서 VDOM 재조정을 담당한다.

### React hook은 어디서 오는가

코드에서 hook 호출 -> `react/React` -> `react/ReactHooks` ->
`react/ReactCurrentDispatcher` -> `react/ReactSharedInternals` ->
`shared/ReactSharedInternals` -> reconciler

우리가 `useState`, `useEffect`를 사용할때 react 패키지에서 가져온다. 그 코어 패키지 안으로 들어가면
`ReactHooks.js`에서 hook들을 import하고 있다. 이 파일 안에선 `ReactCurrentDispatcher.current`를 반환하는 `resolveDispatcher()`를 갖고 있다.
그래서 또 `ReactCurrentDispatcher.current`를 따라가보면 훅 관련해 구현되어있는 내용이 없다.

즉, react 코어 패키지는 React element 관련 정보만 알고, hook에 대한 정보를 갖고 있지 않는다.
훅은 react element라는 클래스가 인스턴스화된 후, 그 객체의 상태를 관리하는 것이기에 hook과 관련된 세부 내용은 react 패키지에선 알지 못하는 것이 맞다.
훅은 `ReactCurrentDispatcher.current`을 통해 외부로부터 주입(DI) 받으며, 리액트 엘리먼트가 reconciler에 의해 fiber로 확장되어야 hook을 포함한다는 걸 알 수 있다.

훅은 shared 패키지에서 import 해오는데, shared 패키지는 모든 패키지가 공유하는 공유 패키지이다.
[reconciler의 ReactFiberHooks.js에서 renderWithHooks 함수](https://github.com/facebook/react/blob/b53ea6ca05d2ccb9950b40b33f74dfee0421d872/packages/react-reconciler/src/ReactFiberHooks.js#L375)를 통해 hook을 주입한다.
훅은 `react-reconciler` 패키지의 `ReactFiberHooks.js`이 주입하는데, 이 파일의 `renderWithHooks` 함수가 훅을 주입하며 컴포넌트를 호출하는 역할을 한다.

위 함수가 하는 일들은 아주 많지만 이런 것들이 있다. 아래의 VDOM 구조 이미지와 함께 보면 좋다.

<img alt='Virtual dom' src='/images/blog/23/vdom.png' width='400px'/>

1. `currentlyRenderingFiber = workInProgress;`: 현재 작업중인 fiber를 전역으로 잡아둠
2. `current`가 존재하면 `current.memoizedState`을 `nextCurrentHook`에 할당하고, 없으면 `null`을 할당한다.
위 VDOM 그림에서 Current 노드는 current 트리 안에 존재한다.
즉 이미 마운트되어 dom에 정보가 반영된 파이버(`current`)가 있으면 `nextCurrentHook`에 `current.memoizedState`을 할당한다.
기존에 들어있던 `current.memoizedState`가 hook일 거라고도 예상할 수 있다.
3. `nextCurrentHook`이 있으면 `ReactCurrentDispatcher.current`에 `HooksDispatcherOnMount`를 할당하고, 없으면 `HooksDispatcherOnUpdate`를 할당한다.
4. `nextCurrentHook`, `firstWorkInProgressHook`과 같은 전역변수를 현재 작업중인 컴포넌트에서만 사용할 수 있도록
작업이 끝날 경우 초기화시킨다
5. `let children = Component(props, refOrContext);`: 컴포넌트 호출.
이때 이 컴포넌트가 마운트되어야하면 전역변수 `firstWorkInProgressHook`에 훅 리스트가 생성되어 저장된다.
그 후 이 변수를 fiber의 `memoizedState`에 저장해 훅을 컴포넌트와 매핑시킨다.

5번을 통해 2번을 이해할 수 있다. `current.memoizedState`가 존재하면 그 컴포넌트는 첫 생성(mount)가 아니라
update되는 것이고, 훅 리스트 또한 이미 존재한다는 거다. 그렇게 3번에서도 mount/update 여부를 구분해
그에 맞는 훅 구현체(`HooksDispatcherOnMount`, `HooksDispatcherOnUpdate`, etc)를 사용한다.

## Hook 생성과 관련된 구현체들

<img alt='hook과 관련된 구현체들' src='/images/blog/23/hookStructure.png'/>

위 3번에서 등장한 `HooksDispatcherOnMount`는 useState 속성으로 `mountState` 함수를 가진다.
즉, useState를 호출한다는 것은 mountState를 호출하는 것이다.
useState를 호출하면 Hook 객체를 생성한다. 그 Hook 객체는 하나의 큐 객체를 가지고, 그 큐 객체는 하나의 update 객체를 가진다.

### mountState

<img alt='reactFiberHooks' src='/images/blog/23/mountStateV16.png'/>

mount 구현체인 `mountState`를 타고 들어가서, hook 객체를 생성하는 함수인 `mountWorkInProgressHook`으로 들어가본다.
(리액트 버전 18에서부턴 `mountStateImpl`이 hook을 반환하고, `mountWorkInProgressHook`으로 타고 들어갈 수 있다.)
`mountWorkInProgressHook`에서 생성하는 hook은 `memoizedState`, `queue`(큐 객체), `next`(다음 hook을 가리키는 포인터) 등의 속성을
가진다. (버전 16과 18의 속성이 살짝 다르다)
그 다음엔 작업중인 훅(`workInProgressHook`)이 없으면 위에서 생성한 hook을 `workInProgressHook`에 할당한다.
만약 현재 작업중인 훅이 있으면 그 훅을 `workInProgressHook`의 `next`로 넣어놓는다.
다시 `mountState`로 돌아와서 보면 `queue` 객체(`hook.queue`)를 생성하고,
`dispatchAction`에 `currentlyRenderingFiber`와 `queue`를 [바인딩](https://ko.javascript.info/bind)해 `dispatch` 함수를 만든다.
그리고 `[hook.memoizedState, dispatch]` 배열을 반환한다. 이 리턴값은 `useState`의 반환값이 된다.

## 훅은 어떻게 상태를 변경하고 컴포넌트를 리렌더링 시키는가

바로 위 문단에서 알아본 대로 `setState`는 사실상 `dispatch`, 즉 `dispatchAction` 함수이다.
이 함수는 상태를 변경하고 컴포넌트를 리렌더링하기 위해 크게 4가지 역할을 한다.
update 객체 생성 -> update를 큐에 저장 -> 불필요한 렌더링이 없도록 최적화 -> update를 적용하고자 Work를 scheduler에 예약한다.

위에서 VDOM을 설명할 때 current 트리와 workInProcess(이하 WIP) 트리가 있다고 했다.
`dispatchAction` 함수에서는 fiber가 `currentlyRenderingFiber`(현재 WIP에 있는 fiber)인지 확인하고 그 alternate까지 더블체크한다.
WIP의 fiber가 current에 반영될 때 기존 current와의 연결을 끊고 자기자신을 복제하여 새로운 workInProgress 노드를 만들기 때문이다.
체크해서 만약 현재 렌더링하고 있는 fiber가 없을 경우는 idle 상태로, render phase에 진입하지 않은 상태이다.
주어진 update가 없는 상태의 idle update의 과정을 먼저 알아본다.

### idle update

1. update 객체 생성: update 객체는 `expirationTime`, `action`(`setState` 인자로 넣을 값), `next`(다음 객체를 가리키는 포인터) 등을 가진다.
2. update를 queue에 저장: 그다음 update 객체를 list의 마지막에 넣는다.
그리고 2번째 업데이트부터는 첫번째 update 객체를 마지막 update의 next로 지정해 원형 링크드 리스트로 만든다.
3. 불필요 렌더링이 없도록 최적화: fiber와 alternate의 `expirationTime===NoWork`이면(스케줄러에 등록된 work가 없으면) `return;`을 통해 `dispatchAction`을 실행 중단한다.
4. update를 적용하고자 Work를 스케줄링: 3에서 실행 중지하지 않았을 경우 `scheduleWork` 함수를 통해 Work를 스케줄링한다.

4번에서 Work를 스케줄링하면 idle 상태를 벗어나 render phase에 진입한다.

### render phase update

render phase update란 이미 다른 스케줄링된 업데이트가 있는 상황에 추가로 업데이트가 발생한 것이다.
리액트 톺아보기의 예시를 들수 있다.

```js
    function FC() {
        const [a, setA] = useState(0)
        if (a === 1)
            setA(2)
        return <button onClick={() => setA(1)}></button>
    }
```

위 코드에서 `button`을 클릭하면 `setA(1)`이 실행된다.
`setState` 함수가 실행되었으므로 컴포넌트가 다시 렌더링되는데, `if(a===1)`문에 걸려 `setA(2)`에 닿는다.

render phase update 상태에서는 크게 3가지의 일을  처리한다.

1. 해야할 update를 임시 저장
2. update가 추가적으로 발생하지 않을때까지 컴포넌트를 호출해 update를 소비
3. 소비 중에 render phase update가 끊임없이 발생하면 에러 띄우기

render phase update의 경우 idle update와 달리,
Work가 이미 스케줄링 되었으므로 scheduleWork를 하거나 성능 최적화를 할 필요가 없다.
버전 16 리액트 코드와 함께 이 3가지를 살펴보자.

### update 임시 저장

<img alt='render phase update' src='/images/blog/23/renderPhaseUpdateV16.png'/>

render phase에 진입했으므로 전역변수 `didScheduleRenderPhaseUpdate`를 `true`로 설정한다.
update 객체를 만들고, update들을 담을 전역변수 Map(`renderPhaseUpdates`)을 만든다.
이 임시 저장소가 있어야 다음 컴포넌트 호출 때 update를 꺼내 소비할 수 있다.
update를 queue 객체를 키로 삼아 이 `renderPhaseUpdates`에 임시 저장해둔다.

### renderPhaseUpdates 소비

<img alt='renderWithHooks' src='/images/blog/23/renderWithHooksV16.png'/>

위 단계에서 저장한 update는 renderWithHooks 함수가 소비한다.

렌더링 횟수를 카운트하며 `nextCurrentHook`, `currentHook`, `workInProgressHook` 등
update를 소비하는데 필요한 값들을 초기화한다. 그러다 466번째 줄에서 Component를 한번 더 실행했을 때
컴포넌트를 리턴하기 전에 setState가 또 호출될 경우(update가 또 있을 경우) dispatchAction 안의
구문이 재실행되며 위 과정이 반복된다.

### 반복되는 리렌더링 방지

<img alt='too many rerenders' src='/images/blog/23/tooManyRerenders.png'/>

반복하는 횟수(`numberOfReRenders`)가 제한(`RE_RENDER_LIMIT`)을 초과하면 `Too many rerenders.` 메시지를 띄운다.

## 결론

위에서 알아본 것과 같이 리액트는 훅을 통해 컴포넌트 상태를 업데이트하고,
업데이트를 반영할 Work를 Scheduler에 전달하고, Scheduler는 스케줄링된 task를 적절한 시기에 실행한다.
다음 장에서는 reconciler가 Work를 스케줄링하기 위해 하는 사전작업과 스케줄러가 행하는 일들을 더 자세히 알아본다.


VDOM, Fiber, 리액트 라이프사이클, 훅을 통해 컴포넌트 상태를 업데이트하는 과정

리액트 톺아보기 - Hooks


## 요약

짧게 요약한 내용입니다.

<img width="700" alt='회원가입 as-is' src='/images/blog/2305/ex-asis.png' />

이랬던 코드를 

<img width="700" alt='회원가입 to-be' src='/images/blog/2305/ex-tobe.png' />

이렇게 바꾸었습니다.

## 도입 계기

```typescript
    const [status, setStatus] = useState<{
        idMsg: string,
        idOk: boolean,
        isIdChecked: boolean,
        passwordMsg: string,
        passwordOk: boolean,
        confirmPasswordMsg: string,
        confirmPasswordOk: boolean,
      }>({
        idMsg: '',
        idOk: false,
        isIdChecked: false,
        passwordMsg: '',
        passwordOk: false,
        confirmPasswordMsg: '',
        confirmPasswordOk: false,
    });
```

원래는 비밀번호, 비밀번호 재입력 필드가 validate한지 여부를 담는 불린값(`passwordOk`)과 
그 상태에 따른 에러 또는 성공 메시지(`passwordMsg`)을 상태로 가지고 있었습니다.
원래 상태를 관리할 때 상태(`password`) 외에 그 상태에 따라 결정되는 값(`passwordMsg`, `passwordOk`)은 상태에 담지 않는게 맞는데요.

```js
    if (!values.password || !PW_REGEX.test(values.password)) {
      _errors.passwordOk = false;
      _errors.passwordMsg = MSG.RULE_PW;
    }

    if (!values.confirmPassword || values.password !== values.confirmPassword) {
      _errors.confirmPasswordOk = false;
      _errors.confirmPasswordMsg = MSG.WRONG_PW;
    }
    setStatus(_errors);
```

기존 코드를 저렇게 작성했던 이유는 필드 간의 의존성 때문이었습니다.
비밀번호가 바뀔 때마다 정규 표현식에 맞는지 확인하고 바로바로 에러메시지를 표시해줘야 했고, 비밀번호 확인 필드가 그 비밀번호와 일치하는지 다시 밸리데이션해야했습니다. 
이런 값들을 JSX 내부에서 그때그때 밸리데이션하게 하기보단 state로 분리해서 `onChange` 내에서 검사 후 `setStatus`를 한번에 하도록 했었어요.  

이 방법이 베스트가 아니라는 걸 알면서도 구현했던 거지만
밸리데이션 내용이 너무 길어졌고, 코드가 복잡해져 어떤 코드를 수정할 때 다른 부분에도 영향이 갈까봐 찝찝해지기 시작했습니다.

그래서 <a href='https://react-hook-form.com' target='blank'> **react-hook-form**</a>을 적용해보았고, 아주 만족 중입니다!

## react-hook-form이란?

react-hook-form, 줄여서 rhf는 폼을 관리하고 활용할 수 있는 커스텀 훅들을 제공해줍니다. 사용가능한 훅들은 이런 것들이 있습니다.

- `useForm`: 폼을 간단하게 관리할 수 있는 커스텀 훅.
- `useController`: MUI처럼 외부에서 제어하는 컴포넌트들의 input을 제어하고 싶을 때 사용합니다. 컴포넌트별로 `useController`를 만들고, `useForm`과 따로 씁니다.
- `useFormContext`: `formContext`에 접근할 수 있고 `useForm`의 메서드를 사용할 수 있습니다. 폼 컨텍스트를 prop으로 넘기기 불편한, 깊게 nested 된 구조에 쓰면 좋습니다.
- `useFormState`: 각 폼 상태를 구독하고, 커스텀 훅 레벨에서 리렌더링을 분리하고 싶을때 사용합니다.
- `useFieldArray`: 필드들을 배열로 관리해 다이나믹하게 필드를 추가하거나 삭제, 순서를 바꾸고 싶을 때 사용합니다.

그 중에서도 저는 가장 기본적인 <a href='https://react-hook-form.com/docs/useform'>`useForm`</a>을 사용하였습니다. 예시코드를 보겠습니다.

## useForm 연동

```jsx
    import { SubmitHandler, useForm } from 'react-hook-form';
    
    const 회원가입 = () => {
        const {
            register,
            handleSubmit,
            formState: { errors },
        } = useForm<FormValues>({
            mode: 'onChange',       // validation을 언제 할지
            defaultValues: {        // input들의 기본값 설정
                userId: '',
                password: '',
                confirmPassword: '',
            },
        });
        return (
            // 생략
        )
    }
```

가장 먼저, `useForm`을 세팅했습니다. `mode` 속성으로 `onChange`마다 validation 하도록 변경해주었습니다.
기본 설정은 `onSubmit`으로, 폼이 submit될 때에만 밸리데이션 처리를 합니다. 
위 폼에선 회원가입에 필요한 `userId`, `password`, `confirmPassword` 필드를 관리합니다.
`useState`와 비슷한 구조로 `defaultValues`를 지정해줍니다.

```jsx
    // 비밀번호 인풋
     <PasswordInput
         // name='password'
         // value={values.password}
         // onChange={handleChange}
        {...register('password', {
            deps: ['confirmPassword'],   // 의존성 연결
            pattern: {                   // 정규표현식 패턴
                value: PW_REGEX,
                message: '비밀번호는 숫자와 영어, 특수문자를 포함해주세요.',
            },
        })}
    />
```

그 다음은 `register` 메서드를 사용해 인풋과 연동합니다. 이 코드의 비즈니스 로직 중 하나가
'*비밀번호 입력값이 변경될때마다 비밀번호 확인 필드도 다시 확인해 바로바로 에러메시지를 띄운다.*'입니다.

그렇기에 `register`의 두번째 파라미터인 `options` 객체의 `deps` 배열에 `confirmPassword`를 넣어줍니다.

또 비밀번호를 위한 정규표현식과 그 정규표현식에 맞지 않을 때 뜰 에러메시지도 지정해줍니다.
기존에 `prop`으로 넘겨주었던 `name`, `value`, `onChange`를 넘겨줄 필요가 없게 되었습니다!

```jsx
// 비밀번호 확인 실패 에러메시지
<p>{errors?.confirmPassword}</p>
```

그리고 그 에러메시지는 `formState.errors.인풋name` 으로 사용하면 됩니다.

## 커스텀 밸리데이션

```jsx
    // 비밀번호 확인 인풋
    <PasswordInput
        // name='confirmPassword'
        // value={values.confirmPassword}
        // onChange={handleChange}
        {...register('confirmPassword', {
            validate: {
                sameAsPw: (v, formValues) => {
                    return formValues.password === v || '비밀번호와 비밀번호 확인 입력값이 일치하지 않습니다';
                },
                // 다른 커스텀 밸리데이션 규칙도 추가 가능!
            },
        })}
    />
```

정규표현식 말고도 커스텀 validation 규칙을 추가할 수 있습니다. 
위 코드에선 `sameAsPw`라는 이름의 validation 규칙이 있고, 폼의 `password`와 값 `v`가 같은지 확인합니다. 같지 않을 경우'*비밀번호와 비밀번호 확인 입력값이 일치하지 않습니다*'라는 에러 메시지가 표시됩니다. 

참고로 저는 이 에러메시지들을 상수화해놓고 따로 구현하였으나, 예시 코드의 가독성을 위해 직접 넣어주었습니다.

## 온클릭 submit 연동

마지막으로 아이디 중복확인 버튼을 클릭했을 때, 서버로 아이디 중복확인 요청을 날려 그 응답을 받아와야 합니다.
하지만 이런 경우 아이디 중복확인 버튼에 `type=submit`을 넣을 수는 없습니다. 폼의 최종 submit은 회원가입하기 버튼을 눌렀을 때 이뤄져야 하기 때문입니다.

```jsx
    // 아이디 중복확인 버튼
    <CheckIdBtn 
        onClick={handleSubmit(checkId)} // handleSubmit으로 연동
    >
        중복확인
    </CheckIdBtn>
```

```typescript
    const checkId: SubmitHandler<FormValues> = (data) => {
        console.log('입력한 id:' + data.userId) 
    }
```

이럴 때엔 `useForm`의 `handleSubmit` 메서드에 중복확인을 하는 함수 `checkId`를 인자로 넘겨주면 됩니다.
이렇게 하면 `checkId`는 `MouseEvent`가 아니라 react-hook-form에서 정의한 타입 `SubmitHandler`을 리턴하며 해당 폼에서 관리하는 `data`를 받아 사용할 수 있습니다.

이런 식으로 react-hook-form을 사용해 리액트에서 폼과 인풋을 간단하게 구현하고 관리할 수 있습니다.
직접 리액트 `state`로 폼 인풋의 `value`를 계속 추적하고 `onChange` 핸들러를 전해줄 필요가 없게 되었습니다. 

이렇게 react-hook-form을 직접 써보니 너무 좋아서 회사 프로젝트에도 도입을 했는데요! 
그 프로젝트에선 MUI의 `TextField` 컴포넌트를 공통화해 사용하고 있었는데요. 그 컴포넌트와 react-hook-form의 `FormContextProvider`, `useController`를 함께 사용하였습니다.
인풋을 동적으로 추가해야하는 부분에서는 `useFieldArray`를 유용하게 사용했구요!

그럼 이만 다들 react-hook-form을 사용해 즐거운 코딩하시길 바라겠습니다!
😁


리액트로 폼 구현할 때 onChange, value, 상태의 props drilling을 줄여봅시다.

react-hook-form으로 리액트 폼 개선하기


Toss Slash 2022 를 들으며 적은 것들.  
실제로 나의 개발에 적용할 수 있는게 많아 여러번 반복해 들었다.  
더 나은 코드를 짜고 싶은 개발자라면 꼭 한번씩 보시길 추천해요.
이 글에 나오는 모든 코드/이미지의 권리는 Toss Slash 2022에 있습니다.

[한재엽 님 발표](https://www.youtube.com/watch?v=fR8tsJ2r7Eg)

## 서론 

제품은 변화를 겪으면서 **성장**한다. 변경이 필요하다는 건 고객의 니즈를 발견했다는 것. 우리는 사용자를 잘 모르기 때문에 변경을 예측하지 말고, 대응해야한다.

아래 코드의 문제점은 뭘까?

```jsx
<Item
	item={{
	data...
	}}
/>
```

문제점
1. Item 컴포넌트가 정확히 어떤 아이템을 의미하는지 알기 힘들다.
2. Item 컴포넌트 안에 item 속성이 또 있다.

이런 컴포넌트는 만들다보니 페이지가 커졌고, 적당히 덜어내며 만들어졌을 것이다. 이런 문제점을 발견한 이후 잘 변경할 수 있는 컴포넌트를 만들어야한다.

### 변경에 유연하게 대응할 수 있는 컴포넌트의 특징

1. Headless 기반의 추상화하기
: 변하는 것 vs. 상대적으로 변하지 않는 것
2. 한가지 역할만 하기
: 또는 한가지 역할만 하는 컴포넌트의 조합으로 구성하기
3. 도메인 분리하기
: 도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트 분리하기

## Headless 기반의 추상화하기

### 컴포넌트가 하는 일

1. 데이터 관리: 외부에서 주입받은 데이터 & 내부 데이터(상태)
2. UI: 데이터가 사용자에게 어떻게 보여질지를 정의 (e.g. `HTML`)
3. 사용자와 어떻게 상호작용할 지 정의 (e.g. `onClick`)

이 중 UI는 디자인에 의존한다. 그러면 컴포넌트의 데이터와 분리하는 게 좋다.

### Headless한 달력 컴포넌트

달력 컴포넌트의 경우 달력을 구성하는 데이터는 달라지지 않지만, 달력의 UI는 언제든 바뀔 수 있다.

headless한 컴포넌트를 만들기 위해선
1. 달력을 2x2 배열의 데이터로 추상화 (년, 월, 일), 배열의 요소는 `Date` 객체로 관리한다.
2. 현재 날짜값을 추상화한다.

```js
const {headers, body, view} = useCalendar()
```

**달력에 필요한 데이터 계산을 useCalendar hooks에 위임**한 셈이다. 
이렇게 UI를 관심사에서 제외하고 데이터에만 집중해 모듈화할 수 있다. (=headless)  
그 결과, 한가지 문제에만 집중하고 더 많은 곳에서 사용하고, 다른 변경으로부터 격리할 수 있다.

### 동작(상호작용) 추상화

```js
// useLongPress hook

interface Props extends ComponentProps<typeof Button>{
	onLongPress?: (event: LongPressEvent) => void;
}

export function PressButton(props: Props) {
	const longPressProps = useLongPress();
	// 생략...
}
```
컴포넌트에서는 hooks의 리턴값을 UI에 적용만 하고, 어떻게 보일지에만 집중할 수 있다. 다른 컴포넌트에서도 hook만 가져다 사용할 수 있다.

**변경에 유연해지려면 각 모듈이 한가지 역할만 하는게 중요하다.**

## Composition

작은 컴포넌트들을 조합해 구성해야하는 컴포넌트가 있다.   
예를 들어 `Selector`의 경우

![한가지 역할만 하기 발표자료](/images/blog/2210/one-role.png)

1. Selector가 열린 경우 `isOpen` -> `Dropdown` 컴포넌트로 관리
2. `isOpen` 상태를 바꾸기 위한 상호작용 -> `Dropdown.Trigger`
3. Menu -> `Dropdown.Menu`
4. Menu 내부 Item -> `Dropdowm.Item`

Toss Slash 2022 한재엽 님 발표를 들으며 정리한 것

Effective Component 지속 가능한 성장과 컴포넌트 (작성중)


*가독성을 위해 문제와 관련없는 부분은 최대한 생략한 코드입니다.*

## 문제 
아래 코드는 유저가 여러 소셜 로그인 방법 중 **카카오 로그인을 선택**한 경우 동작합니다.
순서는 이렇습니다. (코드 내 주석 참고)

```javascript
const [kakaoId, setKakaoId] = useState('');

const snsLogin = (id: string, isChecked: boolean) => {
    switch (SNS) {
		case '카카오':
		    kakaoLogin(() => {
				// (4)
		        updateSNS(kakaoId)
		        .then(resp => (...))
		        .catch(err => (...))
		        )
		      })
		   }
		    break;
		case '네이버':
		// 생략...
	}
};

async const kakaoLogin = (successCallback) => {
	// (1)
	await Kakao.Auth.login({
		success: async function (response: any) {
			// (2)
			await Kakao.API.request({
				success: function (profile: any) {
				    // (3)
				    setKakaoId(profile.id);  
				    successCallback();
				},
			});
		},
	  });
}

```

1. `Kakao.Auth.login`로 카카오 소셜 **로그인**을 한다.
2. 성공시 `Kakao.API.request`로 유저의 카카오 **프로필을 GET한다**.
3. response에서 `profile.id` 값을 컴포넌트 상태 `kakaoId`에 저장한다.
4. 저장한 `kakaoId`를 파라미터로, 서버에 POST 요청을 보낸다.

제가 겪은 문제는 `(3)`에서 setState을 하면 결과적으로 state가 바뀌긴 하지만, `(4)`에서는 아직 kakaoId가 변하지 않았다는 거였습니다.

즉, `(3)`에서 setState가 바로 업데이트를 실행하지 않았다는 거죠.  
왤까요?

## 원인

왜냐면 **setState는 이벤트핸들러 안에서 비동기적으로 호출**되기 때문입니다.
setState는 컴포넌트를 바로바로 리렌더링하지 않고, 변경 사항을 대기열에 넣어두고 한번에 일괄적으로 갱신합니다. 
이 결과 setState을 여러번 호출해도 동일한 키에 대해서는 가장 마지막 값으로만 상태가 갱신되기도 합니다.

### 왜 굳이?

비동기 객체라는 setState의 특징 때문에 아무 생각없이 `setState = 상태 바꿔주는 함수` 로만 알고 있으면 뒤통수를 맞기 쉽상입니다.  
왜 setState는 `XMLHttpRequest`, `콜백`, `setTimeOut`처럼 비동기 객체로 만들어졌을까요?

그 이유는 바로 *불필요한* 렌더링을 방지한 성능향상입니다.

하나의 이벤트핸들러에서 setState가 **여러번** 호출되면 이벤트가 끝날 때 **변경이 필요한 상태들을 일괄적으로 업데이트하고 렌더링**합니다.
그래서 setState를 호출하자마자 state에 접근하면 값이 안 바뀌어있는 겁니다.

## 즉각적으로 state 바꾸는 법

예시와 함께 **리액트에서 상태를 그때그때 바꾸는 방법** 몇가지를 알려드리겠습니다.

### 방법 1. useState: setState의 updater 인자에 함수 사용

```javascript
add() {
	setCount((prevState, prevProps) => {
		return {count: prevState +1}
	})
}
```

첫째로, prevState를 사용해 새로운 객체를 return하면 됩니다.

아래 예시에서 저는 ` fruits 배열의 원소가 객체의 key로 담긴 fruitState 객체`를 만들고 싶었습니다. 
그래서 이런 코드를 짰어요.

```javascript
const [fruitState, setFruitState] = useState({});
const fruits = ['orange', 'apple'];

fruits.map((val, idx) => {    
	setFruitState({ ...fruitState, [val]: true });

```

fruits 배열의 map() 메서드를 써서 setState를 하도록 했습니다. 
하지만 이 코드를 실행하니 예상한 결과물은 `{orange: true, apple: true}`이었는데, 실제 결과물은 `{apple: true}`였습니다.  

처음 `orange`가 `[val]`이었을 때 `fruitState`가 변하지 않은 상태에서 setFruitState를 한번 더 실행했기 때문에 마지막 setState만 빼고 이전의 setState 실행은 다 무시되어버린겁니다!!!

그래서 updater 인자에 prevState를 사용한 함수를 직접 넣어주었습니다.

```javascript
fruits.map((val, idx) => {    
    setFruitState(prevState => ({ ...prevState, [val]: true }));  
});
```

이렇게 고치면  `{orange: true, apple: true}`가 나옵니다.

### 방법 2. 클래스 컴포넌트: setState 콜백 사용

```javascript
const [count, setCount] = useState(0);

add() {
	this.setState({ count : this.state.count+1 },  // arg1
	() => {	console.log(this.state.count)})   // arg2
}

handleClick() {
  this.add();
}
```

두번째 방법은 useState 훅을 사용하지 않고, 클래스 컴포넌트의 setState를 사용하는 방법입니다.  
클래스 컴포넌트의 setState은 **두번째 인자(`arg2`)로 콜백함수**를 받아서 setState가 실행된 이후 콜백 함수를 실행합니다.

0인 count를 1씩 더해주는 예시입니다. 원래 값에 1씩 더해준다기보다 1을 더한 새로운 값을 count로 지정해주고 있습니다.
`arg1`인 setState가 실행되면, `arg2`가 새로운 count를 콘솔에 표시합니다.


이 두 방법 중 저는 첫번째 방법을 주로 씁니다.  
또 이외에도 useCallback 안에 setState을 넣어 처리할 수도 있습니다.

![setState Thumbnail](/images/blog/2209/setstate_thumbnail.png)

setState는 비동기적으로 동작한다

setState 제대로 사용하기 (feat. setState 값이 바로 안 바뀔 때)


[원문](https://frontendmastery.com/posts/the-new-wave-of-react-state-management)

위 아티클의 내용을 번역 및 요약하고, 중간중간 부가 설명을 추가했습니다.

## 상태관리란?

: 앱에서 text input, 확인, 라디오 버튼 등 UI 요소의 상태를 관리

### 리액트 전역 상태의 기준

리액트 쿼리의 철학을 따른다면 **서버 상태는 리액트 쿼리로 관리**하고 클라이언트 상태는 **해당 페이지/컴포넌트의 책임인지, 앱 전체의 책임인지에 따라 구분**한다.  
계정이나 설정 정보같이 **서버와 주고받는** 데이터, **화면과 무관한** 데이터나
**컴포넌트를 가로지르는** 데이터(form 요소들)은 전역에서 관리하는 게 오히려 낫다.

최근 상태 관리의 움직임을 보면 예전보다 더 전역상태를 많이 지원하고 권한다.
컴포넌트 데이터 교환이 props로 인해 복잡해진다면 전역 상태로 관리해도 무방하다.
다만 기존에 전역 상태를 쓰지 말라고 한 것은 전역 상태를 컴포넌트들이 수정하기 시작하면 어디서 수정된 건지 관리가 힘들기 때문이다.
그래서 최근 상태관리들은 대부분 수정 추적을 할 수 있도록 설계되어있다.
마지막으로 페이지나 UI를 가로지르는 state는 큰 전역으로 해야 추적과 디버깅이 편하다.

**결론**

1. 단순 UI 관련 state는 웬만해선 전역으로 넣지 않는다.
2. **여러 UI에서 공유하는 state는 전역으로** 넣는다
3. View단에 절대 state를 선언하지 않는다

### 모던 상태관리 라이브러리의 주 4가지 기능

1. State: 값이 바뀌면 해당 값을 쓰는 페이지나 컴포넌트가 자동 갱신
2. Mutation: 상태를 바꾸는 작업
3. Action: 어떤 작업의 결과가 나올때까지 상태가 바뀌지 않게 하고 결과값을 반영
4. Memoization: 특정 결과값이 상태가 바뀔때만 재계산되게 하는 기능

## 서론

하나의 리액트 앱 전역에서 공유되는 상태를 어떻게 하면 잘 관리할 수 있을까?
리액트가 제공하는 가이드라인은  따로 없으므로 우리의 앱에 맞도록 잘 선택해야한다.
또, 왠만하면 로컬(밑부분)에서 시작해 필요한 만큼만 확장하자.

**요즘의 전역 상태관리 라이브러리들은**

각각 다른 접근법으로 동작한다. 또 각자 다른 문제점과 tradeoff를 가진다.
그렇기에 우리 앱에 가장 적절한 라이브러리를 선택하는 게 중요하다.

**전역 상태 관리 라이브러리가 해결하려는 문제**

첫째, **저장된 상태를 컴포넌트 트리 어디에서든 읽어올 수 있는가?**
이 기능을 통해 상태를 메모리에 유지하고 `prop drilling`을 방지할 수 있다.
초기에 리액트 유저들은 이 문제를 해결하고자 Redux를 무분별하게 사용했다.

## 상태를 저장하는 두가지 방식

1. 리액트 런타임 내부에 저장: 상태를 전파하기 위해 리액트 API인 `useState`, `useRef`
또는 `useReducer`를 활용한다.
이 때 신경 써야할 부분은 리렌더링을 최적화하는 것이다.
2. 리액트 외부의 모듈 상태에 저장: 모듈 상태에는 싱글톤과 유사하게 상태를 저장할 수 있다.
또한 구독(컴포넌트가 저장된 '상태'를 지켜보는 것) 을 통해 상태가 변경될 때만 렌더링하도록 최적화할 수 있다.
다만 메모리 내부의 단일값(`싱글톤`)이므로 다른 subtree에서 사용되는 상태를 가질 수 없다.

둘째, **저장된 상태를 수정할 수 있는가?**

셋째, **렌더링을 최적화하는 메커니즘을 제공하는가?**
상태가 업데이트될 때 다시 렌더링할 시기를 감지하고 필요한 것만 다시 렌더링해야한다.
사용자는 셀렉터 함수로 저장된 상태를 구독함으로써 이 프로세스를 수동으로 최적화할 수 있다.
컴포넌트가 `selector`로 상태를 읽어 상태 변화가 일어났을 때만 리렌더링하는 방식이다.
이 경우 유저가 원하는 대로 구독을 제어할 수 있지만 수동인지라 오류가 발생하기 쉽다.
라이브러리가 자동으로 최적화하는 경우 사용이 편하다는 장점이 있다.
`Valtio`라는 라이브러리는 `Proxy`를 사용해 상태의 업데이트와 컴포넌트가 다시 렌더링돼야하는 시기를 관리한다.

넷째, **메모리 사용을 최적화하는 메커니즘을 제공하는가?**
리액트 라이프 사이클과 상태 저장을 엮으면 컴포넌트가 언마운트될 때 자동으로 가비지 컬렉션되도록 할 수 있다.
단일 전역 저장소 패턴의 Redux는 이를 개발자가 직접 관리해야한다.
가비지 컬렉션이 자동으로 되는 걸 막기 위해 데이터를 계속 참조하고 있을테니 말이다.
또 리액트 외부 모듈 상태에 저장하는 라이브러리를 쓸 때도, 상태가 컴포넌트들과 결합되지 않으므로
수동으로 관리해줘야한다.

## 상태관리 생태계의 역사

리액트가 처음 나왔을때, 리액트는 MVC 패턴에서 View 역할을 하고자 했다.
상태 관리 부재에 따른 불편함 때문에 페이스북의 `Flux` 패턴을 따와 상태 관리를 시작하게 되었다.
이 패턴은 단방향 데이터 흐름과 예측 가능한 업데이트에 적합했다.
그렇게 `Flux` 패턴을 사용한 대표적인 상태관리 라이브러리인 Redux가 사용되기 시작했다. 그러나…

**Redux의 약점**

1. Redux는 트리의 어느 곳에서나 상태에 액세스할 수 있다.
적은 엔드 포인트를 통해서만 데이터를 가져오고, 상호 작용이 거의 없는 간단한 앱에서 쓰기에는 부담스럽다.

2. 모든 상태를 한 단일 저장소에 저장하게 한다.
하향식 접근방식으로, 시간이 흐름에 따라 컴포넌트 트리의 맨 위에서 모든 상태를 빨아들이려 한다.
(상태는 트리의 높은 위치에 있고 아래의 컴포넌트는 셀렉터로 필요한 상태를 끌어내린다.)
독립적으로 분리된 복잡한 컴포넌트를 작업하기 어렵다.

그런데 사실, 대부분의 웹 앱이 서버에서 가져온 데이터(`서버 상태`)를 CRUD하는 것들이라
서버의 캐시 문제를 해결하는게 더 우선이다. 그래서…

**더 간단한 접근을 위한 Hooks, Context API의 등장**

Redux 같이 무거운 추상화보다 훅과 기본 컨텍스트를 활용하는 방법이 뜨기 시작했다.
(예시: `useState`, `useReducer`, `useContext` ) 간단한 앱의 경우 이것들을 사용하는게 더 나았다.
이 경우 리렌더링을 최적화하는게 중요했다.

## 원격 상태 관리 문제를 해결하기 위한 라이브러리들의 등장

CRUD 스타일인 대부분의 웹앱을 위해선 전용 원격 상태 관리 라이브러리와 결합된 로컬 상태가 유용하다.
(`React-query`, `SWR`, `Relay`, `개선된 Redux` 등) 예를 들면 react-query는 앱에서
서버 상태를 가져오기(`fetch`), 캐싱, 동기화 및 업데이트를 하게 도와주며 클라이언트 상태와
서버 상태를 명확히 구분하게 해준다.

**주의할 점**

`State`는 관련 컴포넌트들과 최대한 가까이 배치하는 게 좋다.
그래야 사이에 낀 컴포넌트들의 리렌더링과 부수효과를 줄일 수 있다.


리액트 전역 상태의 기준과 상태관리 라이브러리의 역사

'리액트 상태 관리의 새로운 흐름' 요약


## MDXRemote를 선택한 이유

블로그를 운영하면서 마크다운 문법에 익숙해졌고, 그동안 써둔 글이 다 마크다운이었기 때문이다. 
정적 블로그를 만들거라 포스트를 직접 코드에 넣어야하는데 하나하나 HTML로 바꿔선 넣을 수 없으니까
방안을 찾아보다가 발견한 MDX. Markdown을 JSX로 적을 수 있다니 정확히 내가 찾던 거였다!!! 😘

## next-mdx-remote 사용법

1. Next.js의 `getStaticProps` 함수 안에서 마크다운 파일을 `fs`로 읽어온다.
2. `gray-matter` 라이브러리의 `matter` 함수로 마크다운의 내용물을 frontmatter와 content로 구분해 추출&파싱한다.
3. `next-mdx-remote`의 `serialize` 함수로 markdown을 mdx로 변환한다.

```js
// getStaticProps
export const getStaticProps: GetStaticProps = async ({ params }) => {
  const { slug } = params as SlugInterface;

  // 1
  const markdownToMeta = fs.readFileSync(
    path.join(dir, slug + '.mdx'),
    'utf-8'
  );

  // 2
  const { content } = matter(markdownToMeta);

  const posts = await getAllPosts();
  const post = posts.find(p => p?.slug === slug);
  
  // 3 
  const mdxSource = await parseMarkdownToMdx(content);

  return { props: { post, mdxSource} };
};
```


리액트 앱에서 마크다운을 띄워줄 수 있는 라이브러리를 찾아야했다. 그래서 찾은 건 MDX Remote!

next-mdx-remote로 next.js에 마크다운 적용하기


요즘 핫한 리액트 프레임워크 `next.js`!!  
처음 `next.js`를 알게 된 건 next.js로 만든 멋진 웹사이트를 보고 나서부터였다. 
그이후로 점점 next.js의 이름을 많이 들었더니, 관심이 안 생길 수가 없었다 👀  
documentation을 좀 읽어보는데 쉽게 따라할 수 있는 튜토리얼이 있다고 해서 한번 따라해봤다.  
그리고 배운 것들을 정리해 보겠음 📂

## Next.js

![nextjs](https://nextjs.org/static/images/learn/foundations/next-app.png)

Next.js는 리액트 프레임워크 중 하나다. 위 사진 속에 보이듯 routing, data fetching, SSR 등을 할 수 있게 해준다.  
리액트를 쓸 때 라우팅을 하려면 `react-router-dom`을 따로 쓰고 설정을 해줘야했는데, next.js를 쓰면 얘가 알아서 해준다.  
여러모로 개발자가 리액트로 개발하는데 아주 큰 도움을 준다! (잠깐 써보고 벌써 체감했다.)

또 개발 단계의 앱을 프로덕션 단계로 만들고 싶을 때 Rust로 만들어진 Next.js 컴파일러가 프로덕션 최적화를 한다.
이 때 앱을 **컴파일**(브라우저가 이해하는 언어로 변환),
**번들**(웹 페이지에서 필요한 파일 수를 줄이기 위해 의존성 모듈이나 파일을 합치는 것),
**minify**(불필요한 코드, 여백을 줄여 파일 사이즈 줄임),
**코드 스플릿**(페이지에서 필요한 코드만 로딩해 앱의 초기 로드 시간을 줄이고자 앱 코드들을 작은 번들로 나누는 것)을 해
프로덕션 단계로 만든다. 

프로덕션 준비가 완료된 빌드 단계에서 Next.js 앱은 아래 네가지 파일을 갖게 된다. 
빌드가 완료되면 유저들이 사용할 수 있는 런타임 단계가 된다.

1. 정적 생성(SSG)된 HTML 파일들
2. 서버에서 렌더링할 JS 코드
3. 클라이언트에서 인터랙티브한 페이지를 만들 JS 코드
4. CSS 파일

## 렌더링

Next.js에서 가능한 렌더링 방법은 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 클라이언트 사이드 렌더링(CSR)이 있다. 
이 중 SSR과 SSG는 

### Pre-rendering

![pre-rendering](https://nextjs.org/static/images/learn/data-fetching/pre-rendering.png)

Next.js는 모든 페이지를 pre-render한다. 클라이언트 쪽의 JS가 아니라 
Next.js가 모든 HTML 페이지를 미리 만들어놓는다. 성능과 SEO 결과가 더 좋아진다.
만들어진 각각의 HTML은 그 페이지에서 필요한 최소한의 JS 코드를 포함한다. 
브라우저에서 페이지가 load되면 그때 그 JS 코드가 실행되어 페이지를 더 인터랙티브하게 한다. (이 과정을 **hydration**이라고 한다.)  
`<Link/>`같은 인터랙티브 컴포넌트는 js가 로드된 후 사용가능하다.

브라우저에서 자바스크립트를 꺼두고 Next.js로 만든 페이지에 들어가보면 더 확실히 알 수 있다.  
Next.js가 우리의 웹앱을 정적 HTML로 만들어놓았다는 것을!
만약 그냥 리액트 웹앱이면 자바스크립트 없이 동작하지 않았을 것이다.  

### Pre-rendering의 2가지 방법 (정적 생성 & 서버사이드 렌더링)

Next.js에선 이 두 방법 중 뭐를 쓸지 내가 직접 고를 수 있고, 섞어서도 개발할 수 있다.
Static generation과 server-side rendering의 차이는 **언제 페이지의 HTML을 생성하느냐**다.  
(개발 모드에서는 무조건 매 요청마다 pre-render된다.)

#### Static Generation: 빌드 시에 HTML 생성

![빌드 시 HTML 생성](https://nextjs.org/static/images/learn/data-fetching/static-generation.png)

- 왠만하면 이게 좋다. 왜냐면 한번 빌드된 페이지를 쓰면 되니까 서버가 매 요청마다 페이지를 렌더링하는 것보다 훨 속도가 빠르다.

#### Server-side Rendering: 매 요청 시에 HTML 생성

![매 요청시 HTML 생성](https://nextjs.org/static/images/learn/data-fetching/server-side-rendering.png)

- 만약 자주 업데이트되는 데이터가 있거나 매 요청마다 페이지의 내용이 달라져야한다면 서버 사이드 렌더링을 쓰는게 좋다.
- 정적 생성 방식보다는 느릴지 몰라도 항상 up-to-date!

## getStaticProps로 데이터가 들어간 Static Generation하기

Next.js에선 페이지 컴포넌트를 export할 때 getStaticProps라는 비동기 함수를 같이 export할 수 있다.

### getStaticProps

- 프로덕션 시 빌드 타임에 실행됨
- 파일 시스템, API, DB 등의 외부 데이터를 fetch해와 페이지의 props로 return할 수 있다.

#### 사용법

lib 디렉토리를 만들고 `gray-matter`를 사용해서 데이터를 내보낸다.  
참고로 그냥 `await.fetch()`를 해서 API로 가져온 데이터도 사용할 수 있다.  
`getStaticProps`는 **page에서 export된 파일만 가능하다.**

```js
// lib/posts.js

import fs, { readdirSync } from 'fs'
import path from 'path'
import matter from 'gray-matter'

const postsDirectory = path.join(process.cwd(), 'posts') // current directory/posts

export function getSortedPostsData() {
    const fileNames = fs/readdirSync(postsDirectory)
    const allPostsData = fileNames.map(fileName => {
        const id = fileName.replace(/\.md&/, '') // .md 지우고 id로 설정

        const fullPath = path.join(postsDirectory, fileName)
        const fileContents = fs.readFileSync(fullPath, 'utf8') // path에 있는 파일 내용 읽어오기

        const matterResult = matter(fileContents) // post의 metadata(frontmatter)
        
        return {
            id,
            ...matterResult.data
        }
    })
    
    // 날짜별로 sort
    return allPostsData.sort(({ data: a}, {data: b}) => {
        if (a < b) {
            return 1
        } else if (a > b) {
            return -1
        } else {
            return 0
        }
    })
}
```

```js
// pages/index.js  
import { getSortedPostsData } from '../lib/posts'

export async function getStaticProps() {
  const allPostsData = getSortedPostsData()
  return {
    props: {
      allPostsData  // prop으로 모든 블로그 포스트 넘겨주기
    }
  }
}

export default function Home({ allPostsData }) {
// ...
}
```

## 짱편한 라우팅

바로 위에서 언급한 next.js의 라우팅에 대해 이야기해보겠다. Next.js에서 한 페이지는 'pages' 폴더 안에 있는 한 파일 속 리액트 컴포넌트다.  
그래서 그 파일 이름으로 라우팅이 된다.

예를 들어 `pages/posts/first-post.js` 파일이 있으면 저절로 `posts/first-post` 로 경로가 설정된다.
다른 라우팅 라이브러리가 필요하지 않아서 진짜... 너무너무너무너무너무 편하다!!!

## Link

Next.js에서 다른 컴포넌트로 이동할땐 `<a/>` 태그 대신 `<Link/>` 태그를 사용한다.  
이때 중요한 점은 **클라이언트 사이드** navigation을 한다는 것이다.

### Client-side navigation

![client side nav](https://nextjs.org/static/images/learn/navigate-between-pages/client-side.gif)

위 이미지를 보면 페이지 전환이 일어나도 노란 CSS 설정이 계속 남아있다.
브라우저가 페이지 전체를 다시 로드하지 않고, client-side에서 navigation을 하기 때문에 일어나는 현상이다.
next.js의 `<Link/>`가 아니라 기본 html tag인 `<a/>`를 쓰면 브라우저가 전체 페이지를 새로고침하기 때문에 노란 CSS가 사라질 것이다.

그 외에도, client-side navigation은 자바스크립트를 이용해 페이지를 전환하기 때문에 브라우저의 기본 navigation보다 더 빠르다.

```javascript
export default function FirstPost() {
    return (
        <>
            <h1>First Post</h1>
            <h2>
                <Link href="/">
                   <a> Back to home</a>
                </Link>
            </h2>
        </>
    )
}
```

간단히 코드를 짜보면 이런식으로 `<Link>` 안에 `<a>`를 넣으면 된다. (링크 태그만 쓰는거 아님!)

## Code splitting and prefetching

**Next.js does code splitting automatically, so each page only loads what’s necessary for that page.**

Next.js는 자동으로 코드를 분리해줘서 페이지별로 로드된다.
처음에 홈페이지가 렌더될 때 다른 코드들은 같이 로드되지 않는다.
그렇기에 한 페이지에서 에러가 나도 다른 페이지들은 작동한다.

또 Link 태그가 브라우저의 viewport 안에 나타날 경우, Next.js가 자동으로 그 목적지 페이지의 코드를 미리 가져와둔다(prefetch).  
그래서 그 페이지로 좀 더 빠르게 이동할 수 있다.

## Static asset

- public 디렉토리 아래에 저장
- ```import Image from 'next/image'``` 컴포넌트를 쓰자.

### Nextjs의 ```<Image/>``` 를 쓰면 좋은 점

- 이미지 최적화해줌. WebP 지원되는 브라우저면 저절로 이미지 resizing을 도와준다.
- 심지어 외부 이미지 링크에서 가져오더라도 최적화가 가능하다. 그저 빛 ⭐️

### on-demand 최적화

- 빌드 시가 아니라 사용자 요청이 들어올때 이미지를 최적화한다. 이미지가 많아도 빌드 성능에 영향을 끼치지 않는다.
- lazy loaded! viewport에 들어올 때 이미지를 load한다.

## Third-Party JavaScript

```js
<Script
    src="https://connect.facebook.net/en_US/sdk.js"
    strategy="lazyOnload"
    onLoad={() =>
        console.log(`script loaded correctly, window.FB has been populated`)
    }
/>
``` 
앱에 부가적인 기능(analytics, ads, widgets)을 위한 스크립트들을 추가할 땐 `next/script`를 사용하자.
`strategy` 속성으로 언제 그 script가 로드될지를 지정할 수 있다.

## CSS Styling

Next.js에는 CSS-in-JS의 한 종류인 `styled-jsx`가 빌트인 내장되어있다.
리액트 컴포넌트 안에서 CSS를 쓸 수 있고, 또 CSS 스타일의 범위가 제한된다.**(=scoped)**  
styled-components나 emotion을 써본 사람에게는 더 쉬울 것이다.

### Layout Component

Next.js에서는 CSS 설정을 할 때도 도움을 준다. `className`을 설정하면 뒤에 랜덤한 문자열(해시)을 붙여 자동적으로 고유한 클래스 이름을 만들어준다.  
CSS 이름이 겹칠 걱정은 하지 않아도 된다!

`components/layout.js`에 `components/layout.module.css`를 적용하면 된다.  
[module.css](https://nextjs.org/docs/basic-features/built-in-css-support#adding-component-level-css)는 unique한 클래스 이름을 만들어 충돌을 방지해준다.

### API 등 서버와 소통하는 함수는 루트 디렉토리에

블로그 메인에서 recent posts (최근 글 목록)을 보여주고 싶었다. 
이럴 경우, 내 블로그는 SSR이라 **최근 글 목록을 가져오는 함수**를 컴포넌트에 넣으면 안 된다. 
그래서 루트 디렉토리에 Api 폴더를 만들고 거기다가 API 역할을 해줄 함수들을 작성해주는 게 좋다.

## Next.js 튜토리얼을 따라하며 느낀 점

튜토리얼이 친절하고 너~~~무 유용한 프레임워크라 그런가 배우면서 즐거웠다. 
리액트로 프로젝트를 할 때 추가로 불러와 쓰는 라이브러리가 많았다. 
그에 따라 설정할 것도 많아서 헷갈리곤 했는데 Next.js가 내게 도움을 주니 정말 마음에 든다. 
앞으로 많은 프로젝트를 Next.js로 하게 되지 않을까?


SSR 첫걸음, 더 쉬워진 라우팅, 클라이언트사이드 네비게이션...

Next.js 튜토리얼 직접 따라해보기


## 리덕스란

리덕스는 **상태를 관리해주는 리액트 전역 상태관리 라이브러리**다. 지금은 Redux toolkit으로 표준화됐다.  
상태를 연쇄적으로 변화시키며, 리액트하고 사용할땐 react-redux를 깔아서 함께 쓴다.  
컴포넌트의 상태 변경 로직을 다른 파일로 분리해 효율적으로 관리할 수 있다.

**상태관리가 왜 필요할까?**  
리액트의 경우 컴포넌트에서 원래는 useState 등을 사용했는데, 각 컴포넌트가 아니라 **앱 전체에서 상태를 관리해야하는 경우**가 많다.

그럴 때 **앱 전역에서 사용되는 상태를 관리**하는게 리덕스!

```js
// 만약 todolist를 만드는데 투두와 완료, 삭제리스트를 이렇게 관리하면 한 js에서 관리할 게 너무나 많음
const state = {
      todolist:[],
      donelist:[]
}
```

그럴 때 리덕스를 사용하면 **상태를 앱 최상위에서 관리하기 때문에 그 하위 컴포넌트 어디서든 상태값을 가져와** 사용할 수 있다.

## 작동 순서

![리덕스 작동순서](https://images.velog.io/images/hailey99/post/1c7d4cad-f918-429c-b039-d65573c0a4af/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%204.41.49.png)

리덕스는 사용자 Action이 발생했을때, Store로 가기까지 무조건 한 방향으로 움직인다.

1. dispatch 함수를 실행하면
2. action이 발생한다.
3. 이를 리듀서(reducer)가 전달하면
4. 최종적으로 상태(state)를 바꾼다.

### 구성 요소

- Action: 무조건 타입을 전달한다
```javascript
{type:'some text'}
```

- Reducer: param으로 상태와 액션을 받고 상태를 변화시키는 함수

```javascript
function reducer(state, action) {
    return changeState;
```

- Store: 앱 전체에서 사용되는 상태 저장소
- Dispatch: 액션을 발생시키는 함수 (`e.g. dispatch(action)`)

참고: Fastcampus '한 번에 끝내는 Node.js 웹 프로그래밍 초격차 패키지 Online' 강의

## 장단점

**장점**

1. 데이터 관리하는 부분이 분리되어있어 테스트가 쉬움
2. 모든 구성요소는 Store의 모든 양식 상태에 액세스 가능

**단점**

1. Action type, selector, action 생성자, reducer 등 중복 코드가 많음


리덕스란 무엇인가, 리액트의 작동 순서


## useEffect

- useEffect: `componentDidMount`, `componentDidUpdate` 이후에 발생하는 코드를 넣음
- 순수 함수는 참조 투명성을 가지는데 (부작용이 없음) useEffect는 이름에서 드러나듯 [함수 컴포넌트가 부작용을 이용하는 도구](https://gyuwon.github.io/blog/2020/07/24/react-has-no-functional-components.html)다.
- 계속 마운트되는 부분의 라이프사이클을 관리
- 클래스 컴포넌트에서는 `componentDidMount()` 등의 함수를 썼었는데 넘 번거로워서 생김

## 직접 써보기

`setInterval`로 1초마다 초를 업데이트하는 함수가 있다.

```javascript
function App() {
  const [second, setSecond] = useState(0);

  setInterval(() => {
    setSecond(second +1);
  },1000);

  return (
    <div>
      <p>{second}초</p>
    </div>
  )
}
```

이 함수의 문제점은 1초마다 함수 전체가 새로 **마운트** 된다는 거다.  
그러면 `setInterval` 함수를 또 시작한다.  

![console log](/images/blog/192021/eff.png)

setInterval 안에서 `console.log` 함수를 찍으면 이렇게 이상한 결과가 나온다.  
`setInterval()` 함수가 대략 1초마다 계속 실행되며 점점 쌓인다.  
이런 경우에 useEffect()를 사용하면 된다!

```javascript
function App() {
  const [second, setSecond] = useState(0);

  useEffect(()=> {
    let interval = setInterval(()=> {
      console.log(second);
      setSecond(second+1);
    }, 1000);

    return () => {
      clearInterval(interval);
    }
  }, [second]);

  return (
    <div className="App">
      <p>{second}초</p>
    </div>
  )
}
```

이렇게 하면 마운트, 언마운트가 반복되며 `second`가 1초마다 1씩 늘어난다.

```javascript
useEffect(() => {
  console.log("mount")
  return () => {
    console.log("unmount')       // 언마운트(cleanup) 안 하면 요청이 반복적으로 발생
  }
}, [second]);                   // mount에 의존적인 변수(dependencies) 삽입
```

추가로, [useEffect 잘못 쓰고 계신겁니다.](https://velog.io/@jay/you-might-need-useEffect-diet)라는 글에 따르면
`리액트18의 strict mode에서는 렌더링을 두번씩 하는데 그럴 경우 불필요한 상태 변경/리렌더링이 있을 수 있으니 useEffect에 클린업함수를 꼭 넣어줘라,
연산이 비싸면 useMemo 써라, react-query 등 캐시된 데이터를 써라`고 한다.



컴포넌트 마운트와 관련해 발생하는 사이드이펙트를 이용하는 리액트 훅!

REACT

'REACT'에 관한 글들을 모아봤어요.