상태관리 라이브러리

리덕스 공부하면서 상태관리 라이브러리에 대해서도 정리하게 되었다.
상태관리 라이브러리에 대해 알아보자

---

What - 상태관리 라이브러리란 무엇인가

이름 그대로 상태를 관리하는, 즉 state 관리를 목적으로 하는 라이브러리이다.

Why - 상태관리 라이브러리란 왜 필요한가

프로젝트의 규모가 커질수록 관리해야하는 state가 많아지게 된다.
이를 체계적이고 효율적으로 관리하기위해 고안된게 상태관리 라이브러리이다.

더욱 근본적인 이유!

그렇다면 우리는 어째서 state를 관리해야 하는가?

먼저 우리가 리액트 스타일의 웹 개발에 대해 생각해보자

• 우리는 화면을 구성하기 위해 html파일에 컴포넌트들을 넣어 사용한다.
• 그 컴포넌트들은 props 형태를 통해 서로 상태를 공유한다.

여기서 잠깐!
이러한 props 전달 방식의 특성이자 단점이 바로 우리가 상태관리와 상태관리 라이브러리를 사용해야하는 이유이다.

props 는 단방향 데이터 전달방식이다.

즉, 부모 -> 자식 컴포넌트로만 상태를 전달할 수 있다.
여기서 발생하는 문제점들이

• 자식 컴포넌트에서는 상태 변경이 불가능하다.(setState를 통해 접근이 가능하지만 비효율적)
• 자식 컴포넌트간에는 상태 공유가 불가능하다.(부모 컴포넌트를 통해서만 접근 가능)
• 컴포넌트 계층이 많아지면 props 하나를 전달하는데에 거쳐야할 컴포넌트가 많아진다.
  즉, 중간단계의 컴포넌트들은 사용하지도 않는 props를 들고 있어야 한다.
  => props drilling 발생
  

이며,
이러한 문제점들은 프로젝트의 규모가 커질수록 심각해지고 이것이 우리가 상태관리 라이브러리를 사용해야 하는 핵심적인 이유이다.

Which - 상태관리 라이브러리의 종류

• Redux
• Recoil
• MobX
• React Context API

각각의 특성

Redux

장점

• 과정이 로그로 남아 디버깅하기 좋다.
• 전역 상태관리에 용이하다.
• Js 기반의 많은 환경에서 사용이 가능하다.
• 오래되고 사용도가 높아 참고자료가 많다.(꽤나 중요)
• 사전에 정의된 동작만 이행한다.(예측 가능, 디버깅 용이)
• 다양한 미들웨어(리덕스의 꽃)
• 최적화

단점

• 코드량이 상당해진다.
• 코드가 복잡하다.(처음 접해보면 이게 뭔가 싶다)
• 초기 세팅 과정이 길다.
• 불변성 유지를 위해 매번 새로운 상태 객체를 만들 반환해주어야 한다.(장점이기도 함)
• 보일러 플레이트 코드가 많다.

공부해야 할게 너무 많다...

Recoil

장점

• 비동기 처리가 쉽다.
• 만만하다.(상당히 쉽다. 볼것도 없다.)
• 가볍다.
• React 전용이라 친근하다.(문법이 거기서 거기)

단점

• 전역 상태 관리(쉬운 전역상태 관리는 리코일의 장점이지만 단점이기도 하다)
• 상태 변경 예측이 힘들다(프로젝트가 커질수록 상태 변경을 예측하기 힘들어진다)

MobX

장점

• 간단하다(리덕스에 비해)
• 객체 지향적이다.
• 불변성을 고려하지 않아도 된다.

단점

• 레퍼런스가 없다.(참조할 자료가 그리 많지 않다.)
• 버전과 브라우저에 따른 차이가 크다.
• 안정성이 그리 높진 않다.
  (리덕스와 달리 액션 단에서 바로 상태를 변경한다. 이는 추후에 유지보수 및 디버깅에서 문제가 생길 수도 있다.

Context API

상태관리 라이브러리라고 할 수 있는지는 모르겠다.

이 표현에는 두가지 이유가 있다.

• Context API 자체는 라이브러리가 아니다. 그저 React 라이브러리에 포함되어 있을 뿐
• 성능이 미쳤다. 전역 상태 관리로서는 적절치 못하다.

장점

• 사용이 쉽다(?) react 라이브러리에서 그냥 import 만 하면 된다.

단점

• 성능이 미쳤다.(상태값 하나만 변경해도 provider로 감싼 모든 자식 컴포넌트들이 리렌더링 된다.)
• 이러면 props drilling 을 회피하여 얻는 장점보다 잃는게 더 많다.

물웅덩이 피하려다가 똥 밟는꼴

결론

리덕스는 든든하고,
리코일은 친근하다.

MobX와 Context API는 써보질 않아서 확실한 결론은 못내겠다.