Redux vs Recoil
저번에 상태관리 방법에 대해서 Redux 와 Context API 둘을 비교 해보았다.
결과는 Redux의 승리..
현재 과업으로 맡은 admin 페이지는 기능면에서 규모가 작지만,
앞으로 기능이 추가될 가능성이 열려있어서 무겁지만 확실한 상태관리 라이브러리를 사용하기로 하였다.
여기서 또 새로운 선택자가 나타났는데, 바로 Recoil이다.
이 둘을 비교해보며 최종 결정을 내리기로 했다.
Recoil
Recoil은 페이스북에서 만든 Context API 기반으로 구현된 함수형 컴포넌트에서만 사용 가능한 상태관리 라이브러리이다.
Recoil의 특성 (Redux와 차이점)
- Recoil은 배우기 쉽다.(Redux처럼 복잡하지 않다.)
기존 React 내장 Hooks의 사용하는 방식과 크게 다르지 않고 유사하기 때문이다.
Recoil을 시작하기 위해서는 어플리케이션을RecoilRoot로 감싸고 데이터를atom이라는 단위로 선언하여
useState를 Recoil의useRecoilState로 대체해야 한다.
atom: 작은 단위로 컴포넌트들이 구독할 수 있는 단위selector: 동기적/비동기적 상태를 변환
- 컴포넌트가 사용하는 데이터 조각만 사용할 수 있고, 계산된 selection를 선언할 수 있으며,
비동기 데이터 흐름을 위한 내장 솔루션까지 제공한다.
동적 키로atom을 만들고,selector에 인자를 보내는 등 모두 간단하게 할 수 있다.
Redux에서는 비동기 처리 라이브러리에 따로 의존 하였지만, Recoil에는 내장 되어있다.
-
일반적인 Redux
action
reducer
store 상태 변화 -
Redux Saga(비동기 처리 라이브러리)
데이터를 요청하는 action
saga가 action에 맞는 제너레이터 함수를 실행
제너레이터 함수에서 또 다른 reducer를 실행
이 reducer에 따른 store 상태 변화
Redux는 추가적인 라이브러리 설치로 인해 프로젝트 번들이 더 무거워진다.
Recoil의 selector를 활용하면 쉽게 비동기 데이터를 가져올 수 있다.
결론
나는 Recoil을 사용해보기로 하였다.
첫 번째로 Recoil을 알아봤을 때, Redux에 비해 가장 크게 느낀 장점은 비동기 처리를 할 때에
Redux는 Redux saga나 Redux Thunk 미들웨어를 추가로 설치해서 사용해아하는데
Recoil은 그 라이브러리 내부에 이미 기능이 갖춰져있어서 하나의 라이브러리로 핸들링이 가능한 점이다.
두 번째로 페이스북에서 만든 React 전용 라이브러리다 보니,
사용법이 React Hooks와 거의 동일하고 사용하는데 필요한 코드가 좀 더 간단하다.
다른 블로그를 보았을 때, 같은 규모의 상태 관리에 대해서 작성되는 코드가 Recoil이 현저히 적었다.
세 번째로 React 전용 상태관리 라이브러리인점.(react-redux도 있지만은)
라이브러리의 소스코드가 좀 더 React 친화적일 것 같은 느낌이 들었다.
