새 프로젝트에서 MobX를 사용해도 될까? Redux vs MobX

리액트는 State(상태) 관리 라이브러리를 사용해야 편하다.

이전 프로젝트에서는 Global State를 관리하기 위해 Redux를 사용하다가

신규 프로젝트에서는 MobX를 사용해보면 어떨까 검토하기 위해 두 라이브러리를 비교한 글들을 짜집기해봤다.

 

Redux는 워낙 다양한 방식으로 구현하기 때문에 이전 프로젝트에 적용했던 것을 기준으로 작성했다.

 

---

Redux

Flux와 함수형 프로그래밍을 결합한 가장 많이 사용되는 상태 관리 솔루션.

 

Mobx

애플리케이션 내에서 로컬 상태를 관리할 수 있는 상태 관리 솔루션.

 

 

1. 점유율(인지도)

2020.6.21 기준 구글 검색어 통계만 비교해보아도 Redux가 압도적임을 확인할 수 있다.

 

JavaScript 2019 Survey 결과에서도 Redux를 사용해봤고, 앞으로도 사용하겠다는 비중이 훨씬 높다.

점유율이 높을 수록 관련 문서가 많고 커뮤니티가 활발하다.

 

특히 Redux는 리덕스 개발자 도구(React DevTools)라는 편리한 크롬 확장 프로그램이 있어

현재 Store의 State를 조회할 수 있고 어떤 액션이 디스패치 되었는지, 액션에 따라 Store State가 어떻게 변화했는지 확인이 가능하다.

 

MobX도 몹엑스 개발자 도구(Mobx Developer Tools)라는 크롬 확장 프로그램이 있는걸 확인 했지만, 리덕스 개발자 도구와 비슷한 퀄리티는 아니라고 한다.

 

 

2. 러닝커브

흔히들 React가 Vue보다 러닝커브가 높다고 한다.

그 이유는 React 자체가 어렵다기 보다 Redux를 적용하는데 어려움이 있기 때문이다.

 

나도 회사 프로젝트를 진행하면서 React와 Redux-Saga를 처음 접했고 Store, Action, Reducer 등 추상적인 Redux Data Flow를 이해하는데 애를 먹었다.

 

반면 MobX는 Java Spring Framework와 유사한 구조를 지니고 있어 특히 서버사이드 개발자에게 러닝커브가 낮은 편이다.

Layer	Spring	Mobx	Redux
Service Layer	Service	Store	Reducer
Model Layer	Entity 또는 Dto	Model Class	Reducer의 method 또는 ReSelect 라이브러리로 Getter 역할을 분리하기도 함
Repository Layer	Repository	Repository Class	Redux-Thunk 또는 Redux-Saga

세 가지를 비교해보면 위와 같다.

 

 

 

3. 보일러 플레이트 코드 (상용구)

우리 기존 프로젝트는 비동기 Action을 처리하기위한 라이브러리인 Redux-Saga를 사용했다.

 

useSelector라는 Hook을 사용해 Component와 State를 연결했고

Action을 생성 해주는 createActions, Action과 Reducer를 매핑해주는 handleActions 라이브러리를 사용했기때문에

mapStateToProps, mapDispatchToProps, bindActionCreators 등의 보일러 플레이트 코드는 많지 않았다.

 

불변성 state를 편하게 관리하려 했다면 여기에 추가로 ImmutableJs (redux-immutable) 라이브러리를 사용했을 것이다.

(리액트 개발자가 걷게되는 길 - 우리는 ImmutableJs는 쓰지 않았음)

 

또한 Redux 구조는 Action 타입 정의, Action 생성 , Reducer 생성을 각각 개별 파일 (3개)로 작성하는게 기본이지만

기능(모듈) 중심으로 파일을 나누는 Ducks Pattern을 따랐다. 그래서 하나의 기능을 추가/수정할 때에는 하나의 파일만 다루었기 때문에 큰 불편함이 없었다.

 

