[React] Recoil 톺아보기

Recoil의 등장배경

Recoil 등장 배경에 대한 이해를 돕기 위해 Props Drilling 과Context API 이라는 것이 무엇인지 먼저 알아보자.

Props Drilling이란?

리액트는 단방향의 흐름을 가진다.

위 그림과 같이 상위 컴포넌트의 state를 하위 컴포넌트의 props로 내려주고, 그 props를 또 다시 하위 컴포넌트에 넘겨주는 방식으로 데이터를 전달한다.

이 과정에서 A 컴포넌트의 동작 자체 필요한 props가 아니더라도 B 컴포넌트에게 전달하기 위한 목적만으로 A 컴포넌트는 상위 컴포넌트의 state를 props로 받아와야하는 상황이 발생할 수 있다.
이러한 상황을 Props Drilling이라고 부른다.

function UserList({ users, onRemove, onToggle }) {
  return (
    <div>
      {users.map(user => (
        <User
          user={user}
          key={user.id}
          onRemove={onRemove}
          onToggle={onToggle}
        />
      ))}
    </div>
  );
}

상기한 예시 코드를 보면 UserList에서 users, onRemove,onToggle을 전달하는 다리에 불과하다. 직접 해당
props들을 이용하는 경우도 없고, 그저 자식 컴포넌트에 props를 넘겨주기만 한다.

단순히 3개 정도의 컴포넌트 사이에서는 이러한 상황이 크게 문제가 되지 않지만, 애플리케이션이 성장하며 여러 계층의 컴포넌트가 만들어진 상태에서 Props Drilling 이 발생하게 되면 여러 문제가 발생할 수 있다.

대표적으로

• 이 과정에서 컴포넌트 A와 C에서만 필요한 데이터를 B-C로 전달하면서 컴포넌트 B에서 불필요한 리렌더링이 발생할 수 있고
• A-B-C 컴포넌트 순으로 props를 전달했는데 B-C에서 전달하는 props의 이름을 변경한다면 C에서 문제가 생겼을 때 해당 Props가 어디에서부터 온 건지 추적하기가 힘들어지기도 한다.

Context란?

리액트 컴포넌트에서 별도의 props를 내려주지 않더라도 Context 하위 컴포넌트들이 value로 넣어준 값을 useContext를 통해 사용할 수 있는 일종의 상태관리 API로, Props Drilling을 문제점을 해결할 수 있는 방법 중 하나이다.

Context는 간단하게 다음과 같이 사용한다.

//✅ createContext 함수를 불러와서 context를 생성하고 
import {createContext} from 'react';
const MyContext = creatreContext();

//✅  Context 객체 내 Provider라는 컴포넌트를 이용해 컴포넌트 간 공유하고자 하는 값을 value 라는 Props로 설정한다. 
function App() {
  return (
    <MyContext.Provider value="Hello World">
    	<Children />
	</MyContext.Provider>
  );
}

//✅ value에서 공유된 state를 쓰고 싶은 컴포넌트에서 useContext를 선언하여 state를 꺼내 사용한다.
import {useContext} from 'react';
function Message() {
  const value = useContext(MyContext);
  return <div>Received: {value}</div>;
}

만약 Props를 이용한다면?

만약 props를 이용해서 최하단 컴포넌트까지 props를 전달한다면다음과 같이 최하단 컴포넌트에서만 props2를 사용함에도 B,C와 같은 상위 컴포넌트에서 불필요한 리렌더링이 발생할 것이다.

Context를 이용한다면?

하지만 Context 를 사용한다면 다음과 같은 구조가 될 것이다.

context가 필요한 컴포넌트에서만 C와 같은 중간 컴포넌트를 건너뛰고 바로 대상으로 하는 컴포넌트로 데이터를 전달할 수 있어 불필요한 리렌더링이 사라진다.

