Posts [React] 상태관리 라이브러리에 대하여
Post
Cancel

[React] 상태관리 라이브러리에 대하여

[react] 상태관리 라이브러리에 대하여


리액트로 프로젝트를 진행하다 보면 마주하게 되는 것 중 하나가 상태관리 라이브러리일 것입니다.

많이 알고 계시는 Redux부터 시작해서 MobX, xstate, recoil, zustand 등 종류가 다양합니다.

단순하게 Todo 앱에 아이템 추가/삭제 기능 정도만 가진 웹을 만들 때는 굳이 라이브러리까지 설치하여 관리할 필요는 없습니다. 여러 컴포넌트에서 공유하지 않고 관리할 데이터가 얼마 없다면 useState와 같은 hook만으로도 충분할 것입니다.

하지만 상태관리 라이브러리는 이러한 상황에 초점을 둔 것이 아닙니다.


상태 관리의 필요성

컴포넌트에서 사용하는 상태(state)가 변경되면, 컴포넌트는 리렌더링되면서 변하는 값을 표시합니다. 대부분 이 state를 다른 자식 컴포넌트에도 적용하기 위해 전달하려는 경우가 생기는데, 그 때는 props로 이 값을 내려주게 됩니다.

하지만, (추가적인 작업이 없다면) 자식 컴포넌트는 이렇게 부모로부터 전달받은 state를 직접 변경할 방법이 없습니다.

만약 자식 컴포넌트가 부모로부터 받은 state값을 변경하고 싶다면, 부모로부터 상태값을 변경하는 함수를 props로 전달받아야 합니다. 예를 들어 useState를 사용했다면, setter 함수를 넘겨줍니다.

그런데 컴포넌트 갯수가 점점 많아지고 공유해야 하는 state가 늘어난다면 어떻게 될까요?

상태값을 전달하기 위해, 또 그것을 변경하는 함수도 같이 전달하려고 부모-자식-..으로 이어지는 전달 과정을 매번 작성해야 하는 매우 비효율적인 상황이 발생합니다.

내려 주는 깊이가 깊어질수록 더욱 그런 상황에 직면합니다(과도한 prop drilling).

단순히 값을 내려줄 때 불편한 것 하나로 라이브러리가 등장한 것은 아니겠죠.

프로젝트가 커져서 컴포넌트 갯수가 많아지고 그들간에 서로 공유하는 state 값들이 많아진다면, state가 어디서 어떻게 변하는지, 그리고 이 업데이트가 어떤 컴포넌트의 어떤 작업으로 인해 발생했는지, 손쉽게 파악하기가 힘들 것입니다.


전역 상태를 관리하는 라이브러리

그래서 대다수 상태관리 라이브러리들이 공통적으로 채택하는 개념은 전역 상태를 관리하는 것입니다.

Redux를 예로 들면, store 라는 state 저장 공간을 두어, 여러 컴포넌트가 하나의 store를 바라 보게끔 합니다.

(모든 상황에서 전역적인 상태 관리가 필요한 것은 아닐 것이며, 목적 없이 일단 라이브러리를 설치하고 보자 하는 것보다는, 여러 컴포넌트들간에 state 의존성이 높아지는 경우에 상태 관리 라이브러리의 사용을 고려하게 되는 것입니다.)

Redux는 아직도 많은 프로젝트에서 쓰이고 인기가 많지만, 별도 파일에 action type을 정의하고, action creator 함수를 만들고, 특정 action에 따라 state를 변화시키는 reducer를 작성하는 등 이런 반복되는 boilerplate code의 양이 많다는 것이 단점입니다.

그리고 상태값을 활용함에 있어서 비동기 처리나 state 값을 가공하는 등 부수적인 로직을 처리하기 위한 별도의 모듈(예: redux-saga, reselect..)들을 추가로 설치해서 써야 하는 경우도 마냥 달가운 상황은 아닙니다.

그래서 이렇게 Redux 를 사용할 때 겪는 단점들을 해결하기 위해 리덕스는 직접 Redux Toolkit 이라는 것을 만들어 배포했습니다.

Redux Toolkit의 목적 : Redux Toolkit - Purpose

이전의 Redux boilerplate code의 양을 확실하게 줄이고, 앞서 서술한 단점들도 보완된다는 것에는 이견이 없습니다. 하지만 이쯤 되면 다른 상태관리 라이브러리들은 어떤지가 궁금해지는 시점입니다.


[TypeScript] 타입스크립트 Utility types (1) - Exclude, Omit, Pick

2021년 돌아보기, 2022년에 해야 할 것들