매주 사내 스터디를 통해 개발 관련 지식을 공유하는 시간을 가지고 있다.

컴포넌트 내에서 API를 호출하고 호출된 결과값을

Recoil에 저장해 또 다른 컴포넌트에서 가져다 쓰는 과정을 설명했다. 

그 과정에서 좋은 질문이 나왔다.

"Recoil의 장점은 전역상태에서 사용하는 것인데 크게 멀지 않은데도 (컴포넌트 트리 간의 간격이 3~4 depth 정도) Recoil을 사용하는 이유가 있나요? Context API를 사용하는 게 낫지 않나요?"

내면에서는 자연스럽게 고착된 방식으로 Recoil을 사용해왔지만 크게 고민해보지 않았던 부분이었다.

감사하게도 고민 거리를 만들어주셔서 자세히 찾아볼 수 있는 기회를 가지게 되었다.

그래서 찾아보고 정리된 생각들을 공유해보고자 한다.

 

Recoil 과 Context API 비교

먼저 간단하게 Context API와 Recoil 을 비교해보겠다.

Recoil

- 사용하기 쉬운 전역 상태관리 라이브러리

- 내부적으로 상태값의 의존성 그래프를 추적, 해당 그래프에서 변경된 부분만 리렌더링 (고효율)

Context API

- Props drilling이 이어질 수 있는 컴포넌트간의 종속성을 낮춰줄 수 있는 상태 전달 React 내장 기술

 

레퍼런스들을 통한 나의 접근

Context API 는 Recoil이 생기기 전, React 내부에서 상태 관리의 도움을 줬던 API 이다.

이 API를 통해 Props Drilling과 같은 속성 전달 복잡도를 낮췄으며, 상태를 관리하는 rule이 만들어졌다고 생각한다. 

하지만, 더욱 복잡하고 Volume이 큰 프로젝트의 경우, Context Provider가 많으면,

리렌더링 이슈가 발생할 가능성이 높다.

Provider에 묶인 많은 상태들은 어디서 리렌더링이 발생하는지 어려울 수 있으며,

여러 Provider들이 부모 자식 관계를 만들고 있다면 내부 컴포넌트들은

말그대로 Component의 역할을 제대로 수행하지 못할 수 있다.

해당 비즈니스 로직에만 종속되어 사용될 것이다. 게다가 복잡도는 더욱 올라간다. 

즉, 관리하기 위해 사용한 API가 관리 비용이 더 들어가는 경우가 생기는 것이다. 

Recoil은 Context API가 가진 단점을 해결하고 관리비용을 줄였다. 사용하기 위해선 어떤 boilerplate도 필요없으며, 간단 명료하다.

key값을 가지고 해당 key값을 가진 상태를 직접적으로 바라보기 때문에 복잡해지지 않는다.

여러 상태들을 협업에 편리하도록 atom들을 잘 분리해주고 사용해주면 된다. 

현재 업무에서는 Context API는 연관성 높은 함수들 (ex. API 호출 함수 더미)을 한 Provider에 묶어 담아

호출하여 사용하는데 주안을 두고 있고, Recoil은 Component 간의 상태 전달을 위한 용도로 사용하고 있다. 

이렇게 조합해서 사용할 때 효과적인 것 같다.

 

다른 접근

상태관리를 History 적으로 접근하면 "진화"해온 것이다. 

(props 직접 전달 -> Context API -> 외부 상태관리 라이브러리)

또한, 우리는 Recoil과 Context API를 왜 사용하는 지부터 접근해야 한다.

Props Drilling이 심하다면, 상태관리 API 를 사용할 것이 아니라, 왜 Props Drilling이 심한 지, 

컴포넌트 구조, 아키텍쳐 설계가 잘못되지 않았는 지를 점검하고 개선해 나가야 한다. 

리액트의 철학 중 하나는 '모든 것이 컴포넌트다'입니다. 이는 UI를 작은 조각으로 나누고, 각 조각을 독립적인 컴포넌트로 만들어 재사용하고 조합하는 것을 의미합니다. 이렇게 함으로써 코드의 재사용성을 높이고 유지 보수를 용이하게 합니다.결국, 리액트에서는 상속보다는 컴포넌트의 조합을 통해 코드의 재사용성과 유지보수성을 높이는 것을 추천하고 있습니다. 이는 리액트의 철학인 '컴포넌트화'와 '단방향 데이터 흐름'을 지키는 방향과도 일치합니다. (from Chat GPT)

명확한 근거와 이유없이 아이템들을 남발하여 사용하기 보단 신중하게 도입하는 것이 중요한 것 같다.