renderToReadableStream
은 React 트리를 읽기 가능한 웹 스트림으로 렌더링합니다.const stream = await renderToReadableStream(reactNode, options?)
Note
이 API는 웹 스트림에 의존합니다. Node.js의 경우, 대신
renderToPipeableStream
을 사용하세요.참조
renderToReadableStream(reactNode, options?)
renderToReadableStream
을 호출하면 React 트리를 HTML로 읽기 가능한 웹 스트림으로 렌더링합니다.클라이언트에서
hydrateRoot
를 호출하면 서버에서 생성된 HTML을 상호작용이 가능하도록 만듭니다.매개변수
reactNode
: HTML로 렌더링하려는 React 노드. 예를 들어,<App />
과 같은 JSX 엘리먼트입니다. 전체 문서를 나타낼 것이므로,App
컴포넌트는<html>
태그를 렌더링해야 합니다.
- optional
options
: 스트리밍 옵션이 있는 객체. - optional
bootstrapScriptContent
: 지정하면 이 문자열이 인라인<script>
태그에 배치됩니다. - optional
bootstrapScripts
: 페이지에 표시할<script>
태그의 문자열 URL 배열.hydrateRoot
를 호출하는<script>
를 포함하고자 할 때 사용하세요. 클라이언트에서 React를 아예 실행하지 않으려면 생략하세요. - optional
bootstrapModules
:bootstrapScripts
와 비슷하지만, 대신<script type="module">
을 출력합니다. - optional
identifierPrefix
: React가useId
에 의해 생성된 ID에 사용하는 문자열 접두사. 같은 페이지에서 여러 루트를 사용할 때 충돌을 피하는 데 유용합니다.hydrateRoot
에 전달된 접두사와 동일해야 합니다. - optional
namespaceURI
: 스트림의 루트 namespace URI가 포함된 문자열. 기본값은 일반 HTML입니다. SVG의 경우'http://www.w3.org/2000/svg'
를, MathML의 경우'http://www.w3.org/1998/Math/MathML'
을 전달합니다. - optional
nonce
:script-src
콘텐츠 보안 정책에 대한 스크립트를 허용하는nonce
문자열. - optional
onError
: 복구 가능 혹은 불가능 여부에 관계 없이 서버 오류가 발생할 때마다 실행되는 콜백. 기본적으로console.error
만 호출합니다. 이 함수를 재정의하여 로그 충돌 보고서를 기록하도록 한 경우에도 여전히console.error
를 호출해야 합니다. 셸이 출력되기 전에 상태 코드를 조정하는 데 사용할 수도 있습니다. - optional
progressiveChunkSize
: 청크의 바이트 수. 기본 휴리스틱에 대해 자세히 알아보세요. - optional
signal
: 서버 렌더링을 중단하고 나머지는 클라이언트에서 렌더링하도록 하는 중단 신호.
반환값
renderToReadeableStream
은 프로미스를 반환합니다:- 셸을 렌더링하는 데 성공하면, 해당 프로미스는 읽기 가능한 웹 스트림으로 리졸브됩니다.
- 셸 렌더링에 실패하면 프로미스가 거부됩니다. 이를 사용하여 폴백 셸을 출력합니다.
반환된 스트림에는 추가 속성이 있습니다:
allReady
: 셸과 모든 추가 콘텐츠를 포함하여 렌더링이 전부 완료되면 리졸브되는 프로미스. 크롤링 및 정적 생성시 응답을 반환하기 전에await stream.allReady
를 실행할 수 있습니다. 이렇게 하면 점진적 로딩이 동작하지 않고, 스트림에는 최종 HTML이 포함됩니다.
사용법
React 트리를 가독성 있는 웹 스트림에 HTML로 렌더링하기
renderToReadableStream
을 호출하여 React 트리를 HTML로 읽기 가능한 웹 스트림에 렌더링합니다.root component와 함께 bootstrap
<script>
paths 경로 목록을 제공해야 합니다. 루트 컴포넌트는 루트 <html>
태그를 포함한 전체 문서를 반환해야 합니다.예를 들어, 아래와 같을 것입니다:
이렇게 하면 서버에서 생성된 HTML에 이벤트 리스너가 첨부되어 상호작용이 가능해 집니다.
DEEP DIVE | 심층 탐구
빌드 출력에서 CSS 및 JS asset 경로 읽기
최종 에셋 URL(예: JavaScript 및 CSS 파일)은 빌드 후에 해시 처리되는 경우가 많습니다. 예를 들어,
styles.css
대신 styles.123456.css
로 끝날 수 있습니다. 정적 에셋 파일명을 해시하면 동일한 에셋의 모든 개별 빌드에 다른 파일명이 지정됩니다. 이는 정적 자산에 대한 장기 캐싱을 안전하게 활성화할 수 있기 때문에 유용합니다. 특정 이름을 가진 파일은 콘텐츠를 변경하지 않습니다.하지만 빌드가 끝날 때까지 에셋 URL을 모르는 경우 소스 코드에 넣을 방법이 없습니다. 예를 들어, 앞서와 같이 JSX에
"/styles.css"
를 하드코딩하면 작동하지 않을 것입니다. 소스 코드에 포함되지 않으면서 빌드 시점에 에셋을 로드하기 위해, 루트 컴포넌트가 prop으로 전달된 맵에서 실제 파일명을 읽는 방식을 생각해 봅시다:서버에서
<App assetMap={assetMap} />
을 렌더링하고 에셋 URL과 함께 assetMap
을 전달합니다:이제 서버가
<App assetMap={assetMap} />
를 렌더링하고 있으므로, 클라이언트에서도 assetMap
을 사용하여 렌더링해야 하이드레이션 오류를 방지할 수 있습니다. 다음과 같이 assetMap
을 직렬화하여 클라이언트에 전달할 수 있습니다:위의 예시에서
bootstrapScriptContent
옵션은 클라이언트에서 전역 window.assetMap
변수를 설정하는 별도의 인라인 <script>
태그를 추가합니다. 이렇게 하면 클라이언트 코드가 동일한 assetMap
을 읽을 수 있습니다:클라이언트와 서버 모두 동일한
AssetMap
프로퍼티로 App
을 렌더링하므로 하이드레이션 오류가 발생하지 않습니다.콘텐츠가 로드되는 동안 더 많은 콘텐츠 스트리밍하기
스트리밍을 사용하면 모든 데이터가 서버에 로드되기 전에도 콘텐츠를 보기 시작할 수 있습니다. 예를 들어, 표지와 친구 및 사진이 있는 사이드바나, 게시물 목록이 표시되는 프로필 페이지를 생각해 보세요:
<Posts />
에 대한 데이터를 로드하는 데 시간이 좀 걸린다고 가정해 보겠습니다. 이상적으로는 게시물을 기다리지 않고 나머지 프로필 페이지 콘텐츠를 표시하고 싶을 것입니다. 이렇게 하려면 <Posts />
를 <Suspense>
경계로 감싸면 됩니다:이는
Posts
가 데이터를 로드하기 전에 HTML 스트리밍을 시작하도록 React에 지시합니다. React는 로딩 폴백(PostsGlimmer
)을 위한 HTML을 먼저 전송한 다음, Posts
가 데이터 로딩을 완료하면 나머지 HTML를 인라인 <script>
태그(기존 로딩 폴백을 HTML로 대체하는)와 함께 전송합니다. 사용자 관점에서 볼 때, 페이지는 먼저 PostsGlimmer
로 표시되었다가 나중에 Posts
로 대체될 것입니다.<Suspense>
경계를 더 중첩하여 더 세분화된 로딩 시퀀스를 만들 수도 있습니다:이 예제에서 React는 페이지 스트리밍을 더 일찍 시작할 수 있습니다.
ProfileLayout
과 ProfileCover
만 <Suspense>
경계로 둘러싸여 있지 않기 때문에 먼저 렌더링을 완료해야 합니다. 그러나 Sidebar
, Friends
, 혹은 Photos
에 일부 데이터를 로드해야 하는 경우, React는 대신 BigSpinner
폴백을 위한 HTML을 전송할 것입니다. 이후로는 가용 데이터가 늘어날 때마다 더 많은 컨텐츠가 표시되다가, 결국 모든 데이터가 전부 표시될 것입니다.스트리밍은 브라우저에서 React 자체가 로드되거나 상호작용이 가능해질 때까지 기다릴 필요가 없습니다. 서버의 HTML 콘텐츠는
<script>
태그가 로드되기 전에도 점진적으로 표시됩니다.Note
오직 Suspense를 도입한 데이터 소스에서만 Suspense 컴포넌트를 활성화할 수 있습니다. 여기에는 다음이 포함됩니다:
lazy
를 사용한 지연 로딩 컴포넌트 코드
Suspense는 Effect나 이벤트 핸들러 내부에서 페칭하는 경우를 감지하지 않습니다.
위의
Posts
컴포넌트에서 데이터를 로드하는 정확한 방법은 프레임워크에 따라 다릅니다. Suspense를 도입한 프레임워크를 사용하는 경우, 해당 프레임워크의 데이터 페칭 문서에서 자세한 내용을 확인할 수 있을 것입니다.잘 알려진 프레임워크를 사용하지 않고 데이터 페칭에 Suspense를 도입하는 방법은 아직 지원되지 않습니다. Suspense를 도입한 데이터 소스를 구현하기 위한 요구 사항은 불안정하고 문서화되지 않았습니다. 데이터 소스를 Suspense와 통합하기 위한 React 공식 API는 미래에 출시할 계획입니다.
셸에 들어갈 내용 지정하기
경계 밖에 있는 부분을 셸이라고 합니다:
이는 사용자가 볼 수 있는 가장 빠른 로딩 state를 결정합니다:
전체 앱을 루트의
<Suspense>
경계로 감싸면 셸에는 해당 스피너만 포함됩니다. 하지만 이는 사용자 경험상 좋지 않습니다. 화면에 큰 스피너가 표시되었다가 실제 레이아웃으로 전환되는 방식이, 아무것도 없는 화면에서 잠시 기다렸다가 곧바로 실제 레이아웃을 표시하는 방식보다 오히려 더 느리거나 성가시게 느껴질 수 있기 때문입니다. 때문에 일반적으로 셸이 전체 페이지 레이아웃의 골격과 같이 최소한이면서 완성된 무언가로 느껴지도록 <Suspense>
경계를 배치하는 것이 좋습니다.renderToReadableStream
에 대한 비동기 호출은 전체 셸이 렌더링되는 즉시 stream
으로 리졸브됩니다. 보통 해당 stream
으로 응답을 생성하고 반환함으로써 스트리밍을 시작합니다:stream
이 반환될 때 중첩된 <Suspense>
경계에 있는 컴포넌트는 여전히 데이터를 로드하고 있을 수 있습니다.서버에서의 충돌을 기록하기
기본적으로 서버의 모든 오류는 콘솔에 기록됩니다. 이 동작을 재정의하여 충돌 보고서를 기록할 수 있습니다:
사용자 정의
onError
구현을 제공하는, 경우 위와 같이 콘솔에도 오류를 기록하는 것을 잊지 마세요.셸 내부에서 오류 복구하기
다음 예제에서 셸에는
ProfileLayout
, ProfileCover
, PostsGlimmer
가 포함되어 있습니다:이 컴포넌트들을 렌더링하는 동안 오류가 발생하면 React는 클라이언트에 보낼 의미 있는 HTML을 갖지 못할 것입니다. 이럴 경우에 대한 마지막 수단으로 서버 렌더링에 의존하지 않는 폴백 HTML을 보내려면
onShellError
를 재정의하세요:셸을 생성하는 동안 오류가 발생하면
onError
와 onShellError
가 모두 실행됩니다. 오류 보고에는 onError
를 사용하고, 폴백 HTML 문서 전송에는 onShellError
를 사용하세요. 폴백 HTML은 반드시 오류 페이지일 필요는 없습니다. 대신 클라이언트에서만 앱을 렌더링하는 대체 셸을 포함할 수도 있습니다.셸 외부에서 오류 복구하기
다음 예제에서
<Posts />
컴포넌트는 <Suspense>
로 래핑되어 있으므로 셸의 일부가 아닙니다:Posts
컴포넌트 또는 그 내부 어딘가에서 오류가 발생하면 React는 이를 복구하려고 시도합니다:- 가장 가까운
<Suspense>
경계(PostsGlimmer
)에 대한 로딩 폴백을 HTML에 방출합니다.
- 더 이상 서버에서
Posts
콘텐츠를 렌더링하려는 시도를 “포기”합니다.
- JavaScript 코드가 클라이언트에서 로드되면, React는 클라이언트에서
Posts
렌더링을 다시 시도합니다.
클라이언트에서
Posts
렌더링을 다시 시도해도 실패하면, React는 클라이언트에서 오류를 던집니다. 렌더링 중에 발생하는 모든 에러와 마찬가지로, 가장 가까운 상위 에러 경계에 따라 사용자에게 에러를 표시하는 방법이 결정됩니다. 보다 실질적으로는, 오류를 복구할 수 없다는 것이 확실해질 때까지 로딩 표시기가 표시됩니다.클라이언트에서
Posts
렌더링을 다시 시도하여 성공하면 서버의 로딩 폴백이 클라이언트 렌더링 출력물로 대체됩니다. 사용자는 서버 오류가 발생했다는 사실을 알 수 없습니다. 그러나 서버의 onError
콜백 및 클라이언트의 onRecoverableError
콜백이 실행되므로 오류에 대한 알림을 받을 수는 있습니다.상태 코드 설정하기
스트리밍에는 장단점이 있습니다. 사용자가 콘텐츠를 더 빨리 볼 수 있도록 가능한 한 빨리 페이지 스트리밍을 시작하고 싶을 수 있습니다. 하지만 스트리밍을 시작하면 더 이상 응답 상태 코드를 설정할 수 없습니다.
앱을 셸(특히
<Suspense>
경계)과 나머지 콘텐츠로 나누면, 이 문제의 일부를 이미 해결한 것입니다. 셸에서 오류가 발생하면 오류 상태 코드를 설정할 수 있는 onShellError
콜백을 받게 됩니다. 그렇지 않으면 앱이 클라이언트에서 복구될 수 있으므로 “OK”를 보낼 수 있습니다.셸 외부에 있는 컴포넌트(예:
<Suspense>
경계 안에 있는 컴포넌트)가 에러를 던져도 React는 렌더링을 멈추지 않습니다. 즉, onError
콜백이 실행됨에도 불구하고 코드는 여전히 catch
블록에 진입하지 않고 계속 실행됩니다. 이는 위에서 설명한 것처럼 React가 클라이언트에서 해당 오류를 복구하려고 시도하기 때문입니다.하지만 원한다면 오류가 발생했다는 사실로부터 상태 코드를 설정할 수도 있습니다:
이는 초기 셸 콘텐츠를 생성하는 동안 발생한 셸 외부의 오류만 포착하므로 완전한 것은 아닙니다. 일부 콘텐츠에서 오류가 발생했는지 여부를 파악하는 것이 중요하다면 셸 내부로 이동시키세요.
다양한 방식으로 오류 처리하기
자신만의
Error
서브클래스를 생성하고 instanceof
를 사용하여 어떤 오류가 발생했는지 확인할 수도 있습니다. 예를 들어, 사용자 정의 NotFoundError
를 정의하고 컴포넌트에서 이를 던질 수 있습니다. 그런 다음 오류를 onError
에 저장하고, 오류 유형에 따라 응답을 반환하기 전에 다른 작업을 수행할 수 있습니다:셸을 내보내고 스트리밍을 시작하면 상태 코드를 변경할 수 없다는 점에 유의하세요.
크롤러 및 정적 생성시 모든 콘텐츠가 로드될 때까지 기다리기
스트리밍은 사용자가 콘텐츠를 사용할 수 있게 되는 즉시 볼 수 있기 때문에 더 나은 사용자 경험을 제공합니다.
그러나 크롤러가 페이지를 방문하거나 빌드 시점에 페이지를 생성하는 경우에는, 점진적으로 표시하는 대신 모든 콘텐츠가 먼저 로드된 다음 최종 HTML 출력을 생성하는 것이 좋을 수 있습니다.
onAllReady
프로미스를 사용하면 모든 콘텐츠가 로드될 때까지 기다릴 수 있습니다:일반 방문자는 점진적으로 로드되는 콘텐츠 스트림을 받게 됩니다. 크롤러는 모든 데이터가 로드된 후 최종 HTML 출력을 받게 됩니다. 그러나 이는 크롤러가 모든 데이터를 기다려야 한다는 것을 의미하며, 그 중 일부는 로드 속도가 느리거나 오류가 발생할 수도 있습니다. 앱에 따라서는 크롤러에도 셸을 보내도록 선택할 수 있습니다.
서버렌더링 중단하기
시간 초과 후 서버 렌더링을 “포기”하도록 강제할 수 있습니다:
React는 기존 로딩 폴백을 HTML로 플러시하고 나머지는 클라이언트에서 렌더링을 시도합니다.