Skip to content

Latest commit

 

History

History
75 lines (39 loc) · 3.68 KB

상태관리 라이브러리.md

File metadata and controls

75 lines (39 loc) · 3.68 KB

상태관리 라이브러리


상태관리 라이브러리의 필요성

'상태관리 라이브러리는 왜 필요할까?' 라는 것에 초점을 두어야 한다.

규모가 작은 프로젝트라면 굳이 상태관리 라이브러리를 사용할 필요는 없다.

React를 예로 들면, 16.3 버전에서부터 Context API 가 더욱 좋아지면서 글로벌 상태 관리 또한 별도의 라이브러리 없이 할 수 있게 되었다.

하지만, 프로젝트의 규모가 커지면서 setState로 상태를 구성하고, 이를 props로 넘겨주는 등의 일이 점점 복잡해진다.
뿐만 아니라 상태 업데이트 로직이 컴포넌트 별로 존재하면서 유지보수가 어려워질 수 있다.

사실, 상태관리 라이브러리를 사용하는 이유를 말하자면 간단하다.

애플리케이션의 상태를 단일 스토어에서 관리하고 상태의 흐름을 단방향으로 통일하기 위해서이다.

React에서 주로 사용되는 상태관리 라이브러리에는 ReduxMobx가 있다.


Flux Architecture

Flux 구조는 MVC 구조의 Model, View, Controller의 역할 배분의 구조가 아닌 이벤트와 데이터의 흐름에 집중한다.

Facebook을 예로 들면, 타임라인만 봐도 수많은 사람들이 매번 글을 올리고 그 글에 몇천, 몇만명의 사람들이 댓글을 쓰고 좋아요를 누른다.

이런 복잡한 데이터 흐름을 단방향으로 통일시킴으로써 문제를 해결한 것이 Flux 구조다.

flux_architecture

  • Action : 앱에서 발생한 이벤트(조작), 데이터의 변화에 대한 정보를 담고 있다. Action이 만들어지는 것만으로는 앱에 변화를 주진 않는다.

  • Dispatcher : Action을 순서대로 Store로 전달하는 역할을 한다.

  • Store, View : Dispatcher로 받은 Action을 기반으로 Store 내의 상태를 변경하고 이를 View에 반영하여 화면에 그린다.

Flux 구조를 사용한 대표적인 라이브러리가 ReduxMobx다.


Redux vs Mobx

Redux


  • 단 하나의 스토어를 애플리케이션의 모든 상태를 관리한다. 이는 애플리케이션의 상태를 예측가능하기 쉽게 한다.

  • 함수형 프로그래밍 패러다임을 기본적으로 따른다. 익숙하지 않은 개발자들에게는 낯설 수 있다.

  • 불변성을 필수적으로 지켜줘야한다.

  • 하나의 스토어로 관리하기 때문에 애플리케이션 전체의 흐름을 잘 통제하는 만큼 수많은 Dispatcher가 발생했을 때 병목현상이 발생할 수 있다.(이를 막기 위해 Redux-thunkRedux-saga와 같은 미들웨어를 사용한다.)

Mobx


  • 다수의 스토어를 가질 수 있고 기본적으로 Observable을 사용한다. 이는 Redux보다 데이터 흐름을 쉽게 관리할 수 있게 한다.

  • Redux에서 중요하게 신경썼던 불변성을 신경쓰지 않아도 된다.

  • 새롭게 알아야하는 개념(Reducer, Immutable, connect, Action, Dispatcher, 미들웨어)이 많은 Redux에 비해 Running-Curve가 적다고 한다.



Reference