코드 땜장이

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에 속합니다. 사용법은 거의 같습니다. ...

useEffect 로딩 상태와 Suspense는 무엇이 다르고 언제 써야 할까 빠른 답 useEffect 방식은 요청 시작, 성공, 실패, 로딩 종료를 컴포넌트 안의 state로 직접 관리한다. Suspense 는 자식 트리가 아직 렌더링 준비를 끝내지 못했을 때 가장 가까운 fallback 을 보여주는 경계 모델이다. 일반 fetch 를 useEffect 안에서 호출하는 것만으로는 Suspense 가 동작하지 않는다. Suspense 를 쓰려면 fallback 위치, Error Boundary, 데이터 캐시나 프레임워크 지원 여부를 함께 봐야 한다. 목차 한눈에 비교 시간 흐름으로 이해하기 현재 React 기준에서 봐야 할 점 useEffect 방식이 맞는 상황 useEffect에서 자주 생기는 안티패턴 Suspense 방식이 맞는 상황 경계 배치와 리렌더링 흐름 선택 기준 한눈에 비교 상태 소유권 useEffect 방식은 isLoading , data , error 를 컴포넌트가 직접 가진다. Suspense 방식은 대기 UI 표시를 경계가 맡고, 데이터 준비 여부는 Suspense를 지원하는 데이터 소스가 담당한다. 데이터 흐름 useEffect 는 첫 렌더 이후 Effect에서 요청을 시작하고 응답을 state로 반영한다. Suspense 는 렌더링 중 값을 읽을 때 아직 준비되지 않았음을 React가 감지하고 경계로 빠진다. 리렌더링 useEffect 는 setState 가 일어나며 로딩 화면, 성공 화면, 실패 화면으로 다시 렌더링된다. Suspense 는 자식 트리 렌더링을 보류했다가 데이터가 준비되면 다시 렌더링을 시도한다. 에러 처리 useEffect 는 보통 error state와 조건부 렌더링으로 처리한다. Suspense 와 함께 쓰는 Promise 실패는 Error Boundary 또는 대체 값 설계가 필요하다. 적용 조건 useEffect 는 브라우저 API, 네트워크 요청, 외부 위젯처럼 컴포넌트 밖 시스템과 동...

React 동시성 이해하기: 입력은 즉시 반응하고 무거운 렌더링은 뒤로 미루는 법 빠른 답 현재 기준으로는 Concurrent Mode 라는 전역 모드를 켜는 방식보다, createRoot 기반의 동시 렌더링과 transition API를 필요한 업데이트에 적용하는 방식으로 이해하는 편이 정확합니다. 입력창 값처럼 즉시 반영되어야 하는 상태는 transition 으로 감싸지 않고, 그 입력에 따라 바뀌는 무거운 결과 영역만 낮은 우선순위로 미룹니다. 상태 업데이트를 직접 호출하는 위치라면 useTransition 또는 startTransition 을, 이미 전달받은 값의 화면 반영만 늦추고 싶다면 useDeferredValue 를 고려합니다. 동시성 API는 느린 계산을 빠르게 만드는 도구가 아니라, 사용자가 먼저 체감하는 렌더링이 막히지 않도록 우선순위를 나누는 도구입니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 Concurrent Mode라는 표현이 헷갈리는 이유 설정 기준 잡기 데이터 흐름과 상태 소유권 useTransition과 startTransition을 쓰는 위치 useDeferredValue가 어울리는 경우 흔한 안티패턴 현재 기준의 마이그레이션 포인트 시간 흐름으로 이해하기 검색창에 글자를 입력하고 그 결과로 큰 목록이 다시 렌더링되는 상황을 기준으로 보면 React 동시성은 다음 흐름으로 동작합니다. 입력 발생 사용자가 검색어를 입력합니다. → 긴급 업데이트 입력창의 text 상태는 즉시 반영됩니다. → 전환 예약 결과 목록을 바꾸는 query 업데이트는 낮은 우선순위로 표시됩니다. → 렌더링 조정 결과 렌더링 중 새 입력이 들어오면 React가 기존 작업을 중단하거나 최신 값 기준으로 다시 시작할 수 있습니다. → 화면 커밋 렌더링이 완료된 결과만 실제 DOM에 반영됩니다. 여기서 중요한 구분은 입력 상태와 결과 상태를 같은 속도의 일로 보지 않는 것입니다. 사용자는 키를 눌렀을 때 글자가 바로 찍히는지를 먼저 ...