Redux 상태 갱신 흐름

Redux 상태 갱신 흐름

Redux를 전역 상태 저장소라는 말로만 이해하면 어디서 버그가 나는지 찾기 어렵다. dispatch가 action을 보내고, reducer가 이전 상태와 action으로 다음 상태를 만들며, selector 구독이 필요한 컴포넌트만 다시 읽는 흐름을 기준으로 봐야 한다.

01

Action 만들기

무슨 일이 일어났는지 type과 payload로 표현한다.

UI 이벤트 이름보다 도메인 사건 이름이 낫다
02

Dispatch 전달

컴포넌트나 thunk가 action을 store에 보내 상태 변경을 요청한다.

dispatch 자체가 상태를 직접 바꾸지는 않는다
03

Reducer 계산

이전 상태와 action을 받아 새 상태를 순수 함수로 만든다.

mutation처럼 보여도 RTK는 Immer로 안전하게 처리한다
04

Selector 읽기

컴포넌트는 필요한 조각만 selector로 구독하고 equality 기준을 확인한다.

매번 새 객체를 반환하면 다시 렌더링된다
05

DevTools 추적

action log, state diff, time travel로 잘못된 상태 전이를 찾는다.

비동기 실패도 action 흐름으로 남긴다
useState
컴포넌트 내부 상태 한 화면 안에서만 쓰이고 전역 추적이 필요 없으면 지역 상태가 낫다.
Redux가 기본값은 아니다
Context
낮은 빈도 공유값 theme, locale처럼 변경이 드문 값은 context로 충분할 수 있다.
자주 바뀌는 값은 렌더 범위를 본다
RTK Slice
전역 도메인 상태 여러 화면이 같은 상태 전이를 공유하고 디버깅 이력이 필요할 때 적합하다.
boilerplate를 줄인다
Server Cache
원격 데이터 서버에서 온 목록과 상세는 Query 계열 캐시가 더 맞을 수 있다.
클라이언트 상태와 서버 상태를 나눈다

디버깅 확인

Action 이름 로그만 보고 어떤 사용자의 어떤 사건인지 알 수 있는지 확인한다.
Reducer 순수성 랜덤값, 날짜, API 호출이 reducer 안에 들어가지 않았는지 본다.
Selector 안정성 selector가 불필요하게 새 객체를 만들어 rerender를 늘리지 않는지 확인한다.