<div id="readability-page-1" class="page"><div>react-query의 적용이 무조건 옳은가? 
어떤 장점이 있을까?
난 쌩으로 axios를 사용하는 것 보다 좋다고 본다.
react-query의 장점으로는 크게
<ul>
<li>순수 클라이언트의 앱 상태관리와 API 호출의 상태관리를 각각 독립적인 공간에 관리할 수 있다.<ol>
<li>클라이언트 앱 상태관리: redux, recoil, jotai 기타 등등..</li>
<li>서버 호출 상태관리: react-query</li>
</ol></li>
<li>cache를 지원한다.</li>
</ul>
헌데 아는 개발자분과 이야기를 나누다보니 cache가 백오피스관점에선 큰 이점이 아닐수도 있겠다는 생각이든다.
1번의 장점은 훌륭하다고 생각한다. 
매번 redux store와 같은 공간에 isLoading, isComplete 과 같은 서버호출상태값을 관리하지않아도 된다. 
그리고 우리는 이 상태값을 잘 활용하여 스피너등을 띄우는데 활용한다.
헌데 <code>2번 캐싱</code>은? 
과연 쓸모가 있을까?
백오피스에서 대용량 쿼리를 캐싱했다고 치자. 
헌데 DB상의 데이터가 바뀌었다면..? 
캐싱을 한 데이터는 무용지물일뿐만아니라 오히려 사용자에게 혼동을 줄 수 도 있을 것 같다.</div></div>

ginameee.log

Jangchun Lee

react-query의 적용이 무조건 옳은가?
어떤 장점이 있을까?
난 쌩으로 axios를 사용하는 것 보다 좋다고 본다.
react-query의 장점으로는 크게
순수 클라이언트의 앱 상태관리와 API 호출의 상태관리를 각각 독립적인 공간에 관리할 수 있다.
클라이언트 앱 상태관리: redux, recoil, jotai 기타 등등..
서버 호출 상태관리: react-query
cache를 지원한다.
헌데 아는 개발자분과 이야기를 나누다보니 cache가 백오피스관점에선 큰 이점이 아닐수도 있겠다는 생각이든다.
1번의 장점은 훌륭하다고 생각한다.
매번 redux store와 같은 공간에 isLoading, isComplete 과 같은 서버호출상태값을 관리하지않아도 된다.
그리고 우리는 이 상태값을 잘 활용하여 스피너등을 띄우는데 활용한다.
헌데 2번 캐싱은?
과연 쓸모가 있을까?
백오피스에서 대용량 쿼리를 캐싱했다고 치자.
헌데 DB상의 데이터가 바뀌었다면..?
캐싱을 한 데이터는 무용지물일뿐만아니라 오히려 사용자에게 혼동을 줄 수 도 있을 것 같다.

2022. 12. 18

댓글