코드 땜장이

TanStack Query를 쓰는 이유: 서버 상태를 캐시하고 갱신하는 실전 기준 빠른 답 TanStack Query는 서버 응답을 전역 상태처럼 보관하는 도구가 아니라, 서버 데이터의 조회, 캐싱, 갱신 흐름을 관리하는 도구입니다. 같은 데이터를 여러 컴포넌트가 읽을 때 중복 요청을 줄이고, 로딩과 에러, 재요청 상태를 일관된 방식으로 다룰 수 있습니다. staleTime , gcTime , queryKey 설계가 맞지 않으면 최신성 문제나 불필요한 네트워크 요청이 생길 수 있습니다. 입력값, 모달 열림 여부, 작성 중인 폼 값처럼 브라우저가 원본인 상태는 useState , Zustand, Redux 같은 클라이언트 상태와 분리해서 다루는 편이 좋습니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 서버 상태는 일반 상태와 다르다 현재 기준 용어와 버전 차이 QueryClient에서 기본 정책 잡기 queryKey로 데이터 소유권 나누기 mutation 후 캐시 갱신하기 리렌더링 관점에서 보는 장점 흔한 안티패턴 언제 쓰고 언제 분리할까 더 읽을 공식 문서 시간 흐름으로 이해하기 컴포넌트 마운트 useQuery 를 호출한 컴포넌트가 특정 쿼리를 구독합니다. → 캐시 조회 TanStack Query가 queryKey 로 기존 캐시를 찾습니다. → 데이터 반환 캐시가 있으면 화면은 먼저 기존 데이터를 사용할 수 있습니다. → 신선도 판단 staleTime 이 지났거나 무효화된 데이터인지 확인합니다. → 백그라운드 갱신 stale 상태라면 조건에 따라 다시 요청하고 캐시를 갱신합니다. 흐름으로 보기 흐름 다이어그램 이 흐름에서 컴포넌트는 서버 데이터를 직접 소유하지 않습니다. 서버 데이터의 원본은 서버에 있고, TanStack Query는 브라우저 안의 캐시와 갱신 정책을 관리합니다. 컴포넌트는 캐시를 구독하고, 필요한 시점에 다시 가져오거나 무효화하도록 요청합니다. 이 차이를 이해하면 TanStack Query를 “또 하나의 전역 상태 ...

React 리렌더링을 줄이는 실전 기준: memo, useMemo, useCallback은 언제 써야 할까 빠른 답 리렌더링은 React의 정상 동작입니다. 먼저 React DevTools Profiler나 Profiler API로 느린 컴포넌트와 상호작용을 확인하는 편이 좋습니다. memo 는 부모가 자주 렌더링되지만 자식의 props 가 자주 같게 유지되는 경우에 효과가 있습니다. useMemo 는 비싼 계산 결과를 캐시할 때, useCallback 은 함수 참조 변화가 자식 리렌더링이나 Effect 재실행으로 이어질 때 씁니다. 메모이제이션에도 비교 비용, 메모리 비용, 의존성 관리 비용이 있으므로 모든 값과 함수에 붙이는 방식은 대체로 이득이 작습니다. 목차 선택 기준 매트릭스 React 리렌더링 흐름 문제가 되는 리렌더링 현재 기준과 오래된 설명의 차이 상태 소유권부터 정리하기 자식 컴포넌트 리렌더링 줄이기 린트와 구성 기준 Profiler로 병목 확인하기 흔한 오해와 주의사항 선택 기준 매트릭스 상황 부모만 자주 바뀌고 자식 props 는 그대로라면 memo 로 자식 렌더링을 건너뛸 수 있습니다. 상황 큰 배열 필터링, 정렬, 집계처럼 렌더 중 계산이 무겁다면 useMemo 로 계산 결과를 재사용합니다. 상황 memo 로 감싼 자식에게 콜백을 넘기는데 함수 참조가 매번 바뀐다면 useCallback 을 고려합니다. 조건 객체, 배열, 함수가 매 렌더마다 새로 만들어진다면 props 형태를 줄이거나 참조를 안정화해야 memo 가 의미를 가집니다. 조건 입력값, hover, 모달 열림 같은 일시적 UI 상태가 너무 위에 있다면 메모이제이션보다 상태 위치 조정과 컴포넌트 분리가 먼저입니다. 상황 React Compiler를 도입한 환경이라면 수동 메모이제이션 필요성이 줄 수 있지만, 빌드 설정과 지원 범위를 먼저 확인해야 합니다. React 리렌더링 흐름 React 컴포넌트는 state , props , context 가 바뀌면 다시...