리액트의 상태 관리 라이브러리들을 사용하다 보면, 글로벌 상태 초기화 과정에서 예상치 못한 에러가 발생하는 경우가 있다.

보통 Zustand를 유저의 상태 저장을 위해 사용하고 React-query를 서버 데이터를 관리하기 위해 사용한다. 그래서 처음에는 단순히 둘 다 상태 관리 라이브러리라고 생각하며 사용하게 된다.

하지만, 이 둘을 초기화하는 과정에서 차이점을 느끼게 된다.

특히, React Query가 단순한 상태 관리 툴이 아닌 '캐시와 구독을 관리하는 툴'이라는 점을 깨닫게 된다. 이 때문에 React Query의 캐시는 때때로 추가적인 관리가 필요하다.

이 글은 이러한 문제가 왜 발생하고, 어떻게 해결했는지에 대해 다루고자 한다.

평범한 로그아웃 예시

const onLogout = async () => {
  await logout(); // 로그아웃 api
  resetUser(); // 클라이언트에 저장된 유저 데이터 초기화 Zustand code 
  queryClient.clear(); // 캐시 초기화를 위한 React Query code 
  router.push('/home'); // Navigate 
};

얼핏 보면 문제가 없어 보인다. 하지만 실제로 실행해보면 router.push()와 관련된 에러가 발생할 수 있다.

다양한 시도 끝에 아래와 같은 방식으로 변경하면 문제가 발생하지 않음을 확인할 수 있다.

const onLogout = async () => {
  await logout();
  resetUser(); // Zustand 
  Promise.resolve().then(() => queryClient.clear()); // React Query 
  router.push('/home');
};

그리고 자연스럽게 이런 의문이 생긴다.

"왜 React Query 코드는 Promise가 필요하고, Zustand 코드는 Promise 없이도 잘 작동할까?"

🐻 Zustand vs 🔥 React Query

🐻 Zustand - 단순한 동기적인 상태 업데이트

resetUser()를 실행하면 Zustand는:
1. 스토어의 상태를 동기적으로 변화시킨다.
2. 상태를 구독 중인 컴포넌트들에게 리렌더링을 요청한다.
3. 이미 언마운트된 컴포넌트는 구독이 취소되어 무시된다.

React Query - 캐시, 옵저버들, 그리고 사이드 이펙트들

queryClient.clear()을 실행하면:
1. 캐시로부터 쿼리 데이터를 제거하고 무효화한다.
2. 활성화 상태의 구독자들에게 변경 사항을 알린다.
3. 진행 중인 네트워크 요청, 재시도, 리페치를 처리한다.

주요 문제는 queryClient.clear()가 실행되는 동안, router.push()로 인해 컴포넌트가 언마운트되면 레이스 컨디션이 발생할 수 있다는 점이다.

• React query가 여전히 컴포넌트들에게 알리는 중일 때, 컴포넌트들은 구독 취소를 할 수 있다.
• 캐시를 클리어한 후 진행 중이던 네트워크 요청이 완료될 수 있다.
• 언마운트된 컴포넌트에 React Query가 상태 업데이트를 시도할 수 있다.

레이스 컨디션 (race condition)

‘레이스 컨디션’이란 두 개 이상의 작업이 동시에 실행되면서, 실행 순서나 타이밍에 따라 결과가 달라지는 상황을 말한다. 이 경우, React Query 캐시를 클리어하는 것과 라우트에 의한 컴포넌트 언마운트가 겹칠 수 있다. 이것은 예상치 못한 동작이나 오류로 이어질 수 있다.

왜 지연시키면 문제가 해결될까?

다음 코드를 보면:

Promise.resolve().then(() => queryClient.clear());

캐시 클리어는 다음 마이크로태스크에서 진행된다.

이로 인해 리액트가 다음 작업을 먼저 처리하게 된다.
1. router.push()로 인해 발생한 컴포넌트 언마운트를 완료한다.
2. React Query와 연결된 컴포넌트들이 구독 취소를 완료한다.
3. 그 이후, 진행 중인 리액트 라이프 사이클과 간섭 없이, 안전하게 캐시를 클리어하게 한다.

이러한 비동기 지연 처리가 레이스 컨디션을 피하는 핵심이다.

그렇다면 왜 Zustand는 언제나 안전할까?

Zustand 상태 변경은 동기적이고 라이프 사이클에 민감하게 반응하지 않는다.

• 만약, resetUser() 실행 시, 마운트된 컴포넌트는 리렌더링된다.
• 언마운트된 컴포넌트는 이미 구독 취소되어 있어 무시된다.
• 간섭할 비동기적인 행동이나 네트워크 라이프 사이클 상태 관리가 없다.

이렇듯 간단한 구조 덕분에, 네비게이션이나 컴포넌트 라이프사이클과 관계없이 언제든 안전하게 상태 변경이 가능하다.

요약

Zustand는 동기적이고 단순한 구조 덕분에 안전하게 초기화할 수 있지만, React Query는 캐시와 비동기 요청 상태를 함께 관리하기 때문에 컴포넌트 라이프사이클과 맞물려 레이스 컨디션이 발생할 수 있다. 이를 방지하려면, 비동기적으로 캐시 초기화를 처리하는 등의 주의가 필요하다.