-
Notifications
You must be signed in to change notification settings - Fork 11
상태관리를 어떻게 할 것인가 ?
프론트에서 데이터 전달, 이벤트 처리 등 어플리케이션에서 다양한 동작을 제어 하기 위해 상태를 사용한다.
현재 사용하는 React에서 상태는 화면을 렌더링하는데 큰 영향을 미치는 요소이다. 따라서 리액트 자체적으로 state를 관리 할 수 있으며, 관련 다양한 라이브러리가 제공되고 있다.
- 클래스형 컴포넌트,
this.state
- hooks,
useState
useReducer
useContext
- Redux
- Recoil
- Mobx
- 등등...
현재 프로젝트에서는 상태 관리를 위해 Mobx를 사용하기로 하였다.
Redux를 사용하지 않은 것은 Redux의 상대적으로 높은 러닝커브 때문이다.
Mobx가 상태 관리를 해주는 라이브러리이니 '어플리케이션의 모든 상태를 Mobx로 관리 할 것인가?'
'가계부 입력과 수정 같은 경우 같은 유형의 상태를 상태를 쓸 때 중복 처리는 어떻게 할 것인가?'
에 대한 의문을 가지게 되었다. 여기에서 현재까지 도출한 의견
1. 대부분의 상태를 Mobx로 관리하자
모달 visible 같은 짜잘한(?)것은 제외.
2. 컴포넌트간의 교류가 필요한 데이터만을 Mobx로 관리하자.
그 이외에 단일 컴포넌트에서 사용할 것은 그 안에서 알아서 선언해서 사용하자.
👍 장점
-
프로젝트에 상태가 전역으로 있어서 필요에 따라 연결만 하면 된다.
-
상태 관련 로직이 분리되어 있기 때문에 관리가 용이 할 수 있다.
-
기존 state 사용으로 재사용성 증가.
-
클래스로 관리를 한다면, State와 그 State에 연관된 메서드가 무엇인지 한 번에 알 수 있다.
→ 관리가 편해진다.
👎 단점
- state도 결국 메모리 자원으로 선언 한 만큼 메모리를 잡아먹는다.
- 리프래쉬 하지 않는 이상 상태가 유지 되기 때문에
reset
같은 연산에 신경을 써야 한다. - 엉뚱한 state로 인한 사이드 이펙트 발생 가능성이 있다.
🧐 궁금한 점
- 메모리를 엄청 많이 잡아먹을 것 같지는 않은데, 메모리 관점에서의 단점이 큰 단점일까?
- 큰 메모리를 잡아먹지는 않더라도, 메모리 관점에서 고려를 하는 건 좋은 것 같다.
👍 장점
- 상대적으로 적은 메모리를 사용한다. ( 그렇다고 이게 무조건 적다는 것은 아님 )
- custom hook 자체에서 비동기 통신으로 데이터를 가져와 state를 설정한다면, 개발자 입장에서는 custom hook을 사용할 때, 비동기 통신을 명시적으로 불러오지 않아도 된다.
👎 단점
- 컴포넌트와 로직이 같이 있어서 관리가 힘들 수 있다.
- 중복되는 상태를 만들 수도 있음.
- prop 관계가 깊어 질 수 있다.
먼저 이 고민이 시작된 거래내역 수정과 생성하는 페이지를 만드는 경우를 생각해보자.
수정과 생성하는 페이지는 같은 페이지와 같은 모델을 사용하게 될 것이다.
뷰를 불러오는 순서는 다음과 같다.
page → organism → organism → molecules → atoms
-
State를 사용하는 컴포넌트의 깊이가 깊지 않다.
만약 MobX를 사용한다면, organism 쪽에서 state를 구독해서 가져올 것이다. Custom Hook으로 만든 state를 사용한다면 page에서 state를 organism으로 넘겨줄 것이다. 한 단계 depth 정도의 차이를 줄여줄 수 있음은 MobX를 사용하여 상태관리를 하는 것이 그렇게 큰 장점으로 느껴지지 않는다.
-
비동기 통신으로 거래내역을 가져와서 state를 초기화해주는 측면
거래내역 수정의 경우, 비동기 통신으로 거래내역을 받아와서 state를 초기화해 주어야 한다. 이것을 Custom Hook 내부에서 알아서 해준다면, 비동기 통신을 해주는 메소드를 불러오는 과정을 안 할 수 있다.
-
state의 reset을 신경써야 한다는 측면
수정과 생성이 같은 모델을 사용하게 되는데, MobX를 사용한다면, state를 reset 해주는 과정을 신경써야 한다. 그러나 Custom Hook을 사용한다면 수정 페이지와 생성 페이지를 렌더링할 때 state가 생성되기 때문에, 이전의 값을 reset하는 과정은 하지 않아도 된다.
✅ 컴포넌트간의 교류가 필요한 데이터만을 Mobx로 관리하자
-
전체적으로 MobX를 사용하지 않아도 괜찮은 이유 !
- 상황에 따라 MobX를 사용하는 것이 더 좋을 때가 있고, 자체적인 state를 사용하는 것이 더 좋을 때가 있다.
- 비동기 처리와 같은 연산을 custom hook과 같은 것으로 처리 했을 때 좀더 우아한 코드가 될 것으로 기대한다.
- 아토믹 디자인으로
bottom ⇒ up
으로 prop에 대한 처리를 하였기 때문에, prop 깊어지는 것에 큰 어려움을 없을 것으로 기대한다.
-
MobX 사용 시 주의할 점
state를 전역으로 사용하는 편리한 만큼 신경을 써야 한다.
→ 이전 state로 의도치 않은 렌더링, 페이지 출력이 있을 수 있다.
- Optimistic Update
- 상태관리를 어떻게 할까
- Atomic Design 설계
- Mongoose Atomic Update 방식을 찾아서
- MobX Best Practices는 어디에
- 거래내역 스토어 관리
- user-account DB관계 수정
- 알림 기능 구현
1 주차
- 데일리스크럼
- 회고