Web/React

react-query staleTime vs cacheTime

최근 tanstack사의 react-query가 버전 4를 정식 릴리즈 했다. 그리고 공식 이름을 tanstack-query로 변경하고 하위 패키지로 react-query를 제공한다. 이름을 변경한 이유는 react-query v4부터 react 뿐만 아니라 vue, solid, svelte도 지원하기 때문이 아닐까 추측해본다. 회사에서 진행하는 프로젝트에 활발하게 react-query를 도입 중이다. react-query에는 비슷하지만 다른, 헷갈리는 개념들이 몇 개 있다. isFetching과 isLoading, staleTime과 cacheTime이 그러하다. 이번 글은 staleTime과 cacheTime의 개념과 차이점을 정리한 내용이다. staleTime stale의 뜻은 "신선하지 않은"이다..

react-query props drilling 피하기

react-query는 상태 관리 도구이다. 상태 관리 도구를 사용하는 이유 중 큰 부분을 차지하는 것이 props-drilling을 피하기 위해서일 것이다. 이 포스트는 react-query를 사용할 때 props drilling을 피하기 위해 고민했던 내용을 다룬다. 서버에 부담 주지 않기 react-query는 동일 키의 쿼리를 동시에 여러 개 요청하면 내부적으로 하나의 요청으로 만든다. export default function App() { const { data: posts1 } = useQuery(['posts'], fetchPosts); const { data: posts2 } = useQuery(['posts'], fetchPosts); const { data: posts3 } = use..

react-query로 클라이언트 상태 관리 하기

'서버 상태 관리'라는 멋진 키워드로 등장한 react-query는 리액트 생태계에 큰바람을 불러일으키고 있다. 많은 프로젝트에서 redux + redux-saga 조합을 사용한다. 이 조합은 UI와 비동기 작업의 관심사 분리에 있어 해법처럼 사용되곤 했다. 하지만 프로젝트 규모가 커짐에 따라 redux 본연의 가치가 redux-saga의 거대한 덩치에 가려지기 일쑤이다. 그리고 이 조합은 리액트의 학습 곡선을 가파르게 한 주범이기도 하다. 그래서 redux + redux-saga 조합을 새로운 패러다임인 react-query로 대체하려는 움직임이 많이 보인다. 마이그레이션 과정에서 클라이언트 상태 관리 방법에 대한 고민이 늘 따랐다. 이번 포스트는 해당 고민을 정리한 글이다. 서버 상태, 클라이언트 상..