TanStack Query를 쓰는 이유: 서버 상태를 캐시하고 갱신하는 실전 기준 빠른 답 TanStack Query는 서버 응답을 전역 상태처럼 보관하는 도구가 아니라, 서버 데이터의 조회, 캐싱, 갱신 흐름을 관리하는 도구입니다. 같은 데이터를 여러 컴포넌트가 읽을 때 중복 요청을 줄이고, 로딩과 에러, 재요청 상태를 일관된 방식으로 다룰 수 있습니다. staleTime , gcTime , queryKey 설계가 맞지 않으면 최신성 문제나 불필요한 네트워크 요청이 생길 수 있습니다. 입력값, 모달 열림 여부, 작성 중인 폼 값처럼 브라우저가 원본인 상태는 useState , Zustand, Redux 같은 클라이언트 상태와 분리해서 다루는 편이 좋습니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 서버 상태는 일반 상태와 다르다 현재 기준 용어와 버전 차이 QueryClient에서 기본 정책 잡기 queryKey로 데이터 소유권 나누기 mutation 후 캐시 갱신하기 리렌더링 관점에서 보는 장점 흔한 안티패턴 언제 쓰고 언제 분리할까 더 읽을 공식 문서 시간 흐름으로 이해하기 컴포넌트 마운트 useQuery 를 호출한 컴포넌트가 특정 쿼리를 구독합니다. → 캐시 조회 TanStack Query가 queryKey 로 기존 캐시를 찾습니다. → 데이터 반환 캐시가 있으면 화면은 먼저 기존 데이터를 사용할 수 있습니다. → 신선도 판단 staleTime 이 지났거나 무효화된 데이터인지 확인합니다. → 백그라운드 갱신 stale 상태라면 조건에 따라 다시 요청하고 캐시를 갱신합니다. 흐름으로 보기 흐름 다이어그램 이 흐름에서 컴포넌트는 서버 데이터를 직접 소유하지 않습니다. 서버 데이터의 원본은 서버에 있고, TanStack Query는 브라우저 안의 캐시와 갱신 정책을 관리합니다. 컴포넌트는 캐시를 구독하고, 필요한 시점에 다시 가져오거나 무효화하도록 요청합니다. 이 차이를 이해하면 TanStack Query를 “또 하나의 전역 상태 ...
localStorage와 sessionStorage 차이: 저장 기간, 탭 범위, 보안 기준으로 고르기 빠른 답 localStorage 는 브라우저를 닫아도 값이 남고, 같은 origin 의 여러 탭에서 공유됩니다. sessionStorage 는 탭 또는 창 단위 세션에 묶이며, 해당 탭을 닫으면 값이 사라집니다. 둘 다 JavaScript로 읽고 쓸 수 있으므로 인증 토큰, 비밀번호, 개인정보 저장소로 보기에는 위험합니다. 테마·언어 설정처럼 오래 유지할 값은 localStorage , 현재 탭 안에서만 필요한 임시 상태는 sessionStorage 가 어울립니다. 목차 한눈에 비교 시간 흐름으로 이해하기 origin과 탭 범위 이해하기 저장소 선택 규칙 만들기 실제 사용 예시 언제 무엇을 저장할까 보안 주의점 저장 실패와 예외 처리 흔한 오해 정리 선택 기준 정리 한눈에 비교 저장 기간 localStorage 는 코드로 삭제하거나 사용자가 브라우저 데이터를 지우기 전까지 유지되고, sessionStorage 는 탭 또는 창 세션이 끝나면 삭제됩니다. 공유 범위 localStorage 는 같은 origin 의 문서들이 공유하고, sessionStorage 는 탭 또는 창마다 별도 공간을 가집니다. 새로고침 두 저장소 모두 같은 탭에서 새로고침만으로는 삭제되지 않습니다. 새 탭 열기 localStorage 값은 같은 origin 의 새 탭에서도 읽을 수 있지만, sessionStorage 는 새 탭 기준의 별도 저장 공간을 사용합니다. 사용 예시 localStorage 는 테마, 언어, 목록 정렬 방식에 잘 맞고, sessionStorage 는 결제 단계 상태, 임시 폼 입력, 현재 탭의 검색 필터에 잘 맞습니다. 보안 기준 두 저장소 모두 JavaScript 접근이 가능하므로 민감 정보 저장에는 신중해야 합니다. localStorage 와 sessionStorage 는 모두 Web Storage API에 속합니다. 사용법은 거의 같습니다. ...