상태관리 라이브러리의 장단점 정리

React로 개발을 하다보면 props를 많이 사용하게 된다. 하지만 이 과정에서 구조상 props가 너무 깊게 내려간다거나 같은 하나의 데이터를 여러 컴포넌트에서 공통적으로 사용해야 하는 경우가 발생한다. 이 경우 상태 관리를 이용하여 이를 해결할 수 있는데, 상황에 따라 혹은 선호도에 따라 선택할 수 있는 라이브러리가 많다. 이번 포스팅에서는 상태관리 툴에 약간의 장단점과 내 생각을 정리해 보려 한다. (본인은 context만 사용해 보았다.)

Redux

상태관리를 위해 사용하는 JavaScript 라이브러리 이다. Flux 아키텍쳐를 따르며 단방향 데이터 흐름 모델을 통해 상태를 관리를하여 확장성을 늘려준다.

장점

1. 상태 예측이 가능하다.

동일한 상태와 액션이 리듀서에 전달되면 리듀서는 순수 함수이기 때문에 항상 동일한 결과가 생성된다. 또한 이전 상태 사이를 앞뒤로 이동하고 결과를 실시간으로 볼 수 있습니다.

2. 유지 보수가 용이하다.

코드를 구성하는 방법에 대해 엄격하므로 Redux에 대한 지식이 있는 사람이 Redux 애플리케이션의 구조를 더 쉽게 이해할 수 있다.

3. 디버깅이 쉽다.

어떤 액선이 일어나고 데이터가 어떻게 변화했는지 로그가 남는다. 또한 개발자는 이전의 특정 상태로 돌아가볼 수 있다. 때문에 시간 여행이 가능해지며 버그가 나기 이전 상태로 돌아가서 테스트해볼 수 있다.

4. 한 곳에서 관리

store를 이용하여 상태를 한 곳에서 관리한다. 전역상태를 관리할 때 효율적이다.

단점

1. 코드의 증량

리덕스로 코드를 구현하는 순간 필수적으로 만들어야하는 파일이 있다. 때문에 코드량이 그만큼 증가하게 된다.

2. 읽기 전용

리덕스는 상태를 읽기 전용으로 취급하지만 읽기 전용으로 만들어주지는 않는다. 때문에 항상 직접 수정하지 않게 하기위해 주의해야 한다.

3. 컴포넌트와의 연결성

store와 component를 연결하기 위해 mapStateToProps, mapDispatchToProps 와 같은 메서드가 필요하다. (코드량이 증가한다.)

Mobx

MobX는 functional reactive programming을 투명하게 적용함으로써 상태 관리를 쉽고 확장성 있게 만들어주는 검증된 라이브러리입니다. -Mobx-

장점

1. 객체지향적

mobx는 객체지향적으로 class를 사용할 것을 권장한다.

2. 데코레이터

데코레이터를 제공하기 때문에 좀더 깔끔하게 구성이 가능하다.

3. 캡슐화

state의 변경을 오직 메서드를 통해서만 변경할 수 있게 설정이 가능하다. (privite)

단점

1. 디버깅이 불편하다

리덕스와 같은 툴이 마땅히 없기에 디버깅을 위해서 console.log를 이용해야 한다.

2. 데코레이터

개인적으로 데코레이터는 장점이자 단점같다. Class 형으로 컴포넌트를 구성했다면 데코레이터는 장점이 될 수 있지만 함수형으로 구성했다면 단점이라 생각한다. 함수형에서 데코레이터를 사용하기 위해서는 useContext hook을 이용해야하며 컴포넌트에 연결하기 위해 hoc로 랩핑해야 한다.

3. 레퍼런스

레퍼런스 코드가 부족하다. 특히 함수형의 경우 정말 찾아보기 힘들다.

Context api

장점

1. 접근성

react에서 제공하는 기술이기에 추가 설치가 필요없다.

2. 러닝 커브

Mobx와 Redux에 비해 러닝커브가 낮다.

3. 간결성

사용하기위한 코드 구성이 가장 간결하다.

단점

rendering

context의 provider는 value값이 변할 경우 해당 값을 사용하는 컴포넌트 또한 리렌더링이 된다. 만약 컨택스트를 상태값과 액션값으로 나누어 사용하면 이 문제는 해결이 가능하다. 하지만 그에따른 보일러 플레이트코드가 증가하며 복잡해질 수록 provider가 늘어나 지옥이 될 수 있다.

Recoil

fecebook에서 만든 상태관리 라이브러리이다. 기존 context의 렌더링 문제, 단일값만 저장 가능한 문제(consumer를 가지는 여러 값의 집합을 저장 못하는 문제), 코드 분활의 어려움을 해결하고자 만든 라이브러리이다.

장점

1. 간단한 인터페이스로

get/set으로 사용할 수 있도록 boilerplate-free API를 제공

2. 증분 및 분산

코드 분할이 가능해진다.

3. 컴포넌트 비수정

컴포넌트를 수정하지 않고 상태 데이터로 대체 가능하며 파생된 데이터를 사용시 동기식과 비동기식 간에 이동이 가능하다.

단점

1. 호환성

Recoil 빌드는 ES5로 트랜스파일 되지 않으므로, Recoil을 ES5와 사용하는 것은 지원하지 않는다. -Recoil-

ES5에서도 사용할 수 있는 방법은 있으니 버그가 발생할 수 있다 명시되어 있다.

2. 레퍼런스

나온지 얼마 안된만큼 레퍼런스가 부족하다.

공통적인 단점

컴포넌트의 재사용성을 해칠 수 있다.

맺음말

이상으로 각 상태관리 라이브러리에 대하여 간략히 알아보았다. 사실 사용해본 기능이 context뿐인 만큼 각자의 개념만 살짝 맛봤을 뿐 어떤것이 더 좋은지 경험에서 판단하기는 불가능 한것같다. 하지만 개인적으로 규모가 작거나 전역관리 하나만 필요할떄는 context만으로도 충분할 것 같으며 recoil의 등장으로 조금씩 선호도가 변할 수도 있을 것 같다는 생각이 들었다. 또한 전역관리는 중요하지만 남발할 경우 재사용성을 해할 수 있다는 공통적인 단점이 있기에 항상 사용에 주의해야 할 것같다.