본 글은 Recoil을 알아보는 것이 주목적이기에 Context에 대한 더 깊은 이해는 다른 사람들이 안 알려주는 리액트에서 Context API 잘 쓰는 방법을 참고보면 좋겠다.

하지만 Context에도 한계는 있다.

Context 역시 내부의 state가 갱신되면 하위 컴포넌트들이 전부 렌더링되는, 리액트 컴포넌트의 룰을 벗어나지 않기 때문에 불필요한 리렌더링을 완전히 피할 수는 없다. React.Memo 등으로 최적화를 할 수도 있지만, 모든 최적화는 결국 적지 않은 비용이기에 최우선으로 고려할 내용은 아니다.

$\rightarrow$ 복잡한 컴포넌트 구조를 가신 어플리케이션에서는 Context API가 Props Drilling에 대한 완벽한 해답이 되지 않는다.

---

그렇게 등장한 상태관리 라이브러리

이에 따라 mobx, redux, recoil 과 같은 상태관리 라이브러리들이 등장하기 시작했다.

각 상태관리 라이브러리 간단히 비교하기

1. redux
   • redux-saga, redux-thunk, redux-devtools와 같은 추가 기능을 제공하는 라이브러리를 사용할 수 있다.
   • 작은 상태 하나를 변경하려고 해도, actions, reducer, type 등 보일러 플레이트 코드를 많이 작성해야 하는 번거로움이 있고, 작성하는 코드의 양이 많아진다.
   • 긴 역사를 자랑하는 만큼 안정성이 어느 정도 보장된다.

2. mobx
   • React 뿐만 아니라 Vanilla JS나 Angular, Vue와 같은 프레임워크에서도 사용 가능
   • 보일러 플레이트 코드 등 작성할 것이 많은 Redux에 비해 가볍다.
   • 클래스형 컴포넌트를 기준으로 만들어져 객체 지향 프로그래밍 방식으로 코드를 작성할 수 있다. 이 때문에 Mobx와 리액트의 함수형 컴포넌트의 Hooks를 함께 사용하면 오류가 발생할 수 있다.

3. recoil
   • React의 라이브러리가 아니기 때문에 React 내부 스케쥴러에 접근이 어려운 mobx, redux와 달리 Recoil을 만든 Facebook에서 발표한 리액트 전용 상태관리 라이브러리이다.
   • 동시성 모드와 suspense의 제공을 통해 렌더링을 인터럽트 가능하도록 만들어 최적의 UX를 제공한다. (참고자료)
     • 동시성 모드 제공 : React가 각 컴포넌트에서 실행되는 비동기 요청 등을 보고 판단하여 렌더링 우선 순위를 정해 렌더링 최적화를 하는 모드. 렌더링 될 준비가 완료되어야 렌더링을 시작한다.
     • Suspense: 컴포넌트가 렌더링 될 준비가 되지 않으면 렌더링을 하지 않고 suspense 상태로 둔다. 아래와 같이 fallback 속성을 전달하면 대신 렌더링 할 컴포넌트를 지정할 수 있다.

Recoil vs Redux

최근 6개월 간의 recoil과 redux의 npm 다운로드 수를 비교한 자료이다.

긴 역사를 가지고, devtool을 제공하며 큰 커뮤니티를 가진 redux의 사용이 아직도 압도적인 것이 사실이지만, API와 의미 및 동작을 가능한 React답게 유지한 Recoil에 대한 선호도도 꾸준히 유지되고 있다.

이 Recoil의 사용에 대해 조금 더 톺아보자.

왜, Recoil?

Recoil 공식문서 에서는 Recoil이 등장하게 된 동기를 다음과 같이 서술하고 있다.

1. React 컴포넌트의 상태는 공통된 상위요소까지 끌어올려야만 공유될 수 있으며, 이 과정에서 거대한 트리가 다시 렌더링 되는 효과를 야기하기도 한다.
   $\rightarrow$ 위에서 살펴본 Props Drilling을 언급하고 있다.

