
## 요약

짧게 요약한 내용입니다.

<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'에 관한 글들을 모아봤어요.