1. State Management
React를 처음 접하다 보면, 종종 상태 관리라는 개념을 마주치게 된다.
처음에는 React라는 프론트엔드 렌더링 라이브러리가 컴포넌트에서 상태를 지역적으로만 접근할 수 있어 막연하게 상태 관리가 필요하다는 사실과 함께 상태 관리에 대해 제대로 개념이 잡히지 않고, 충분한 필요성을 느끼지 못한 채로 상태 관리 라이브러리를 곁들여 React를 배우기 시작한다.
- 지역적으로 접근의 의미 > 구체적으로 말하면 하나의 컴포넌트는 하나의 상태를 가지며, 그러한 컴포넌트에서 어떤 데이터를 화면에 렌더링하기 위해서는 필요한 데이터를 상태에 갖고 있어야 하는데 리액트에서는 전역적으로 상태를 관리할 수 없어서 props를 통해 필요한 컴포넌트까지 전달할 수 밖에 없다는 것을 말한다.
- 필자 또한 실제로 지금까지도 제대로 이해하지 못하고 사용 중인 부분이 많다. 그래서 이번 포스팅을 포함해 리액트 관련 포스팅을 진행하며 공부할 예정이다.
다시 상태 관리가 중요한 이유로 돌아와서…
상태 관리가 중요한 이유를 정확히 짚어야만, 자신 현재 어떤 어려움이 있어 이를 상태 관리 라이브러리로 해결할 것인지 말할 수 있고, 어떤 라이브러리의 기능을 활용할 것인지, Redux를 사용할 것인지, MobX를 사용할 것인지 등을 결정할 수 있을 것이며, 상태 관리를 함에 있어 필요한 개념에 대한 이해가 훨씬 쉬울 것이라고 생각한다.
- 가장 중요한 이유는 프로젝트의 규모가 커지고, 요구사항이 늘어남에 따라 컴포넌트 간 상태 교환도 증가한다면 개발과 유지보수하기가 어렵다는 것이다.
- 위의 그림을 보면, 상태 관리 라이브러리가 있고 없고의 차이에 따라 하위 혹은 상위 컴포넌트에서 어떤 상태를 보내고, 받아올지에 따라 컴포넌트 코드에 포함되는 상태 교환 코드의 양이 상당히 늘어날 것이다. 그렇게 된다면 당연히 개발하기도 복잡하고, 유지보수하기도 어려운 코드가 된다.
- 그러므로, 상태 관리에 관련된 코드를 컴포넌트에서 분리할 수 있도록 도와주는 것이 상태 관리 라이브러리라고 할 수 있다.
- 오해하지 말아야 할 것은 상태 관리를 확장하거나, 별도의 상태 계층을 두는 것은 상태 관리 라이브러리가 없더라도 할 수 있다는 것이다. 그렇기 때문에 상태 관리 라이브러리를 사용하기 전에 지역적 상태 관리만을 통해 상태를 관리해보며 개발해 보는 과정이 상태 관리 라이브러리에 대한 필요성을 느끼기 위해 필요하다고 생각한다.
2. MobX
필자는 Redux를 사용해본 적이 없다. 어렵다는 이야기를 많이 들어 지레 겁먹은 감도 없잖아 있지만, 나름대로 Redux를 조사해본 결과
- 많은 양의 보일러 플레이트 코드
- 많은 양의 코드로 인해 코드의 복잡성이 증가한다.
- 상태 관리에 관한 높은 이해도를 필요로 한다.
세 가지 이유와 MobX의 몇 가지 장점 때문에 MobX를 사용해보게 되었다.
- ES6에서 도입한 클래스 문법 때문에 자바스크립트를 이용하여 객체 지향적으로 프로그래밍이 가능해졌다.
- 클래스 문법 때문에 객체 지향적으로 프로그래밍이 가능해졌다는 점이 스프링으로 서버 어플리케이션을 개발하던 나에게는 계층 구조 별로 코드를 나누는 설계를 익숙하게 받아들일 수 있게 되었다. (실제로 MobX를 사용하여 상태에 사용될 객체를 Model, RESTful API 요청을 통해 상태에 사용될 데이터를 받아오는 Repository, 컴포넌트와 연결되며 상태 관리에 대한 Store 이 세 가지 클래스로 나누어 설계를 하였다. 스프링에서 Persistence, Service, Controller 세 가지 계층으로 나누는 것과 유사하다.)
- npm eject와 간단한 Babel 설정으로 자바의 어노테이션과 유사한 데코레이터를 사용하여 보다 간단한 코드를 작성할 수 있다.
결론적으로, 내가 진행할 프로젝트는 규모가 그리 크지 않았고, 상태 관리를 쉽게 할 수 있다는 점에서 개발자(나)에게 보다 높은 생산성과 효율성 때문에 MobX를 선택하게 되었다.