2. Context는 단일 값만 저장할 수 있으며, 자체 소비자(consumer)를 가지는 여러 값의 집합을 담을 수는 없다.
   $\rightarrow$ Context 섹션에서 살펴본 것처럼 context1: "new"와 같이 하나의 Context에서는 단일값(숫자, 문자열, 객체 등)만 저장할 수 있는데, recoil에서는 뒤에서 살펴볼 atom이라는 개념을 통해 이 한계를 해결하였다.

3. 이 두 가지 특성이 트리의 최상단(state가 존재하는 곳)부터 트리의 말단(state가 사용되는 곳)까지의 코드 분할을 어렵게 한다.

---

Recoil, 어떻게 사용할까?

Recoil에는 크게 Atoms, Selector 이렇게 두 가지 핵심 개념이 존재한다.
Recoil은 이 둘 개념을 이용해 atoms (공유 상태)에서 selectors (순수 함수)를 거쳐 React 컴포넌트로 내려가는 data-flow graph를 만들어 상태를 관리한다.

Atoms

Atoms는 상태의 단위이며, 업데이트와 구독이 가능하다.
atom이 업데이트되면 각각 구독된 컴포넌트는 새로운 값을 반영하여 다시 렌더링 된다.
Atoms는 React의 로컬 컴포넌트의 상태 대신 사용할 수 있다.
동일한 atom이 여러 컴포넌트에서 사용되는 경우 모든 컴포넌트는 상태를 공유한다.
-Recoil 공식문서-

Facebook에서 Recoil을 소개한 영상에 등장하는 그림이다.
상단 1,2,3,4,5,6이 atom 이며 하단 Web 에서 atom을 가져다 사용하고 있다.

atom은 하나의 상태로, 컴포넌트가 구독할 수 있는 react state라고 생각하면 되는데, 개인적으로는 전역 상태를 담고 있는 저장소 정도로 이해했던 것 같다.
각각의 atom은 필수적으로 key, default를 가지는데 각각 다음과 같다.

• key : 내부적으로 atom을 식별하는데 사용되는 고유한 문자열로, 해당 atom을 필요로 하는 컴포넌트에서는 이 key를 이용해 atom 내 데이터를 가져온다. 그렇기에 Atoms은 App 전체에서 다른 Atom과 Selector와 구분되는 Unique한 Key값을 가져야한다.
• Default : atom에 지정해주는 초깃값이다.
  

// ✅ atom() 함수를 호출해 atom을 생성한다. 
const counter = atom({
  key: 'myCounter',
  default: 0,
});

atom에 옵션으로 effects_UNSTABLE 과 dangerouslyAllowMutability 을 넣어줄 수도 있다.

• effects_UNSTABLE : atom을 위한 선택적인 Atom Effects 배열인데, Atom Effects는 부수효과를 관리하고 Recoil의 atom을 초기화 또는 동기화하기 위한 API이다. 상태 지속성, 상태 동기화, 히스토리 관리와 같은 다양한 옵션이 있으니 참고해보면 좋겠다.
• dangerouslyAllowMutability : boolean값으로,Recoil 상태값을 불변성을 지키지 않는 방식으로 업데이트할 수 있게 한다.

dangerouslyAllowMutability 보충설명

Recoil 상태를 수정할 때 일반적으로는 set 메서드를 사용하고, 이때 set 메서드는 이전 상태를 복사하고, 이전 상태와 새로운 값을 결합하여 새로운 상태를 생성한다.
이렇게 함으로써 Recoil 상태의 불변성을 유지하고, 상태 업데이트를 안전하게 처리한다.

하지만 dangerouslyAllowMutability 옵션을 사용하면, 이전 상태를 복사하지 않고 직접 수정할 수 있다.
이는 상태 업데이트를 더 빠르게 처리할 수 있게 해주지만, 상태 불변성을 깨뜨리는 위험성이 있다.

