사전 과제의 필수 조건 중 하나인 Redux Toolkit..!
적용 전 학습을 위한 시간을 가졌습니다.
recoil, jotai 등 상태 관리를 위한 라이브러리를 사용해왔지만..
Redux를 직접 사용해본 적이 없었고, 다량의 보일러 플레이트 및 복잡한 초기 환경설정 등과 같은 무성한 소문만 알고 있었습니다 ㅎㅎ
상태 관리 라이브러리의 필요성
React는 단방향 데이터 흐름으로..
특정 시점의 상태를 가지고 UI를 렌더링하고, 이벤트가 발생했을 때 상태를 업데이트하며, 해당 상태를 반영한 UI를 리렌더링하는 사이클을 가집니다.
규모가 커지면 커질수록 동일한 상태를 공유하고 사용해야 하는 여러 구성 요소가 생기게 되겠죠?
state lifting, props drilling과 같은 문제가 이때 발생하며 단순성이 무너지는 문제가 발생합니다. 문제 발생 시 출처를 찾는 것 또한 어렵습니다.
공유 상태를 추출해 구성 요소 트리 외부의 중앙에 배치하고 트리 위치에 관계 없이 상태에 액세스할 수 있도록 하면 될 것 같죠?
상태 관리 라이브러리는 바로 이런 역할을 하는 겁니다!ㅎㅎ
Redux 기본 용어
차이를 비교하기 전에 기본 용어를 알아보도록 하겠습니다.
store
상태를 관리하는 저장소로, 프로젝트 하나는 스토어 하나만 가질 수 있음
action
스토어 내 상태를 변경하기 위해 필요한 객체로, 반드시 type을 가져야 하며 액션 생성 함수에 의해 만들어짐
reducer
현재 상태와 액션 객체를 받아 새로운 상태를 리턴하는 함수
dispatch
스토어 내장 함수, 리듀서가 호출될 때 액션 객체를 넘겨서 상태를 업데이트하는 역할
subscribe
스토어 내장 함수, 리듀서가 호출될 때 구독된 함수 및 객체를 호출
Redux vs Redux Toolkit
Redux
- 많은 양의 보일러 플레이트 (액션 타입, 액션 생성 함수, 리듀서를 각각 생성해야 함)
- 복잡한 초기 환경설정
- 불변성을 지키기 위한 추가 작업
Redux Toolkit
- 리듀서, 액션타입, 액션 생성함수, 초기 상태를 하나의 함수로 편하게 선언
- Redux 앱을 만들기 위해 필수적인 패키지와 함수를 포함
Redux Toolkit 이해하기
이렇게 생성된 store를 사용하기 위해 루트 컴포넌트를 Provider로 감싸면 사용할 준비 끝입니다.
ReactDOM.createRoot(document.getElementById("root")!).render(
<React.StrictMode>
<Provider store={store}>
<App />
</Provider>
</React.StrictMode>,
)
컴포넌트 내부에서 useSelector()를 이용해 상태를 조회하거나 useDispatch() 를 이용해 생성된 액션을 발생시켜 액션 생성 함수를 가져올 수 있습니다.
소감
recoil이나 jotai보다는 러닝커브가 있는 편이지만, redux-devtools와 같은 디버깅 툴이 존재해서 실제로 todoList를 만들어보면서 액션이 발생할 때마다 남는 로그를 보며 추후에 대규모 프로젝트에서 디버깅에 유리할 것 같다는 생각이 들었습니다. (아니 확신일지도?)
참고 링크
https://ko.redux.js.org
https://blog.hwahae.co.kr/all/tech/6946
