좌충우돌 anecdote

상태 관리의 필요성

React에서 가장 중요한 상태값은

state가 많은 것은 문제가 되지 않지만, state가 많아지고 그것을 사용하는 컴포넌트의 갯수가 늘어날 수록 props drilling이 심해진다. 

state를 관리하지 않으면 여러 상태 값에 의해 컴포넌트가 재렌더링이 된다는 뜻이다.

state가 어디서 어떻게 변하는 지 한 눈에 파악하기 힘들어지고, 어떤 컴포넌트에 의해 상태 값이 변화했는지  손쉽게 파악하기 힘들다.

그래서 우리는 전역 상태를 관리해야 하고, React 컴포넌트 트리 안에서 데이터를 전역적으로 공유할 수 있는 상태 관리 라이브러리를 사용한다.

상태 관리 라이브러리

상태 관리 라이브러리는 다양하다. Context API, Redux, MobX, Recoil 등의 많은 도구가 있고, 각각의 장/단점이 분명하게 존재한다.

Context API

• 가장 많이 쓰이는 상태 관리 라이브러리로 간단한 상태 관리만 필요하다면 쓰기 좋은 라이브러리이다.
• 함수형 Hooks에서는 기능이 제한되어 있다.
• 성능과 기능이 적다.

=> 간단한 프로젝트에 사용하기 좋은 상태 관리 라이브러리이다.

참고 자료 https://ko.legacy.reactjs.org/docs/context.html

Redux

• 1개의 root & 1개의 store 만이 존재하고, 순수 함수(pure function)에 의존한다.
• MVC 패턴의 문제점을 극복하고자 페이스북에서 고안한 상태 관리 도구이다.
• 상태가 읽기 전용이다. 🥶
  • 지속적으로 불변성을 유지해야 하기 때문에 immutable.js와 같은 라이브러리를 사용해서 상태 값을 바꿔야 한다.
• 상태 값의 변경 사항을 Redux Devtools를 이용해 직관적으로 볼 수 있는 방법이 있다.
  • 상태 값이 많아질 경우 디버깅 할 때 굉장히 유용할 것이라고 생각한다.
• 작은 상태 하나를 변경하려고 해도, actions, reducer, type 등 여러번 작성해야하는 번거로움이 있다.
  • 그렇기 때문에 상대적으로 더 많은 양의 코드를 작성해야 한다.

Recoil

Recoil은 페이스북에서 만든 React를 위한 상태 관리 라이브러리이다. 

• React의 useState와 비슷하게 동작하여, 러닝 커브가 적고 직관적인 구조로 구성되어 있다.
  
  • useState -> useRecoilState
  • state -> useRecoilValue
  • setState -> useSetRecoilState
• 비동기 처리를 기반으로 작성되어 동시성 모드(concurrent mode)를 제공하기 때문에, Redux와 다르게 비동기 처리 라이브러리에 의존할 필요가 없다.
• 단점으로는 Redux처럼 안정적인 Devtool이 없다.
  • Snapshot을 사용하면 RecoilRoot 컴포넌트 안에서 사용하는 모든 Recoil 상태에 접근이 가능하지만, 직관적으로 볼 수 있는 것은 아니고 콘솔을 이용하는 형태로 볼 수 있다.

=> 확실히 React를 만든 Facebook에서 직접 만든 것이라 다른 상태 관리 라이브러리보다 호환성이 좋다고 생각한다. 
뿐만 아니라, 러닝 커브가 적어 세팅하기도 편하다.

참고자료

https://recoiljs.org/ko/docs/introduction/getting-started/