그렇기 때문에 Recoil의 성능을 높이기 위해 사용할 수는 있지만, 일반적으로는 안정성을 위해 dangerouslyAllowMutability 옵션을 사용하지 않고, 불변성을 유지하는 방식으로 상태를 업데이트하는 것이 좋다.

---

Selector

Selector는 atoms나 다른 selectors를 입력으로 받아들이는 순수 함수(pure function)다.
상위의 atoms 또는 selectors가 업데이트되면 하위의 selector 함수도 다시 실행된다.
컴포넌트들은 selectors를 atoms처럼 구독할 수 있으며 selectors가 변경되면 컴포넌트들도 다시 렌더링 된다.
-Recoil 공식문서-

처음 recoil을 사용할 때 공식 문서의 해당 부분을 보고 atom을 set 메서드를 사용해서 업데이트 시키는 것과 Selector를 사용하는 것의 차이를 이해하기가 어려웠다.

사용을 해보며 이해한 내용은 다음과 같다.

💡 atom은 단순히 상태를 저장하고 업데이트하는 데 사용되지만, selector는 상태를 파생시켜서 계산하는 데 사용된다. 즉, selector를 사용하면 상태 값을 다른 상태 값을 기반으로 동적으로 계산할 수 있다.

예를 들어 투두리스트를 하나 만든다고 가정해보자.

const todoListState = atom({
  key: 'todoListState',
  default: [],
});

atom에는 다음과 같이 todoList의 상태, 즉 투두리스트의 항목들을 저장한다.

export const todoListStatsSelector = selector({
  key: 'todoListStatsSelector',
  get: ({ get }) => {
    const todoList = get(todoListState);
    const totalNum = todoList.length;
    const totalCompletedNum = todoList.filter((item) => item.isComplete).length;

    return {
      totalNum,
      totalCompletedNum,
    };
  },
});

그리고 만약 투두 항목의 전체 개수, 혹은 완료되 투두의 개수를 세고 싶다면, todoListState(atom)을 입력으로 받아들여 연산을 실행하여 반환할 수 있다.

그리고 이 연산 결과를 이용하고 싶은 컴포넌트에서

const { totalNum, totalCompletedNum } = useRecoilValue(todoListStatsSelector);

다음과 같이 받아와 사용할 수 있는 것이다.

즉, atom은 단순히 데이터를 담고 있는 저장소의 역할을 하는 것이고 그 데이터를 가공하는 것은 selector가 한다고 이해할 수 있을 것이다.

---

Example

필자가 프론트엔드 개발에 참여한 Pic.me에서 팀원이 작성한 코드를 예시로 들어보겠다.

Pic.me에서는 유저가 사진 2장을 업로드하고 해당 사진에 익명 투표를 받는 형식인데, 투표 결과를 보여주거나 투표 현황을 보여주는 등 유저가 첨부한 사진을 많은 컴포넌트에서 필요로 하기에 효율적으로 관리하기 위해 Recoil을 사용했다.

먼저 atom.ts 에 유저가 사진을 첨부하기 전 해당 정보를 필요한 컴포넌트에서 참조할 수 있도록 atom에 참조할 수 있는 unique한 key와 초깃값을 저장한다.

//✅ 새로고침, 혹은 페이지가 변경되더라도 상태관리를 유지하기 위해 persistAtom을 옵션으로 넣어주었다. (새로고침해도 첨부한 사진이 그대로 화면에 보인다.)
const { persistAtom } = recoilPersist();

export const votingImageState = atom<VotingImageInfo>({
  key: 'votingImage',
  default: {
    title: '',
    imageUrl: [],
  },
   effects_UNSTABLE: [persistAtom],
});

그리고 유저가 사진을 첨부하면 useRecoilState 를 이용해 유저가 첨부한 사진 정보를 atom - votingImageState에 업데이트한다.