Mobx를 사용하면 데코레이터(어노테이션) 사용으로 보일러플레이트 코드를 해결할 수 있다.

찾아보니 Redux에서도 데코레이터를 사용할 수 있긴 하다. redux-connect-decorator 라이브러리를 사용하면 클래스 기반 접근이 가능하다고 한다.

 

정리해보자면, MobX를 사용하면 데코레이터를 통해 보일러플레이트 코드를 다량 줄일 수 있다.

Redux에서도 보일러플레이트 코드를 줄일 수 있지만 그에 따른 추가 라이브러리 사용이 필요하다.

 

 

4. Store 관리

Redux는 단일 Store를 갖고 여러개의 Reducer로 이를 분할할 수 있다. (a single source of truth)

따라서 현재 State와 관련하여 중복 또는 혼동이 발생할 수 없어 직관적이다.

 

Mobx는 Multiple Store를 허용한다. 논리적으로 Store를 분리할 수 있기 때문에 모든 애플리케이션 상태가 하나의 Store에 있지 않다.

따라서 UI State와 Domain State 2개로 Store를 분리해서 설계할 수 있다. 이 방법을 사용하면 다른 애플리케이션에서 Domain State를 재사용할 수 있다.

 

이 관점은 개발자에 따라서 선호가 갈린다고 한다.

개인적으로는 여러 명이 협업할 경우 같은 State가 여러 Store에 들어있는 등 중복이 발생할 것 같아 단일 Store가 마음에 든다.

 

 

5. State 관리

Redux에서 State는 변경할 수 없기 때문에 모든 State가 읽기전용이다. 이는 Reducer를 순수하게(Pure) 만든다.

Pure Function은 예측 가능하고 단순하기 때문에 테스트하기가 더 쉽다는 장점을 갖는다.

또한 plain JavaScript Objects를 데이터 구조로 사용하며 State의 변경은 직접 dispatch를 통해 업데이트 해줘야 한다.

 

MobX에서 State는 변경이 가능하기 때문에 간단하게 업데이트가 가능하다. (Impure) (객체에 push를 통해 항목 추가등이 가능하다는 말)

Impure Function은 항상 예측 가능한 출력을 반환하지는 않으므로 테스트 및 유지 관리가 더 어렵다.

데이터 구조는 Observable한 데이터를 사용하여 구독을 통해 변경 사항을 자동으로 추적한다. 따라서 데이터 업데이트가 자동으로 된다.

 

기존 프로젝트의 Reducer를 보면 불변성을 유지하면서 State를 업데이트 하기 위해 스프레드 연산자(... state)를 사용했다.

그래서 State의 구조가 복잡할 경우 업데이트가 번거로웠지만, 이 점은 꼭 MobX를 써야만 편리한게 아니라 Redux에 ImmutableJS를 사용해도 코드를 직관적으로 작성할 수 있다.

 

데이터 구조에 관해서는 개인적으로 MobX의 경우 여기저기에서 State가 변경하기 때문에 변경지점을 파악하기 어려울 것 같아 명시적으로 업데이트를 해야하는 Redux에 손을 들어주고 싶다.

 

---

참고

 

Redux와 Mobx 비교글

• A definitive guide to Redux vs. MobX
• Redux vs MobX: Which Is Best for Your Project?
• Redux Vs MobX: A Performance Comparison [2019]
• React에서 Mobx 경험기 (Redux와 비교기)
• [번역] React Native MobX 특집 1편 : 상태관리를 redux에서 mobX로 바꾼 이유

 

튜토리얼

• 상태 관리 라이브러리의 미학: Redux 또는 MobX 를 통한 상태 관리
• 리액트의 불변함, 그리고 컴포넌트에서 Immutable.js 사용하기
• Redux 를 통한 React 어플리케이션 상태 관리

 

기타

• react-redux 에서 Hooks 사용하기
• 리덕스 개발자도구 적용하기