1시간이면 준비되는 MobX

프로젝트에서 지난 9개월 동안 Redux를 주력으로 사용하다 MobX로 바꾼 개인적 경험을 바탕으로 작성하였습니다.

 

Redux를 사용하였으므로 체계는 매우 잘 잡혀 있었고 스토어를 바꾸는 과정은 대략 3주가 걸렸습니다.

 

아키텍처는 곧 인터페이스이고 Flux 인터페이스의 핵심을 알고 있다면 그것을 구현한 라이브러리들은 프로젝트 상황에 맞게 선택하면 된다고 생각합니다.

 

고구마 줄기들보다 더한 Redux와 친구들에 대해, MobX는 정말 훌륭한 대안입니다.

 

너무 장황하게 펼쳐지는 Redux

 

Redux를 사용하다 보면, 너무 장황하게 펼쳐지는 느낌을 지울 수가 없습니다.

 

스토어의 개념이 익숙지 않은 사람들에게는 더욱 어렵고, 어지럽게 느껴집니다.

 

Actions, Saga, Thunk 외에도 '기술을 위한 기술'들이 계속 동반됩니다.

 

 

Flux
중요한 것은 Redux인지 MobX인지가 아니라 Flux 인터페이스입니다.

 

다양한 컴포넌트 사이에서 데이터를 주고받으면서 서로 얽히게 되면 관리하기가 어려운 것이 아니라 불가능해집니다.

 

특히나 대규모 프로젝트의 MVC패턴에서는 하나의 뷰에서 여러 모델이 사용되고 다수의 뷰가 컨트롤러에서 사용됩니다.

 

뷰에서 모델이 변경되고 모델에서 뷰가 변경되는 상호작용 속에서 종잡을 수 없는 연쇄작용이 펼쳐집니다.

 

5년 전쯤 AngularJS의 첫 번째 버전을 사용하면서 위의 상황을 직접 겪었습니다.

 

이를 해결하기 위한 Flux의 개념(패턴)은 간단합니다.

 

데이터의 흐름을 단순화시키는 거죠.

 

데이터의 원천은 하나입니다. 그곳을 스토어라고 명한다면 모든 컴포넌트가 스토어에서 데이터를 받으면 됩니다.

 

데이터를 변경해야 한다면 그 스토어를 바꾸는 것이죠.

 

자연스럽게 뷰 레벨에서 데이터는 선언형으로 그저 표현될 뿐입니다. 어떻게 받고, 어떻게 변경되는지는 기술할 필요가 없습니다.

 

뷰에서 데이터를 바꿔야 한다면 (사용자 인터렉션 등으로) 정의된 액션을 호출하기만 하면 됩니다.

 

 Flux 공식 문서에 잘 표현된 데이터의 단순한 흐름

 

1. (데이터는) 스토어에서 나와서 뷰로 갑니다.
2. (데이터에) 변화를 줘야 한다면 무조건 디스패치를 이용합니다.
3. (데이터의) 어떤 변화인지는 액션으로 구분하며 변화에 필요한 데이터가 있다면 해당 액션에 담겨있습니다.
   (만약 사용자가 자신의 기분을 선택(변경) 해야 한다면 CHANGE_USER_CONDITION이라는 액션과 좋음과, 매우 좋음이라는 데이터가 필요하겠죠)
4. 디스패치는 들어온 액션에 맞는 행동(콜백)을 실행하고 결과 데이터를 스토어에 전달합니다.
5. 스토어는 데이터를 변경합니다.
6. 변경된 데이터에 맞게 뷰가 업데이트됩니다.

 

 

이제 기본 개념이 자리 잡혔다면 마지막으로 옵져버 패턴에 대해 간략하게 알아야 합니다.

MobX는 옵져버 패턴으로 구현되어 있기 때문입니다.

 

옵져버 패턴 설명

 

 

이제 MobX를 실제로 사용할 차례입니다.

 

mobx 설치

mobx 실제 사용하기

 

손쉽게 스토어 생성하기

손쉽게 데코레이터로 스토어 연결하기

손쉽게 데이터 변경 설정하기

손쉽게 비동기 액션 사용하기

손쉽게 제너레이터 사용하기

손쉽게 when 사용하기