상태 관리 라이브러리

이전까지 저는 Redux, Redux Tool Kit을 주로 사용해왔습니다. 이들을 사용하면서 느낀 점은 러닝커브가 크다는 것, action, reducer, store 등등 작성하는 코드가 많아 비효율적이다 라는 느낌을 많이 받았습니다. 그리하여 더 쉽고 강력한 라이브러리를 찾고자 합니다.

사용하는 이유

우리 서비스의 특성상 사용자의 정보를 받는 페이지가 3페이지, 상품을 등록하는 페이지가 3페이지이다. 여기서 이 정보들을 관리하려면 상태 관리가 필요하다. 또한, 사용자가 설정하는 필터 기능에서도 마지막으로 사용자가 클릭한 필터 내용을 기억할 필요가 있다. 따라서 상태 관리가 필요하다.

스토어 기반

특징

• 객체지향, 클래스 사용에 익숙하다면 그렇게 어렵지 않다.
• 필요한 변수들끼리 묶여있으므로 유지보수하기 한층 쉽다.
  종류
• Redux
  • 오직 하나의 스토어만 가지며 디버깅이 용이하다.
  • 러닝커브가 높다.
• Mobx
  • Redux에 비해 러닝커브가 낮다.
  • 스토어가 여러 개가 될 수 있는데 분리해서 사용할 수 있지만 상태 변경 시 다수의 스토어가 영향을 받을 수 있다.
  • 스토어의 데이터를 액션의 발행없이 업데이트할 수 있는데, 구현이 쉽고 용이하지만 테스트, 유지보수 측면에서 문제를 일으킬 수도 있다.
• zustand
  • 정말 쉽고 간단하다.
  • 하지만 공식 문서만으로도 자료가 부족한 것 같고 커뮤니티가 작다.

atom 기반

장점

• 쓰기 쉽다.
• 코드량이 적다.(useState 쓰는 것과 차이가 없다.)
  단점
• 적절한 규칙이 필요하다. provider로 scope을 정해두지 않으면 유지보수가 어렵다.
• 개발자 도구 지원이 이제야 생기는 중
  종류
• recoil
  • react 전용 상태 관리 라이브러리이며 React 내부 접근성이 용이하다.
  • Boiler Plate 양이 적으며(recoil 디렉토리만 필요), 사용하는 방법도 간단하여 러닝커브가 낮다.
  • 동시성 모드(Concurrent Mode)를 비롯한 다른 새로운 React의 기능들과의 호환 가능성도 갖는다.
  • 동시성 모드: 흐름이 여러 개가 존재하는 경우를 의미하며, 리액트에서 알아서 렌더링 동작의 우선순위를 정하여 적절한 때에 렌더링을 해준다는 개념
• jotai

결론

recoil을 사용하고자 합니다.
기존에 사용하던 RTK도 Redux에 비해 간단하지만 여전히 action, reducer, store를 관리해야 해서 다소 복잡하며 여전히 코드양이 많다고 생각합니다. 이를 개선하기 위해 recoil, zustand를 고려했지만 zustand의 경우 직접 사용해봤을 때, 간단한 것에 비해 docs가 부실하다는 점을 느꼈습니다. 이를 개선해보고 새로운 상태관리 라이브러리를 경험해보고자 합니다.