Tanstack Query의 useQuery, useMutation로 데이터를 관리 및 캐싱

25. Tanstack Query의 useQuery, useMutation을 사용하여 데이터를 관리하고 캐싱하는 방법을 이해합니다.
    • 답변)
      • 의도:
        • 지원자가 Tanstack Query의 useQuery와 useMutation 훅을 사용하여 데이터를 관리하고 캐싱할 수 있는지 평가.
      • 팁:
        • useQuery와 useMutation의 개념과 사용법을 설명하세요.
        • 데이터를 가져오고 변이시키는 과정에서 캐싱이 어떻게 이루어지는지 설명하세요.
        • useQuery와 useMutation을 사용하는 예제를 떠올려 보세요.
      • 모범답안:
        • useQuery는 데이터를 가져오고 캐싱하는 데 사용되며, 자동으로 데이터를 캐싱하고 리패칭합니다.
        • useMutation은 데이터를 변이시키는 데 사용되며, 성공적인 변이 후에 관련된 쿼리를 리패칭합니다.
        • Tanstack Query는 효율적인 데이터 관리와 성능 최적화를 제공합니다.

---

❓ 위의 리패칭이 refetching이야 repatching이야? 외래어 표기를 섬세하게 합시다🥹

➡️ refetching이다!
이미 가져온 데이터를 다시 서버에서 새로 가져오는 작업을 의미한다.

• Tanstack Query 자동 refetching이 발생하는 상황

  • 컴포넌트가 마운트될 때
  • 브라우저 윈도우가 다시 포커스될 때
  • 네트워크가 다시 연결될 때
  • staleTime이 지나서 데이터가 'stale' 상태가 될 때
  • 설정한 refetchInterval에 따른 주기적인 갱신

❓ repatching이라는 용어는 보통 소프트웨어 개발에서 패치(코드 수정)를 다시 적용하는 것을 의미하며, 데이터 fetching과는 다른 개념이다.

---

Tanstack Query 핵심 개념, 특징

useQuery 개념, 특징

• 서버에서 데이터를 가져오는(READ) 작업을 처리하는 훅
• 데이터를 자동으로 캐싱하고, 필요할 때 자동으로 리페칭
• 데이터의 상태(loading, error, success)를 자동으로 추적 및 관리
• 한번 가져온 데이터는 staleTime 동안 "신선한" 상태로 유지되며, 이 기간 동안은 불필요한 재요청 방지
• cacheTime 동안은 데이터가 메모리에 유지되어, 재사용 가능

❓ 즉, useQuery는 별도의 후속 작업 없이도 자동 캐싱? ➡️ YES!

useQuery 기본 동작

• queryKey를 기반으로 자동으로 캐싱됨
• 동일한 queryKey로 다른 컴포넌트에서 데이터를 요청하면, 캐시된 데이터를 재사용
• staleTime 동안은 새로운 요청 없이 캐시된 데이터 사용

필요한 경우에는 useQuery에도 후속 작업 정의 가능

🖥️ javascript

const { data } = useQuery({
  queryKey: ['todos'],
  queryFn: fetchTodos,
  onSuccess: (data) => {
    console.log('데이터 가져오기 성공:', data);
  },
  onError: (error) => {
    console.log('에러 발생:', error);
  }
});

useMutation과의 차이점

• useQuery : 자동 캐싱이 기본 동작이며, 후속 작업은 선택적
• useMutation : 캐싱이 없고, 후속 작업(onSuccess, onError 등)을 통해 수동으로 캐시 관리 필요

---

useMutation 개념, 특징

• 서버의 데이터를 변경하는(CREATE, UPDATE, DELETE) 작업을 처리하는 훅
• 단발성 작업이므로 캐싱이 없고, 요청할 때마다 서버에 새로운 요청을 보낸다
• 성공/실패에 따른 후속 작업(다른 쿼리 무효화, 캐시 업데이트 등)을 정의할 수 있다
• 낙관적 업데이트를 통해 서버 응답 전에 UI 먼저 업데이트 가능

---

데이터 캐싱 방식

• queryKey를 기반으로 데이터 캐싱
• staleTime : 데이터가 "신선하다"고 간주되는 시간
  (기본값이 0이어서 오자마자 썩는 거였던 걸로 기억)
• cacheTime : 사용하지 않는 데이터가 메모리에 유지되는 시간
• 자동 리페칭 : 윈도우 포커스, 네트워크 재연결, 컴포넌트 리마운트 시 발생

🏵️ TIL - 기존 캐싱 vs 탠스택 쿼리 캐싱

---

데이터 상태 관리

• fresh : 신선한 데이터 (staleTime 이내)
• stale : 오래된 데이터 (staleTime 이후)
• fetching : 데이터를 가져오는 중
• error : 에러 발생
• inactive : 사용되지 않는 상태

---

장점

• 서버 상태 관리 자동화로 개발자 부담 경감.
• 중복 요청을 방지하고 캐싱을 통해 성능을 최적화한다.
• 데이터의 동기화 상태를 자동으로 관리한다.
• 에러 처리와 로딩 상태 관리가 용이하다.
• 서버 데이터와 클라이언트 상태를 명확하게 구분할 수 있다.

---

주의사항

• queryKey는 배열 형태로, 고유하고 일관성 있게 관리해야 한다.
• staleTime과 cacheTime을 상황에 맞게 적절히 설정해야 한다.
• 너무 잦은 리패칭은 서버 부하를 일으킬 수 있으므로 주의.
• 변이 후의 쿼리 무효화 전략을 잘 설계해야 한다.