서비스의 규모가 커질수록 관리해야할 state가 많아지고 이를 체계적으로 관리하기 위해 상태 관리라는 라이브러리를 사용한다.
상태 관리 라이브러리란 말 그대로 state를 관리를 목적으로 하는 라이브러리의 대표적인 예로 Redux가 있다.
리덕스는 모든 state를 store라는 중앙 상태 저장소를 사용하여 앱의 모든 상태를 저장한다.
이 Store는 Reducer 함수를 통해 수정될 수 있다.
또한 이러한 Reducer 함수는 이전 상태와 액션 객체를 dispatch로 입력으로 받아 새로운 상태를 반환한다.
dispatch(action) => action에 해당하는 리듀서 함수 실행 => store에 저장된 state 값 변경
컴포넌트에서는 상태값 자체를 변경시키는 것이 아닌 항상 특정 액션만을 dispatch 해준다. 이는 컴포넌트가 순수 함수 원칙을 유지할 수 있도록 도와준다.
상태 관리 라이브러리의 장점?
props drilling 방지
props drilling이라는 컴포넌트가 특정값을 사용하기 위해 여러 상위 컴포넌트에서 props를 정의하고 전달받는 과정을 말한다.
이는 여러 컴포넌트에서 사용하지도 않는 props를 정의해야하고 필요없는 코드를 증가시킬 수 있다.
때문에 이러한 필요없는 코드를 줄이고 해당 데이터를 사용하는 컴포넌트에서만 끌어와서 쓸 수 있도록 할 수 있는 역할이 상태 관리 라이브러리이다.
상태 관리 라이브러리에서는 store라는 state 저장소에서 사용하고 싶은 state만 끌어와 사용할 수 있기 때문에 props drilling을 피할 수 있다.
컴포넌트를 순수 함수로 유지
컴포넌트를 순수 함수로 유지할 수 있습니다.
리액트의 컴포넌트는 순수 함수로 유지되도록 하기를 권장합니다.
하지만 다음과 같은 상황에서 컴포넌트는 순수 함수를 유지할 수가 없습니다.
외부 데이터를 가져와 사용하는 컴포넌트
브라우저 이벤트에 의존하는 컴포넌트
때문에 위와 같은 컴포넌트들은 상태 관리 라이브러리를 사용하여 순수 함수 컴포넌트로 만들어줄 수 있습니다.
<초기세팅>
폴더구조
index.js
reducer.js
store.js
하지만 redux 공식입장에 따르면 @reduxjs/toolkit을 설치하여
createStore를 계속 사용해도 상관없이만 createStore 대신 configureStore를 사용하는 것을 권장한다.
회사마다 다르지만 if문을 쓰는 곳이 있고 switch문을 쓰는 곳이 있다.
store은 reducer의 return값을 받으면 그 return 값을 적용해서 바뀐다.
그래서 reducer는 항상 return을 해야한다.
useSelector 함수를 통하여 store 에서 값을 들고 올 수 있다!!
useSelector는 함수를 매개변수로 받는다.
payload 는 필요한 정보를 보내줄 수 있다(매개변수 같은 느낌)
action.payload.num 을 이용하여 5씩 늘어나게 할 수 있다.
<정리>
Redux는 앱의 상태를 중앙에서 관리하기 때문에 디버깅이 쉽다.
Parent 이던지, Child 이던지 상관없이 어디서든 state가 필요하면 가져다가 사용할 수 있다.
Redux DevTools와 같은 도구를 사용하면 앱의 상태 변화를 쉽게 추적할 수 있다.
따라서 상태 관리 라이브러리는 React와 함께 사용하면 상태 관리를 더욱 예측 가능하고 일관된 방식으로 관리할 수 있으며, 코드의 가독성을 높이고 디버깅을 쉽게 할 수 있도록 도와준다.
하지만 상태 관리 라이브러리를 사용한다고 해서 모든 상태를 꼭 store에 저장할 필요는 없다.
특정 컴포넌트 자체에서만 사용하는 state가 있다면 굳이 해당 state를 store로 끌어올 필요는 없다.
각 state의 역할을 고려하고 컴포넌트 자체에서 사용할지 전역 state 사용할지를 결정하면 올바른 state 관리를 할 수 있을 것이다.
