redux, mobx, recoil 중 polar는 mobx를 선택했습니다:)
이유는 redux 보다는 mobx가 장점이 많고
recoil은 아무도 몰랐기 때문!
그래두 아직 사용은 redux가 1위라는 점~!!
그럼 각각의 장점부터 살펴볼까요??
앗 자연스럽게 네이버 블로그 말투로 변해버렸네요
역시 이게 편해~!~!
과거 : Jquery, Dom으로 Global Scope에서 대부분 작업할 했기 때문에, 큰 문제가 없었음
현재 : 기능 단위의 Component 조합 (SPA Framework)으로 이루어지게 되면서 부모자식 관계의 Scope으로 이루어져서 각 component간 상호작용(state, props)와 메소드의 접근이 까다롭게 됨.
위를 해결하기 위해 State를 Global한 Store영역에서 관리하는 방법을 사용해 state와 메소드 접근을 높임!
=> 이게 바로 전역 상태 관리의 등장!
이점 : React Component로만 개발하게 되면 비즈니스로직이 component에만 집중되면서, 스파게티 코드가 탄생함. => state관리 라이브러리를 사용해서 component는 controller에 해당하는 역할을 주고 나머지는 적절히 분리해 아키텍쳐 구성
mobx의 장점은?
- 객체지향적
- 데코레이터
- 캡슐화
- javascript는 접근제어자를 제공하지 않아, 데이터 핸들링 비즈니스 로직이 퍼지거나, 사이드 이펙트가 발생할 확률이 높고 잘 관리 안하면 번잡스러운 코드가 생산 됨.
- Mobx Configuration설정을 통해 state를 오직 메소드를 통해 변경할 수 있도록 private하게 관리 할 수 있음.
- 도메인 모델간의 message를 통한 상호작용 코드 패턴을 유지해 나갈 수 있도록 해줌.
- 불변성 유지
- 불변성 유지를 위해 별다른 코드나 라이브러리를 따로 사용할 필요가 없음
- 가독성 향상
- Mobx README정의 : 어플리케이션의 상태에서 파생될 수 있는 모든 것은 자동으로 파생되어야 함.
이게 무슨뜻일까요?? 정말 어렵게 정의 되어 있습니다.
쉽게 정리하면,
- Mobx : 모든 상태변화를 부분적으로 자동 추적해주는 전역 상태 라이브러리.
상태관리를 이용하지 않으면, 업데이트도 되지 않고 하나하나 신경을 써야합니다. 작은 파일이면 상관 없지만, 프로젝트가 조금만 커져도 여러곳에서 상태 관리를 해줘야합니다. 따라서 개발할 때 빠질 수 없는 요소라는 점!
mobx의 특징
- 간단하고 확장 가능한 상태 관리 라이브러리를 철학으로 함
- react에 종속적인 라이브러리가 아님
- typescript를 기반으로 만들어짐
- mobx는 절대적으로 필요한 경우에만 state 변경
- 아키텍처나 상태 컨테이너가 아닌 라이브러리
- actions, state, Derivations, Reactions 컨셉이 있음. (이건 코드 보면서 이해해야할듯)
- observable : Mobx에서 Rendering 대상이 되는 state를 observable value라고 칭함.
- @observable 데코레이터로 지정한 state는 관찰대상.
- 관찰 대상 state는 값이 변경될 때 마다 rerendering 됨.
git opensource를 보다보면 Store로 끝나는 함수들을 많이 보셨을텐데요! 과연 store라는 이름을 왜 붙이는 걸까요?
Store : global 영역에서 어플리케이션의 state와 비즈니스로직을 가지고 있는 주체 store.
++ 다음 포스팅에서 mobx 코드와 함께 자세한 mobx(actions, state, Derivations, Reactions)에 대해 만나용!!
[참고]