{read(id)}
} ``` - `useState` 초기화 함수는 컴포넌트가 **새로 만들어질 때만** 돈다. 번호가 오르면 새로 만들어졌다는 뜻이다 - `useLayoutEffect`는 커밋 직후에 돈다. "커밋" 로그가 찍히면 화면에 나간 것이다 --- ## 실험 1 결과: 렌더 세 번, 초기화도 세 번 ```text 3ms useState 초기화 → #1 render 5ms fallback 커밋 7ms useState 초기화 → #2 render 56ms useState 초기화 → #3 render 310ms 커밋 (state #3) ``` - 커밋되기 전까지 Profile은 **세 번** 렌더됐고, 세 번 모두 `useState`가 **새로** 초기화됐다 - 화면에 남은 것은 #3뿐이다. #1과 #2가 들고 있던 값은 그대로 사라졌다 - #1은 첫 시도, #3은 데이터가 온 뒤의 재시도다. #2는 fallback을 띄운 직후 React가 한 번 더 해 본 렌더다. 렌더는 생각보다 자주 일어나고, 언제든 버려질 수 있다 --- ## 네 가지 경우를 나란히 놓으면 | 상황 | 렌더 | `useState` | 화면 | | -------------------------- | ---- | ------------------------ | ----------------------------------- | | 리렌더 (setState) | 1번 | 그대로 #3 | 그대로 | | 커밋된 뒤 다시 suspend | 3번 | **그대로 #3** | 기존 DOM을 `display: none`으로 숨김 | | **처음 마운트 중 suspend** | 3번 | **매번 새로** #1, #2, #3 | fallback | | 리마운트 (key 변경) | 1번 | 새로 #4 | 새로 그림 | 한 번이라도 커밋된 컴포넌트는 React가 기억해 둔다. 그래서 다시 suspend돼도 숨겨 두었다가 그대로 꺼내 쓴다. 한 번도 커밋되지 않은 컴포넌트는 기억할 것이 없어서, 재시도는 사실상 처음부터 다시 마운트하는 것과 같다. 이것이 질문 1의 답이다. --- ## 그러니 남아야 하는 것은 밖에 둔다 실험 1에서 #3이 데이터를 받을 수 있었던 것은 `cache`가 컴포넌트 밖에 있었기 때문이다. 캐시를 컴포넌트 안으로 옮기면 어떻게 될까. ```jsx function Profile({id}) { const cache = useRef(new Map()).current // 캐시를 안으로 // ...나머지는 실험 1과 같다 } ``` - 2초 동안 `useState` 초기화가 **94번** 돌았고, 화면은 계속 loading이었다 - 렌더할 때마다 새 Map이 생기니 앞 렌더가 시작한 요청을 모른다. 또 요청하고, 그 요청이 끝나 재시도하면 또 새 Map이 생긴다 react-query도 정확히 같은 제약 위에 서 있다. --- ## react-query에서 무엇이 어디에 사나 도서관에 빗대면 이렇다. | 도서관 | react-query | 사는 곳 | | -------------- | ---------------------------------- | --------------------------------------- | | 책 | **Query**: 데이터와 진행 중인 요청 | QueryCache (**컴포넌트 밖**) | | 그 책의 신청서 | **QueryObserver** | 컴포넌트의 `useState` (**컴포넌트 안**) | ```ts // react-query 5.104.1, useBaseQuery.ts:83 (타입 생략) const [observer] = React.useState( () => new Observer(client, defaultedOptions), ) ``` 신청서는 컴포넌트와 함께 버려지고, 책은 서가에 남는다. 책은 queryKey마다 한 권, 신청서는 useQuery를 부를 때마다 한 장이다. --- ## useSuspenseQuery는 렌더 중에 요청한다 ```ts // react-query 5.104.1, useBaseQuery.ts:119 if (shouldSuspend(defaultedOptions, result)) { throw fetchOptimistic(defaultedOptions, observer, errorResetBoundary) } // suspense.ts:49 (타입 생략) export const shouldSuspend = (defaultedOptions, result) => defaultedOptions?.suspense && result.isPending ``` - 풀어 쓰면: 데이터가 아직 없으면(`isPending`) 그 자리에서 요청을 시작하고, 그 요청의 promise를 던진다(suspend) - `fetchOptimistic`은 서가(QueryCache)에서 책(Query)을 찾거나 새로 만든 뒤 요청을 보낸다 --- ## 실험 2: useSuspenseQuery가 suspend될 때 ```text 3ms render Profile 4ms new QueryObserver #1 4ms queryFn 호출 #1 7ms render Profile 7ms new QueryObserver #2 56ms render Profile 56ms new QueryObserver #3 309ms 커밋 Profile 310ms Observer #3 구독 시작 ``` | 버려진 것 (컴포넌트 안) | 남은 것 (컴포넌트 밖) | | ----------------------- | ----------------------------------- | | QueryObserver #1, #2 | Query 1개, 요청 1번, 받아 온 데이터 | 신청서는 세 장 썼다가 두 장이 버려졌다. 책은 한 권이고, 책을 가지러 간 것도 한 번이다. --- ## 렌더가 세 번인데 요청은 왜 한 번일까 | 렌더 | QueryCache에서 찾은 `['user']` | 그래서 | | ---- | ------------------------------ | --------------------------------------------- | | #1 | 없음 | 새로 만들고 요청을 시작한다 | | #2 | 있음, 요청 중 | 새로 요청하지 않고 진행 중인 promise를 받는다 | | #3 | 있음, 데이터 도착 | 데이터를 바로 읽는다. suspend하지 않는다 | ```ts // query-core 5.104.1, queryCache.ts:163 build() 발췌 let query = this.get(queryHash) // 같은 키의 Query가 이미 있으면 그것을 쓴다 if (!query) { query = new Query({...}) this.add(query) } // query.ts:608 fetch() 발췌. 이미 요청 중이면 return this.#retryer.promise // 진행 중인 promise를 그대로 돌려준다 ``` --- ## 그래서 렌더 중 요청은 괜찮은가 엄밀히 말하면 규칙 위반이다. React는 렌더 중에 **부수 효과**(네트워크 요청이나 전역 값 변경처럼 계산 바깥을 바꾸는 일)를 하지 말라고 한다. 렌더가 몇 번 돌지, 버려질지 알 수 없기 때문이다. 그래도 react-query의 렌더 중 요청이 문제를 일으키지 않는 것은 그 두 가지 걱정을 모두 피하기 때문이라고 생각한다. - **몇 번 돌아도 요청은 한 번이다.** 같은 키면 같은 Query, 같은 요청으로 모인다. StrictMode에서 Observer가 6개 만들어져도 queryFn은 1번이었다 - **버려져도 잃는 것이 없다.** 요청과 데이터는 컴포넌트 밖 QueryCache에 남는다 이것이 질문 2의 답이다. --- ## 라이브러리도 "suspend 뒤에는 리마운트된다"고 적어 두었다 ```ts // react-query 5.104.1, suspense.ts:24 발췌 if (defaultedOptions.suspense) { // Handle staleTime to ensure minimum 1000ms in Suspense mode const MIN_SUSPENSE_TIME_MS = 1000 // ...staleTime이 1000보다 작으면 1000으로 올린다 } ``` > This prevents unnecessary refetching when components remount after suspending (바로 아래 줄 주석) - staleTime 기본값은 0이라, 데이터는 받자마자 **stale**(다시 받아야 할 데이터)로 취급된다 - 실험 2에서 #1이 받아 온 데이터를, 나중에 마운트하는 #3은 stale로 보고 또 요청하려 한다 - 그래서 suspense 모드에서만 staleTime을 최소 1초로 올려 이 중복 요청을 막는다. 이 보정이 **suspense 모드에만** 있다는 점은 실험 4에서 다시 나온다 --- ## 이제 useQuery: 요청은 언제 나갈까 ```text 3ms new QueryObserver #1 4ms render Profile (status=pending) 6ms 커밋 Profile 6ms Observer #1 구독 시작 6ms queryFn 호출 60ms render Profile (status=success) ``` ```ts // query-core 5.104.1, queryObserver.ts:110 발췌 (한국어 주석은 덱에서 붙임) protected onSubscribe(): void { // 구독이 시작될 때 불린다 if (this.listeners.size === 1) { this.#currentQuery.addObserver(this) if (shouldFetchOnMount(this.#currentQuery, this.options)) { this.#executeFetch() // 요청은 여기서 나간다 ``` **구독**은 Observer가 Query에 "바뀌면 알려 달라"고 등록하는 것이다. useQuery에서 구독은 커밋된 뒤에 시작되고, 요청도 그때 나간다. 신청서를 제출해야 사서가 책을 가지러 가는 셈이다. --- ## useQuery를 쓰는 컴포넌트가 스스로 suspend하면 실험 1의 표에 대입해 본다. 1. 처음 마운트되는 중에 suspend되면 커밋되지 않는다 2. 커밋되지 않으면 Observer는 구독을 시작하지 않는다 3. 구독이 없으면 요청도 나가지 않는다 4. 요청이 없으면 promise는 풀리지 않고, 재시도할 계기도 생기지 않는다 신청서를 제출하기도 전에 찢어 버리니, 아무도 책을 가지러 가지 않는 상황이다. useQuery는 "커밋된 뒤에 요청한다"는 전제로 만든 훅이라 렌더 중 suspend와 맞물리지 않는다. 이것이 질문 3의 답이다. --- ## 그래도 시도는 있었다: `experimental_prefetchInRender` ```jsx // react-query 5.101.4까지 const queryClient = new QueryClient({ defaultOptions: {queries: {experimental_prefetchInRender: true}}, }) function Profile() { const {promise} = useQuery({queryKey: ['user'], queryFn}) const user = use(promise) // React 19의 use()로 suspend return{user.name}
} ``` - 플래그를 켜면 useQuery 결과에 `promise`가 붙는다 - `use(promise)`는 React 19 API다. promise가 아직이면 suspend하고, 끝났으면 값을 돌려준다 - 메인테이너 TkDodo는 2024년 12월에 useSuspenseQuery라는 별도 훅을 없애고 이 방식으로 가는 것을 고민하고 있다고 했다(토론 #8381) --- ## 실험 3: 렌더 중 요청 블록을 지워 보면 플래그가 렌더 중에 요청을 걸어 주지 않았다면 어떻게 됐을지 보려고, 5.101.4에서 그 블록만 지운 사본으로 위 Profile을 실행했다. ```text 3ms render Profile 4ms new QueryObserver #1 7ms render Profile 7ms new QueryObserver #2 1.5초 뒤: 구독한 Observer 없음, queryFn 0회, 화면은 loading ``` 앞 장의 1~4가 그대로 일어났다. 아무도 요청을 보내지 않으니 fallback에서 나오지 못한다. --- ## 그래서 플래그가 손으로 해 주던 일 두 가지 ```ts // react-query 5.101.4, useBaseQuery.ts:153 발췌 (5.102.0에서 삭제) if (defaultedOptions.experimental_prefetchInRender && ...) { const promise = isNewCacheEntry ? fetchOptimistic(defaultedOptions, observer, errorResetBoundary) // (1) : query?.promise promise?.catch(noop).finally(() => { observer.updateResult() // (2) }) } ``` - (1) **구독을 기다리지 않고 렌더 중에 직접 요청한다.** 신청서를 제출하기 전에 사서에게 먼저 달려가 부탁해 두는 셈이다 - (2) **요청이 끝나면 promise를 직접 풀어 준다.** React가 기다리는 promise는 곧 버려질 Observer #1이 만든 것이다. #1은 구독을 하지 않으니, 원래라면 아무도 이 promise를 풀어 주지 않는다 --- ## 실험 4: 원본 5.101.4에서는 ```text 4ms new QueryObserver #1 4ms queryFn 호출 #1 ← 렌더 중에 요청 7ms new QueryObserver #2 57ms new QueryObserver #3 311ms Observer #3 구독 시작 312ms queryFn 호출 #2 ← 같은 데이터를 또 요청 ``` - 화면은 제대로 나온다. 렌더 중 요청 블록 덕분이다 - 그런데 요청이 **두 번** 나갔다. #3이 마운트하며 구독할 때 데이터가 이미 stale이었기 때문이다 - useSuspenseQuery였다면 staleTime 1초 보정이 이 요청을 막았을 것이다. useQuery에는 그 보정이 없다. staleTime을 1000으로 주면 1번으로 줄어드는 것도 확인했다 --- ## 실험 5: 컴포넌트를 나누면 문제가 사라진다 ```jsx function Parent() { const {promise} = useQuery({queryKey: ['user'], queryFn}) return ({use(promise)}
``` | 5.101.4 | Observer | queryFn | 화면 | | ---------------------- | -------- | ------- | ---- | | 원본 | 1개 | 1회 | 정상 | | 렌더 중 요청 블록 삭제 | 1개 | 1회 | 정상 | suspend되는 것은 Child뿐이다. 신청서를 가진 Parent는 커밋되고 구독하니, 렌더 중 요청 블록이 없어도 평소처럼 요청이 나간다. --- ## 메인테이너의 결론 (2025-12-30, 이슈 #9988) > I think we should generally disallow suspending the same component that calls useQuery and get rid of the experimental flag. I think it's too hacky. What you'd need to do is to pass the promise to a separate component and wrap that in suspense. - useQuery를 호출한 **바로 그 컴포넌트**를 suspend시키는 것은 막아야 한다 - 실험 플래그는 없애야 한다. 너무 꼼수 같다(too hacky) - promise를 별도 컴포넌트로 넘기고, 그쪽을 Suspense로 감싸야 한다 없애자고 한 것은 꼼수(실험 3, 4)다. 바깥 배치(실험 5)는 오히려 **권장하는 방법**이었다. --- ## 그리고 제거 (5.102.0) | 날짜 | 일 | | ---------- | ------------------------------------------------------------------------- | | 2025-12-30 | TkDodo, "같은 컴포넌트를 suspend시키는 것은 막고 플래그는 없애야" (#9988) | | 2026-08-17 | "이 방식은 오래 버티지 못할 것 같다" (토론 #10733) | | 2026-08-20 | PR #11221 "ref: remove experimental_prefetchInRender" 병합 | | 2026-08-22 | 5.102.0 배포. 플래그와 결과의 `promise` 필드가 함께 사라짐 | - 플래그만이 아니라 `promise` 필드까지 지웠다(5.104.1에서 직접 확인). 그래서 **바깥 배치(실험 5)도 함께 사라졌다** - PR 본문과 changeset에는 지웠다는 사실만 있고 이유는 없다. 바깥 배치를 보여 주던 공식 문서 예제(Suspense 가이드)도 이 PR에서 삭제됐다 --- ## 헷갈리기 쉬운 점: 사라진 것은 두 가지다 | | 렌더 중 요청 (꼼수) | 결과의 `promise` 필드 | | ------------- | ---------------------------------------------------------- | ---------------------------------- | | 무엇을 위해 | 같은 컴포넌트에서 suspend해도 요청이 나가게 | `use(promise)`로 suspend할 수 있게 | | 문제가 있었나 | 꼼수 없이는 요청이 안 나가고(실험 3), 있어도 두 번(실험 4) | 바깥 배치에서는 없었다(실험 5) | | 지운 이유 | "too hacky" (#9988) | **적혀 있지 않다** | - 실험 3, 4에서 본 문제(버려지는 Observer와 중복 요청)는 **왼쪽 열**, 같은 컴포넌트에서 suspend할 때의 이야기다 - 바깥 배치는 멀쩡했는데도 `promise`와 함께 사라졌다. 이유가 기록에 없으니 다음 장은 근거를 붙인 추측이다 --- ## 바깥 배치는 왜 같이 사라졌을까 (추측) **1. 바깥 배치만 골라 남길 방법이 없다** - `promise`는 useQuery가 돌려주는 값이라, 같은 컴포넌트에서 바로 `use(promise)`를 부르는 코드가 가장 자연스럽다. 토론 #10733에 달린 답변도 그렇게 썼다 - 꼼수만 지우고 `promise`를 남기면, 그 자연스러운 코드는 실험 3처럼 **영원히 loading에 멈춘다** **2. 바깥 배치로 하던 일은 기존 훅으로 된다** - 자식이 promise를 받는 대신 같은 키로 useSuspenseQuery를 부르면 된다(다음 장) - 조건에 따라 suspend하고 싶다면 queryFn 안에서 조건을 검사해 `null`을 돌려주고, 그 조건을 queryKey에 넣는다(TkDodo, #10733) --- ## 실험 6: promise 없이 같은 배치를 만들면 ```jsx function Parent() { useQuery({queryKey: ['user'], queryFn}) // 부모도 데이터가 필요하다면 return ({data}
} ``` | 5.104.1 | queryFn | 화면 | | ------------------------------------- | ------- | ---- | | 부모 useQuery + 자식 useSuspenseQuery | 1회 | 정상 | | 자식 useSuspenseQuery만 | 1회 | 정상 | 같은 키는 서가에서 책 한 권으로 모인다. 신청서가 몇 장이든 책을 가지러 가는 것은 한 번이다. --- ## 질문 네 개, 다시 | 질문 | 답 | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | 1. 재시도는 리렌더인가 리마운트인가 | 한 번도 커밋되지 않았다면 리마운트와 같다. `useState`가 매번 새로 만들어진다 | | 2. 렌더 중 요청이 왜 괜찮은가 | 몇 번 렌더돼도 요청은 한 번이고 결과는 컴포넌트 밖에 남는다. 렌더가 버려져도 잃는 것이 없다 | | 3. useQuery에는 왜 그 옵션이 없나 | useQuery는 커밋 뒤 구독할 때 요청한다. 스스로 suspend하면 커밋도, 구독도, 요청도 없다 | | 4. 있던 옵션은 왜 사라졌나 | 같은 컴포넌트 suspend를 메우던 꼼수라서 걷어냈다. 바깥 배치는 멀쩡했지만 `promise`와 함께 사라졌다(이유는 기록에 없다) | 넷 다 "처음 마운트되는 중에 suspend된 컴포넌트는 아무것도 남기지 못한다"에서 나온다. --- ## 확인 문제 ```jsx function Providers({children}) { const [client] = useState(() => new QueryClient()) return