MobX 정리를 하기전, Flux
Mobx ·현재 개발 중인 슈퍼 오피스는 MobX 라이브러리를 사용하고 있다. MobX 라이브러리를 실제 사용하면, 워낙 사용하기 쉽기 때문에 평소에 지나치기 쉬운 개념들에 대해서 생각해보고 정리를 하고자 한다.
Flux
-
Mobx에 대해서 정리하기던 전 기원에 대해서 먼저 알아보자. Flux는 페이스북 개발자들이 처음 고안한 개념으로 페이스북 채팅 시스템에서 발견된 결함을 해결하기 위해 태어났다고 한다.
-
해당 결함에 대해서 설명하자면, 애플리케이션의 데이터를 공유하는 구성 요소가 많아질수록, 그리고 그 구성 요소간의 상호작용이 복잡해지면 복잡해질수록, 데이터의 상태를 예측하거나 이해하기 어려워진다. 그렇게 되면 애플리케이션을 더 이상 확장하거나 유지 보수하기 어려운 상황이 발생할 수 있다.
-
Flux는 이러한 결함을 완화시키기 위한 아키텍처 가이드라인으로 Mobx와 Redux 그리고 Vuex는 Flux의 일부 패턴을 구현한 라이브러리라고 할 수 있다.
-
Flux는 기본적으로 스토어(store), 액션(action), 디스패처(dispatcher), 뷰(View) 네 부분으로 구성된다.
Store
- Flux에서 컴포넌트는 데이터와 완전히 분리되어야 하지만, 데이터가 변경될 때마다 다시 렌더링할 수 있도록 알림을 받는다. 스토어는 애플리케이션의 모든 상태(데이터와 UI)를 유지하며 상태가 변경되면 이벤트를 발송한다. 컴포넌트는 필요한 데이터를 포함하는 스토어를 구독하며 데이터가 변경되었다는 알림을 받으면 자신을 다시 렌더링한다.
- 애플리케이션의 다른 부분에서는 스토어의 데이터를 변경, 갱신, 삽입할 수 없다. 오직 getter형태로 데이터에 대한 접근권한이 주어지며 데이터를 변경하려면 다른 수단이 필요합니다.
Action
- 위에서 말한 수단이 바로 액션이다. 액션은 애플리케이션의 거의 모든 부분에서 생성될 수 있으며, 사용자 상호작용(버튼 클릭, 검색 결과 요청, 텍스트 입력)과 Ajax 요청, 타이머, 웹 소켓 이벤트 등을 통해서 생성된다.
Dispatcher
- 디스패처는 액션을 스토어로 전달하는 과정을 조율하고 스토어의 액션 핸들러가 올바른 순서로 실행되도록 관리한다. 디스패처는 액션들을 받아서 해당 해당 디스패처를 등록한 스토어에게 전달하는 역할을 하며 한 애플리케이션은 싱글턴 디스패처를 가지고 있어야 한다.
View
- 스토어의 데이터는 뷰를 통해서 사용자에게 보여지게 된다. 액션들은 주로 사용자가 뷰와 상호작용할 때 뷰로부터 생성된다.