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

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

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


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

상태관리

'상태관리'에 관한 글들을 모아봤어요.

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

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