본의아니게 Recoil코드를 뜯어보고있는데..
지금은 잡초만 무성한 프로젝트 되었지만..
jotai같은 비슷한 프로젝트에 비해서 확실히 근본 철학이 있음.
jotai가 부족하기보단 jotai는 단순 반응형 primtive를 만드는것에 집중해서 확장성에 집중했다면..
Recoil은 설계목표가 분명히 있고, 그 목표에 아니게 쓰는애들은 다 금지시켜버리는것 같은 선택을 함.
리액트 컴포넌트(혹은 랜더러)의 동작 방식과 비슷하게
리코일 상태 트리 데이터도 융화되게 하고 싶었던 것 같은데
이거 잘만 했으면 리액트 버전 Signal은 이쪽이 재패했을 수 도 있지 않았을까 싶기도 함.
근데 jotai가 유틸이 쓸만한게 많아서 약팔기 참 쉬운것도 있지... ㅋㅋ
리코일 조타이 둘 다 아톰 컨셉일건데 리코일이 아빠
둘다 atom컨셉은 비슷한데 중요한건 그게 아님. jotai는 atom 하나로만 다 퉁치고 recoil은 괜히 selector를 별도로 만드는게 아니야
리코일의 selector 컨셉과 캐시를 다루는 방법이 굉장히 흥미로움
두 프로젝트는 겉보기에는 굉장히 비슷한데 내부적으론 좀 많이 다름.
글쿠나 난 조타이 안써보고 리코일이랑 주스탠드만 써봄
리코일의 근본 철학이라니 궁금하네. 내 주변에서는 그냥 문법이 state랑 비슷하고 별로 세팅할 거 없어서 쓴다는 말만 많았는데
그냥 jotai랑 비슷한 분산형에 결합형 상태관리라 생각했는데 아닌가봐?
내가 너무 모호하게 썼네. 일단 atom을 가지고 state를 변경한다는건 님이 알고있는게 맞음. 근데 selector(캐시)를 관리하는 방법이 React 랜더러가 컴포넌트를 관리하는 방식과 매우 유사함. 보통 atomic state중에 이렇게 캐시관리에 진심인 라이브러리는 본적이 없음. (그냥 '반응형'에만 집중한건 많아도)
내부적으로 selector 캐시를 관리하는 전략이 다양하게 있고, 트리를 그리거나, 아니면 외부 props에 의존하거나 하는 등의 여러가지 방법론들이 제공됨. 그리고 그 정의에 위배되는 행동은 다 throw error 시켜버리고. 그에 비해 jotai는 그런 제약은 없음. 어처피 반응형만 달성하면 되는거라서.. 이런게 정말 큰 설계상의 차이인듯
근데 얘들이 이런걸 문서에 안써놨음. 너무 내부적인 기능이라 그런가? 쩃든 코드 까봐서 알게된 내용이라 신기했다 이말
그런 라이브러리 내부 로직은 문서화 안하거나 해도 따로 파놓은 고급 코스에 대충 써둠. 보통 사용자 인터페이스단에서 필요한것만 써놔도 문서가 기니깐
근데 다 layoff당하니뮤 ㅠㅠ
난 상태관리 리코일 위주로 씀 내가 제일 혐오하는게 리덕스를 비롯한 원스토어 상태관리임 볼때마다 고전적인 초거대 싱글톤 패턴 보는 기분이라.
원스토어 상태가 나쁜것만은 아님. tanstack query나 redux처럼 한곳에서 처리를 해서 컨트롤이 쉬워지는 경우도 있거든. 오히려 다 쪼개지면 귀찮아지는게 한곳으로 모아야되는 SSR+ Hydration케이스라던지, 아니면 api 호출을 한번에 묶어서 처리해야하는 경우라던지 이런거 골치아파지지. 다 trade-off가 있는듯.