TL;DR : 캔버스나 GUI 같은 앱이 아니면 딱히 필요하지 않다.
프로젝트 초반에 리코일을 도입하기 위한 리서치를 진행하다 어쩌다보니 사용하지 않고 있는데요.
사실 생각보다 원하는대로 쓰기 어렵다는 것 외에도 (뒤에 이유를 설명합니다.)
전역 상태 관리 도구로서 에측하지 못한 하나의 단점이 있는데요.
반드시 데이터가 리액트 컴포넌트 내부에 존재해야 한다는 것입니다.
생각보다 개발하다보면 마이크로 최적화를 위해 렌더링 없이 상태 참조가 필요한 경우가 왕왕 있습니다.
(useRecoilCallback을 활용할 수도 있지만, useCallback과 같은 문제가 있습니다.)
https://recoiljs.org/docs/api-reference/core/useRecoilCallback/
물론 ms단위의 미묘한 최적화지만, 종이에라도 1000번 베이면 죽을수도 있습니다.
이에 관련하여 zustand/ jotai/ valtio 개발자인 다이시 카토상이 다른 주제로 올린 게시물의 이미지를 첨부합니다.
컴포넌트 중심 애플리케이션 vs 데이터 중심 애플리케이션
컴포넌트 중심 접근 방식에서는 컴포넌트를 먼저 설계합니다.
일부 상태는 useState를 사용하여 컴포넌트에서 로컬로 정의할 수 있습니다.
전역 상태는 컴포넌트 간에 공유됩니다.
예를 들어 GUI 집약적 앱에서 동기화된 UI 부분을 제어하고 싶지만, 각 컴포넌트가 컴포넌트 트리에서 멀리 떨어져 있는 경우 도움이 됩니다.
이럴 경우 리코일이 큰 도움이 됩니다.
개인 의견 정리
리덕스나 zustand같은 데이터 중심 상태관리 라이브러리의 가장 큰 장점은
비즈니스 로직을 리액트 컴포넌트에서 분리할 수 있다는 것이라고 생각합니다.
더욱이 리덕스나 zustand는 리액트와 상관 없이 모든 라이브러리/프레임워크에서 사용 가능합니다.
jotai와 recoil은 해결하고자 하는 문제가 문제인 만큼 리액트와 착 붙어서 동작합니다.
리코일은 상태 업데이트와 조회가 set, get으로 간단하지만,
여러 스토어를 오케스트레이션하는 비즈니스 로직을 구현한다면 가면 갈수록 골치 아파집니다.
그리고 리액트 쿼리와 같이 우선하는 상태관리 도구가 존재할 경우, 동기화 하는것도 애매합니다.
솔직히 말하면 잘 쓰는 방법을 잘 모르겠습니다.
GUI 앱이더라도 비즈니스 로직이 좀만 복잡해지면 좋은 솔루션이라고 하기 어려워집니다.
Jotai 개발자인 다이시 카토 상도 자기가 구현한 로직이 이해하기 쉬운지에 대해 확신하기 어렵다 하더군요
(카토상은 도쿄공과대학 컴공 학석사인 수재입니다)
https://blog.axlight.com/posts/learning-react-state-manager-jotai-with-7guis-tasks/
Learning React State Manager Jotai With 7GUIS Tasks
Introduction I stumbled upon 7GUIS tasks while reading XState Tutorials. This motivated me to challenge those 7 tasks with jotai. It turned out that this would be a good resource to learn jotai. They are from basic tasks to advanced tasked, and you will se
blog.axlight.com
그리고 Jotai와 Recoil 합친것보다 zustand를 많이쓰며 성장세 마저도 밀리고 있습니다.
https://npmtrends.com/jotai-vs-recoil-vs-zustand
jotai vs recoil vs zustand | npm trends
Comparing trends for jotai 1.7.5 which has 129,373 weekly downloads and unknown number of GitHub stars vs. recoil 0.7.4 which has 270,471 weekly downloads and unknown number of GitHub stars vs. zustand 4.0.0-rc.1 which has 585,156 weekly downloads and unkn
npmtrends.com
리액트 쿼리 개발자인 tanner Linsley는 어떻게 생각할까요?
https://mobile.twitter.com/tannerlinsley/status/1293653425968701440
트위터에서 즐기는 Tanner Linsley
“@ee0pdt Recoil is... interesting. Probably. not necessary for a vast majority of apps. Unless you're experiencing the class of parallel-update/subscription issues that they talk about in the video on recoil's home page, you probably don't need it.”
twitter.com
리코일은 흥미롭지만, 공식 홈페이지의 리코일 소개 영상에서 나오는 문제를 해결하는 경우가 아닌 이상 필요하지 않을 것입니다.
우리의 오랜 좋은 친구인 redux(toolkit)이나 selector 기반 라이브러리를 잘 활용하는게 나을 수도 있겠네요.
저는 추가로 프록시 기반 라이브러리들을 좀 더 조사해 볼 예정입니다.
참고
https://blog.axlight.com/posts/when-i-use-valtio-and-when-i-use-jotai/
When I Use Valtio and When I Use Jotai
Introduction Recently, I often got asked about this question: Which is recommended, valtio or jotai? For those who are not familiar with them, they are two out of many state management libraries that I developed. https://github.com/pmndrs/valtio https://gi
blog.axlight.com
'FrontEnd' 카테고리의 다른 글
| Valtio의 프록시 상태관리가 어떻게 동작할까? (React Part) (1) | 2022.07.18 |
|---|---|
| Valtio의 프록시 상태관리가 어떻게 동작할까? (Vanila Part) (0) | 2022.07.18 |
| 리액트 훅의 클로저 트랩(closure trap) 이해하기 (0) | 2022.07.17 |
| 리액트에 SOLID 원칙 적용하기 (0) | 2022.07.17 |
| 리액트 쿼리 : FAQ(자주 묻는 질문) (2) | 2022.07.17 |
