recoil 정리

react 에서 기본적으로 제공하는 전역 state 관리 도구이다.

redux 에 비해 보일러 플레이트가 현저히 줄어들었다. 상태 관리 뿐만 아니라, 메모이제이션 지원 및 컴포넌트 의존성을 줄이기 위한 reselect 역할과 외부 부수효과를 비동기적으로 다루기 위한 redux saga 같은 redux 미들웨어 기능도 겸한다.

개념 정리

atom

react hooks 의 useState 처럼 사용 가능하지만, state 를 <RecoilRoot> 가 감싼 범위 내에서 전역적으로 사용이 가능하다.

selector

reselect 의 selector 처럼 초기값으로 설정된 atom 에서 필요한 값만 선택하는 것도 가능하고,

인자로 전달하는 오브젝트의 get 키워드에 할당하는 함수 내부에 외부 부수효과를 다루는 비동기 처리도 가능하다.

알아두어야 할 점은, atom 기반의 selector 가 아니라 외부 부수효과로 state 를 갱신하는 selector 라면

초기값이 없기 때문에 비동기 작업이 완료될 때까지 state 가 존재하지 않는 상태가 된다.

이걸 그대로 사용하면 에러가 발생해서 react 의 실험적 명세인 <Suspense> 등으로 컴포넌트를 감싸주어야 한다.

사용 후기

장점

일단 react hooks 에 익숙하고 react hooks 기반으로 코드를 작성했다면 migration 과정도 매우 쉽다.

단 migration 작업을 그냥 그대로 진행하면 selector 가 많이 늘어나서 불필요한 코드량이 늘어날 수 있다.

특별히 복잡한 것도 없고, 현재 공식 문서가 약간 부실한 편이지만 api 문서의 타입 설정을 보고 조금만 실험해보면 원하는 대로 동작할 수 있게 코드 작성이 가능하다.

테스트

테스트 작성을 최근 대세로 자리잡은 듯한 testing-library 로 작성했다면 컴포넌트 렌더링 때에 초기값 설정 및 <RecoilRoot> 으로 감싸주는 작업만 잊지 않으면 기존에 작성한 테스트를 그대로 사용 가능하다.

하지만 selector 가 외부 부수효과를 비동기 작업으로 처리한다는 점을 고려해보면 이런 작업만 따로 테스트가 가능하도록 별도로 분리해주면 좋겠다는 생각이 든다. redux-saga-test-plan 같은 형태로.

아쉬운 점

일단 공식문서가 정말 뭐가 없다. 그만큼 직관적이고 딱 필요한 것만 있기 때문이긴 해도.

그리고 redux 의 강점은 redux 에 특화된 이런저런 개발 보조도구인데 그것들을 전부 포기해야 한다는 점이 많이 아쉽다.

하지만 이 부분은 recoil 을 전폭적으로 페이스북에서 밀어준다면 시간이 해결해줄 부분이라고 생각한다.

개인적으로 react hooks 가 등장한 이후로 모든 컴포넌트를 함수 컴포넌트로만 작업하는 분위기를 별로 좋아하지 않는데,

recoil 이 그런 경향을 가속화할 것이라는 우려도 생긴다.