리액트 서스펜스의 내부 작동 원리: 프로미스를 던지기와 선언적 비동기 UI

자바스크립트 throw 는 함수 호출을 동기적으로 중단시킨다. 리액트는 렌더 함수에서 throw 된 값이 프로미스이면 "이 컴포넌트는 아직 준비 안 됨"이라 해석하고 가장 가까운 <Suspense> 의 fallback 을 그린다.

function PhoneDetails() {
  const details = use(phoneDetailsPromise);
  // 여기 도달했다는 건 details 가 준비됐다는 뜻
}

// 잘못: 매 렌더마다 새 fetch
function Bad() {
  const p = fetch('/api').then(r => r.json());
  return <Inner promise={p} />;
}

// 올바름: 모듈/이벤트 스코프
const phoneDetailsPromise = fetch('/api/phone-details').then(r => r.json());

프로미스가 렌더 함수 안에서 만들어지면 매 렌더마다 새 요청·새 참조가 되어 무한 루프 같은 현상.

로딩과 에러는 다른 메커니즘이지만 같은 자리에서 묶는다.

<ErrorBoundary fallback={<div>문제가 발생했습니다.</div>}>
  <Suspense fallback={<div>로딩 중...</div>}>
    <PhoneDetails />
  </Suspense>
</ErrorBoundary>

resolve → 정상 렌더, pending → fallback, reject → ErrorBoundary 셋이 모두 자동.

let userPromise;
function fetchUser() {
  userPromise = userPromise ?? fetch('/api/user').then(r => r.json());
  return userPromise;
}

React Query/TanStack Query/SWR/react-cache 같은 도구가 "같은 키 → 같은 프로미스" 를 보장해 fallback 깜빡임과 중복 요청을 막는다.

[감점 답변] "로딩 fallback 을 보여준다" 만. [좋은 답변] (1) 컴포넌트가 준비 안 된 데이터에 접근하면 프로미스를 throw, (2) 리액트가 catch 해 가장 가까운 <Suspense> fallback 렌더, (3) 프로미스 resolve 시 다시 렌더, reject 시 ErrorBoundary. 자바스크립트 throw 가 동기 함수 흐름을 즉시 중단 한다는 사실을 활용한 트릭이라는 점이 핵심.

[감점 답변] "코드가 짧다". [좋은 답변] (1) 선언적: 로딩·에러 상태를 컴포넌트 안에서 직접 관리하지 않음. (2) 조합 가능: Suspense/ErrorBoundary 와 자연스럽게 결합. (3) 렌더-애즈-유-페치 호환: 라우트 로더에서 시작한 프로미스를 그대로 받기. (4) 조건부 호출 가능: hooks 규칙의 예외로 조건부 호출이 허용된다.

[감점 답변] "빨리 끝나면 된다". [좋은 답변] (1) 요청 중복 제거: 같은 키 → 같은 프로미스 (React Query 등). (2) useTransition 으로 전환을 "낮은 우선순위"로 표시해 이전 UI 유지. (3) unstable_Activity 로 첫 렌더 결과 보관. (4) 라우트 prefetch + 캐시. "trickle 깜빡임"의 원인을 분리해서 답하면 깊이가 보인다.