recoil과의 첫 만남

김민찬·2022년 5월 29일
0

Recoil

목록 보기
1/2
post-thumbnail

Recoil을 만나다.

회사에서 전역 상태관리로 redux, 각 위젯의 props drilling을 피하기 위해서 Context API로 진행하다가 Context API 대신 Recoil을 도입하기로 했다.

주 이유는 다음과 같이 두 가지 이다.

  1. Context API에서 상태값을 변경하면, provider로 감싼 모든 자식 컴포넌트들이 리렌더링 한다. (이를 해결하기 위해서는 많은 보일러플레이트 코드가 필요하다.)
  2. 페이스북에서 공식적으로 개발해서, 차후지원과 React와의 연계성을 기대할 수 있다. React의 문법과 비슷하다는 것도 큰 장점이다.

우리 팀에서 중심적으로 고민한 문제는 key에 대한 것이다.

협업을 하다보면 함수등의 이름이 겹치는 현상을 자주 볼 수 있다.

위와 같은 이유로 component 밖에 let을 선언하지 말라.라는 제로초의 강의도 있다.

그러면 Recoil에서 key는 어떻게 관리해야 될까라는 고민을 하게되었다.
Recoil의 atomselector에는 key가 존재하는데 이는 모든 atomselecotrkey들과 겹치면 안되고 고유 해야한다.
그러지 않으면 다음과 같은 오류를 만나게 된다

우리팀에서 생각한 방법은 두 가지이다.

  1. key를 겹치지 않고 랜덤생성
  2. object 형식으로 한 파일에서 관리하기

결론 부터 말하자면 2번째 방법을 선택했다.
1번 문제는 recoil dev tools에서 key를 이용해서 어떤 atom인지 구분을 한다고 들었기 때문에, 디버깅에 불편함이 존재할 수도 있기 때문이었다.
(그런데 recoil dev tools는 2020년 이후 제대로 된 업데이트를 하지 않았고, 내가 간단한 프로젝트 recoil 프로젝트를 만들었는데도, 빈화면으로 작동하지도 않았다.)

key를 한 파일에서 관리하기

이 방식은 회사 대리님의 아이디어로, object의 key가 같은 이름으로 두 개를 만들 수 없다는 방식을 차용했다.
2번째 방법으로 사용한 것은 한 파일에서 우선 object를 만들었다.

import { getnerateKey } from './index';

export const recoilKey = {
	counter: {
      count: '',
    },
  	todo: {
      list: '',
    }
};

generateKey('key', recoilKey);

export default recoilKey;

위와 같이 Recoil의 key를 만들고 generateKey라는 함수를 만들어서 그 object의 key를 string 형태로 변환하는 방법이다.

이 key 관리법은 아직 실험적인 방법으로 추후에 변화가 있을 수도 있다.

아직 Recoil의 사용자 풀이 적고, unStable한 라이브러리라, 더 많은 연구가 필요할 것 같다.

profile
두려움 없이

0개의 댓글