TLDR : (!트리_아래_업데이트 && context) || zustand
긴말 필요없이 아래 트윗을 인용합니다. (Tanner Linsley === 리액트 쿼리 메인테이너, 창시자)
https://twitter.com/tannerlinsley/status/1293640999533568000?lang=en
트위터에서 즐기는 Tanner Linsley
“I'm using #ReactQuery with Zustand and really liking the pairing. It's a super tiny, very flexible, no-nonsense client-state solution for React. If I were to write a client-state solution from scratch, it would likely resemble Zustand in many ways. http
twitter.com
해당 트윗에 아래와 같은 질문이 달렸습니다.
https://twitter.com/ADiMartun/status/1293642826975268864
트위터에서 즐기는 马丁
“@tannerlinsley When would you consider using zustand over Context api? :)”
twitter.com
Context API보다 zustand를 사용하는 것을 언제 고려하시겠습니까? :)
그에 대한 답변입니다.
https://twitter.com/tannerlinsley/status/1293645778532016128
트위터에서 즐기는 Tanner Linsley
“@ADiMartun If I don't need to update a value from a deep-component (eg. a theme context or configuration context), then I would use context. But I think for anything that needs to be updated over time by a component, I would *consider* Zustand. It's pre
twitter.com
참고
https://github.com/pmndrs/zustand
GitHub - pmndrs/zustand: 🐻 Bear necessities for state management in React
🐻 Bear necessities for state management in React. Contribute to pmndrs/zustand development by creating an account on GitHub.
github.com
첨언하자면 왜 컨텍스트로 zustand나 Recoil, redux를 대체할 수 없을까요?
기본적으로 컨텍스트는 Reactivity를 제공하지 않습니다.
즉 셀렉터 등으로 상태 변화에 대한 컴포넌트 구독 메커니즘을 수현할 수가 없습니다.
그냥 해당 컨텍스트의 상태가 바뀌면, 해당 컨텍스트에 의존하는 모든 컴포넌트는 상테가 변경되게 됩니다.
엑셀을 웹에서 구현한다 생각하면 이 문제가 극단적이 되는데여,
리덕스, zustand는 셀렉터 구독이 가능하기 때문에 상태가 아예 새로 만들어져도 변경된 셀만 렌더링이 가능합니다.
리코일은 해당 아톰에 의존적인 컴포넌트만 변경됩니다.
context API는 memoiziation 연산밖에는 리렌더링을 방어할 방도가 없습니다.
'FrontEnd' 카테고리의 다른 글
| 타입스크립트 : React.FC는 그만! children 타이핑 올바르게 하기 (0) | 2022.07.24 |
|---|---|
| 리액트 테스트 : Context API 테스트와 커스텀 렌더 함수 사용하기 (0) | 2022.07.23 |
| 리액트 테스트 : 브라우저 API와 서드파티 모듈 mocking (0) | 2022.07.23 |
| 리액트 테스트 : MSW를 사용하여 HTTP Requests 모킹하기 (0) | 2022.07.23 |
| 타입스크립트 : typescript with JSON (JSON에 타입 지원) (0) | 2022.07.22 |
