Skip to content

상태관리를 어떻게 할 것인가 ?

ParkSeungHwan edited this page Nov 27, 2020 · 5 revisions

프론트에서 데이터 전달, 이벤트 처리 등 어플리케이션에서 다양한 동작을 제어 하기 위해 상태를 사용한다.

현재 사용하는 React에서 상태는 화면을 렌더링하는데 큰 영향을 미치는 요소이다. 따라서 리액트 자체적으로 state를 관리 할 수 있으며, 관련 다양한 라이브러리가 제공되고 있다.

  • 클래스형 컴포넌트, this.state
  • hooks, useState useReducer useContext
  • Redux
  • Recoil
  • Mobx
  • 등등...

상태를 어떻게 관리 할 것인가?

현재 프로젝트에서는 상태 관리를 위해 Mobx를 사용하기로 하였다.

Redux를 사용하지 않은 것은 Redux의 상대적으로 높은 러닝커브 때문이다.

Mobx가 상태 관리를 해주는 라이브러리이니 '어플리케이션의 모든 상태를 Mobx로 관리 할 것인가?'

'가계부 입력과 수정 같은 경우 같은 유형의 상태를 상태를 쓸 때 중복 처리는 어떻게 할 것인가?'

에 대한 의문을 가지게 되었다. 여기에서 현재까지 도출한 의견

1. 대부분의 상태를 Mobx로 관리하자

모달 visible 같은 짜잘한(?)것은 제외.

2. 컴포넌트간의 교류가 필요한 데이터만을 Mobx로 관리하자.

그 이외에 단일 컴포넌트에서 사용할 것은 그 안에서 알아서 선언해서 사용하자.

1️⃣ 대부분 상태를 Mobx(상태 관리 라이브러리) 관리하자

👍 장점

  • 프로젝트에 상태가 전역으로 있어서 필요에 따라 연결만 하면 된다.

  • 상태 관련 로직이 분리되어 있기 때문에 관리가 용이 할 수 있다.

  • 기존 state 사용으로 재사용성 증가.

  • 클래스로 관리를 한다면, State와 그 State에 연관된 메서드가 무엇인지 한 번에 알 수 있다.

    → 관리가 편해진다.

👎 단점

  • state도 결국 메모리 자원으로 선언 한 만큼 메모리를 잡아먹는다.
  • 리프래쉬 하지 않는 이상 상태가 유지 되기 때문에 reset 같은 연산에 신경을 써야 한다.
  • 엉뚱한 state로 인한 사이드 이펙트 발생 가능성이 있다.

🧐 궁금한 점

  • 메모리를 엄청 많이 잡아먹을 것 같지는 않은데, 메모리 관점에서의 단점이 큰 단점일까?
    • 큰 메모리를 잡아먹지는 않더라도, 메모리 관점에서 고려를 하는 건 좋은 것 같다.

2️⃣ 컴포넌트간의 교류가 필요한 데이터만을 Mobx로 관리하자

👍 장점

  • 상대적으로 적은 메모리를 사용한다. ( 그렇다고 이게 무조건 적다는 것은 아님 )
  • custom hook 자체에서 비동기 통신으로 데이터를 가져와 state를 설정한다면, 개발자 입장에서는 custom hook을 사용할 때, 비동기 통신을 명시적으로 불러오지 않아도 된다.

👎 단점

  • 컴포넌트와 로직이 같이 있어서 관리가 힘들 수 있다.
  • 중복되는 상태를 만들 수도 있음.
  • prop 관계가 깊어 질 수 있다.

상황에 따라 생각해보자!

먼저 이 고민이 시작된 거래내역 수정과 생성하는 페이지를 만드는 경우를 생각해보자.

수정과 생성하는 페이지는 같은 페이지와 같은 모델을 사용하게 될 것이다.

뷰를 불러오는 순서는 다음과 같다.

page  organism  organism   molecules  atoms
  1. State를 사용하는 컴포넌트의 깊이가 깊지 않다.

    만약 MobX를 사용한다면, organism 쪽에서 state를 구독해서 가져올 것이다. Custom Hook으로 만든 state를 사용한다면 page에서 state를 organism으로 넘겨줄 것이다. 한 단계 depth 정도의 차이를 줄여줄 수 있음은 MobX를 사용하여 상태관리를 하는 것이 그렇게 큰 장점으로 느껴지지 않는다.

  2. 비동기 통신으로 거래내역을 가져와서 state를 초기화해주는 측면

    거래내역 수정의 경우, 비동기 통신으로 거래내역을 받아와서 state를 초기화해 주어야 한다. 이것을 Custom Hook 내부에서 알아서 해준다면, 비동기 통신을 해주는 메소드를 불러오는 과정을 안 할 수 있다.

  3. state의 reset을 신경써야 한다는 측면

    수정과 생성이 같은 모델을 사용하게 되는데, MobX를 사용한다면, state를 reset 해주는 과정을 신경써야 한다. 그러나 Custom Hook을 사용한다면 수정 페이지와 생성 페이지를 렌더링할 때 state가 생성되기 때문에, 이전의 값을 reset하는 과정은 하지 않아도 된다.


결론

컴포넌트간의 교류가 필요한 데이터만을 Mobx로 관리하자

  • 전체적으로 MobX를 사용하지 않아도 괜찮은 이유 !

    1. 상황에 따라 MobX를 사용하는 것이 더 좋을 때가 있고, 자체적인 state를 사용하는 것이 더 좋을 때가 있다.
    2. 비동기 처리와 같은 연산을 custom hook과 같은 것으로 처리 했을 때 좀더 우아한 코드가 될 것으로 기대한다.
    3. 아토믹 디자인으로 bottom ⇒ up 으로 prop에 대한 처리를 하였기 때문에, prop 깊어지는 것에 큰 어려움을 없을 것으로 기대한다.
  • MobX 사용 시 주의할 점

    state를 전역으로 사용하는 편리한 만큼 신경을 써야 한다.

    → 이전 state로 의도치 않은 렌더링, 페이지 출력이 있을 수 있다.

Clone this wiki locally