const [votingForm, setVotingForm] = useRecoilState(votingImageState);
...
//✅ setVotingForm을 통해 유저가 첨부한 사진 url 값을 담아 atom 값을 변경한다. 
setVotingForm({ ...votingForm, imageUrl: copyImageForm });

또한 Selector를 사용한 경우를 살펴보자.

첨부한 사진으로 투표를 생성한 유저에게 투표가 종료된 후 사진에 부착된 스티커의 총 개수를 보여주려고 한다.

먼저 atom에 stickerResultState를 선언해 유저가 부착한 스티커 정보를 담는다.
상기한 예시처럼 set 메서드를 통해 업데이트된 atom은 다음과 같을 것이다.

export const stickerResultState = atom<StickerResultInfo[]>({
  key: 'stickerResult',
  default: [
    {
      stickerLocation: [{10,10}, {20,20}], // ☑️ 스티커 좌표 정보
      emoji: 1, // ☑️ 몇 번 스티커인지
      count: 2, // ☑️ 총 몇개의 스티커가 부착되었는지 
    },
     {
      stickerLocation: [{30,10}, {50,50}], // ☑️ 스티커 좌표 정보
      emoji: 3, // ☑️ 몇 번 스티커인지
      count: 5, // ☑️ 총 몇개의 스티커가 부착되었는지 
    },
  ],
  effects_UNSTABLE: [persistAtom],
});

그리고 유저에게 총 스티커 개수를 보여주기 위해 연산을 수행하는 selector 함수를 만든다.

export const stickerCountSelector = selector({
  key: 'stickerCountSelector',
  get: ({ get }) =>
  //✅ reduce 함수를 이용하여 currentStickerResult의 각 요소에서 count 속성만 더해 합계를 내준다. 
    get(stickerResultState).reduce((accumulator, currentStickerResult) => accumulator + currentStickerResult.count, 0),
});

다음과 같이 리턴값을 가져와 총 합계를 보여줄 수 있다.

  const stickerResultCount = useRecoilValue(stickerCountSelector);
...

 <StFirstReason>{stickerResult.length ? stickerResultCount : 0}표</StFirstReason>

---

마치며

Recoil을 공부하다 보니 확실히 상태 관리 라이브러리를 사용하여 전역 상태를 관리하는 것이 확실히 편리하다는 생각이 들었다.

하지만 이렇게 편리하다고 해서 상태관리에 대한 큰 고민 없이, 혹은 자식에서 부모로, 즉 역방향으로 데이터를 업데이트 해줘야만 하는 상황에서 바로 상태관리 라이브러리를 쓰는 태도가 옳은 태도일까?

실제로 Pic.me 개발 당시 자식 component에서 부모 component의 state를 바꿔야 하는 상황이 왔을 때 Recoil 사용을 고려했지만, 결국에는 자식에게 부모의 state를 modify 할 수 있는 setState 함수를 props로 넘겨주는 방식으로 해결한 경험이 있다.

해당 기능의 depth가 깊지 않았기에 할 수 있었던 방법이었지만, 그때 든 생각은 어떤 기술이든지 그 기술을 사용하는 상황에서 "왜?"에 대한 고민이 필요하다는 것이었다.

Recoil이 React 친화적으로 조금 더 편리하다고 느끼는 사람도 있겠지만, 상황에 따라, 그리고 서비스의 규모에 따라 Redux가 더 적합한 상황이 올 수도 있다. (보일러플레이트 문제에도 불구하고 국내 많은 대기업에서 redux를 사용하고 있다고 한다. devtools의 제공이 무시할 수 없는 원인이라고.)

따라서 Recoil을 사용할 때에도 충분한 고려와 다른 상태관리 라이브러리들과의 비교를 통해 스택 도입을 결정짓는 태도를 가지는 것이 좋겠다.

---

참고자료

리코일 공식 문서
다른 사람들이 안 알려주는 리액트에서 Context API 잘 쓰는 방법
props drilling과 context
Recoil, 리액트의 상태관리 라이브러리