(번역) 리액트 렌더링의 미래

18 min readOct 19, 2022

원문: https://prateeksurana.me/blog/future-of-rendering-in-react/

UI 제작 라이브러리로서 리액트의 인기는 시간이 지날수록 점점 더 빠르게 증가하고 있습니다. 라이브러리 인기도를 나타내는 정확한 지표가 아니라는 것은 알지만, 이 글을 작성하는 시점에 1,400만 이상의 주간 npm 다운로드가 있으며 크롬 확장 프로그램인 React Devtools의 주간 활성 사용자도 300만명이 넘습니다. 하지만, 리액터 렌더링 패턴은 리액트 18까지 거의 변하지 않았습니다.

이 글은 현재 리액트의 렌더링 패턴과 문제점, 그리고 리액트 18에 도입된 새로운 패턴이 이런 문제를 어떻게 해결하려고 하는지를 살펴보려고 합니다.

동영상을 더 선호하시는 분이 많을까요? 저는 이 주제에 대해 리액트 뱅걸로에서 발표 했습니다. 이곳에서 확인해주세요!

웹 바이탈 용어

렌더링 패턴에 대해 알아보기 전에 글 전반에서 사용될 몇 가지 웹 바이탈 용어를 살펴보겠습니다.

Time To First Byte (TTFB) — 클라이언트 측에서 콘텐츠의 첫 번째 바이트를 수신하는 데 걸린 시간
First Paint (FP) — 첫 픽셀이 사용자에게 표시되는 시간
First Contentful Paint (FCP) — 컨텐츠의 첫 번째 부분이 표시되는 데 걸린 시간
Largest Contentful Paint (LCP) — 페이지의 주요 콘텐츠가 로딩되는 데 걸리는 시간
Time To Interactive (TTI) — 페이지가 상호작용이 가능해지고 사용자 이벤트에 안정적으로 응답하게 되는데 걸린 시간

현재 사용되는 렌더링 패턴

현재 리액트에서 사용하는 가장 일반적인 패턴은 클라이언트 사이드 렌더링과 서버 사이드 렌더링, 그리고 Next.js 같은 프레임워크에서 제공하는 정적 사이트 생성(Static Site Generation, SSG), 증분 정적 재생성(Incremental Static Regeneration, ISR) 같은 고급 서버 렌더링 방식이 있습니다. 이 패턴을 각각 살펴보고 리액트 18에 도입되어 앞으로 사용할 수 있는 새로운 패턴도 함께 살펴보겠습니다.

클라이언트 사이드 렌더링(Client-Side Rendering, CSR)

클라이언트 사이드 렌더링은 Next.js 및 Remix 같은 메타 프레임워크가 등장하기 전까지 리액트 앱을 빌드하기 위한 가장 기본 방식이었습니다. create-react-app 또는 유사한 스타터를 사용할 때 주로 사용하게 됩니다.

CSR을 사용하면 서버는 모든 페이지에 대해 필요한 스크립트 및 link 태그가 포함된 기본 HTML만 제공합니다. 관련 자바스크립트 파일이 브라우저에 다운로드되면 리액트는 트리를 렌더링하고 모든 DOM노드를 생성합니다. 또한, 라우팅 및 데이터 페칭을 위한 모든 로직은 클라이언트 자바스크립트에서 처리됩니다.

작동 방식을 확인하기 위해 아래 앱을 렌더링 한다고 가정해보겠습니다.

위 앱의 렌더링 사이클은 다음과 같습니다.

그리고 네트워크 그래프는 다음과 같습니다.

CSR 앱은 대부분 정적 자산에 의존하기 때문에 TTFB가 빠릅니다. 하지만 사용자들은 해당 자바스크립트가 다운로드될 때까지 빈 화면을 응시해야 합니다. 그 후에 대부분의 실제 앱은 사용자에게 표시하기 위해 관련 데이터를 API를 통해 가져와야 하므로 LCP도 매우 느려집니다.

️✔️ CSR의 장점

클라이언트 사이드 렌더링 아키텍처는 정적 파일로 구성되어 있어 CDN을 통해 쉽게 제공할 수 있습니다.
모든 렌더링을 클라이언트에서 수행해 전체 페이지 리프레시 없이 네비게이션이 가능하므로 좋은 UX를 제공합니다.
TTFB까지의 시간이 빠르므로 브라우저는 글꼴, CSS 및 자바스크립트를 즉시 로드할 수 있습니다.

✔️ CSR의 ️문제점

모든 콘텐츠가 클라이언트에서 렌더링되기 때문에 사용자가 페이지의 콘텐츠를 보려면 먼저 콘텐츠를 다운로드하고 처리해야 합니다. 그래서 성능이 크게 저하됩니다.
클라이언트 사이드 렌더링 앱은 일반적으로 컴포넌트 마운트 시점에 데이터를 페칭하기 때문에 초기 페이지 로드에서 많은 로더를 맞이합니다. 이런 부분은 나쁜 사용자 경험으로 이어집니다. 또한, 자식 컴포넌트에 데이터 페칭이 있지만 상위 컴포넌트가 모든 데이터를 가져올 때까지 렌더링 되지 않는 경우 상황이 더 악화 될 수 있습니다. 이로인해 로더의 연속성과 잘못된 네트워크 워터폴이 발생할 수 있습니다.
마지막으로, SEO에서 문제가 있을 수 있습니다. 웹 크롤러는 서버에서 렌더링된 HTML을 쉽게 읽을 수 있지만 모든 자바스크립트 번들을 다운로드하고 실행하고, 모든 데이터 페칭이 완료될 때까지 기다리지 않을 수 있습니다. 이는 부적절한 인덱싱으로 이어질 수 있습니다.

서버 사이드 렌더링

현재 리액트에서 서버 사이드 렌더링이 동작하는 방식은 다음과 같습니다.

관련 데이터를 페칭한 뒤, renderToString 메서드를 통해 서버에서 클라이언트 사이드의 자바스크립트를 실행합니다. renderToString 메서드는 페이지 표시에 필요한 모든 HTML을 제공합니다.
이 HTML은 클라이언트 측에 제공되어 빠른 FCP로 이어집니다.
그러나 모든 게 끝난 것은 아닙니다. 페이지가 상호작용할 수 있도록 자바스크립트 로직을 서버에서 생성한 HTML에 연결하기 위해 클라이언트 측에서 자바스크립트를 다운로드하고 실행해야 합니다. (이 과정을 “하이드레이션(hydration)”이라고 합니다) 하이드레이션이 필요한 이유와 작동 원리가 궁금하다면 Josh의 Perils of Rehydration 글을 확인하세요.

작동 방식을 더 잘 이해하기 위해 이전 섹션에서 본 것과 동일한 앱을 SSR로 구현한 앱의 생명주기를 살펴보겠습니다.

그리고 네트워크 그래프는 다음과 같습니다.

SSR을 사용하면 좋은 FCP와 LCP를 얻을 수 있지만, 서버에서 데이터를 가져와 HTML 문자열로 변환해야 하므로 TTFB 부분에서 문제가 됩니다.

이제 Next.js의 SSG/ISR이 이 문제에 적합한 해결책인지 따져 보겠습니다. 두 방식 또한 위에서 본 것과 같은 과정을 거쳐야 합니다. 유일한 차이점은 HTML이 빌드 시 생성되거나 요청이 들어올 때 증분식으로 생성 및 캐시 되기 때문에 느린 TTFB로 고통받지 않는다는 점입니다.

그러나 SSG/ISR은 만병통치약이 아닙니다. 제 경험상 공개된 페이지에서 잘 동작하지만, 사용자에 로그인이 필요하거나 브라우저에 저장된 쿠키에 따라 변경되는 페이지의 경우 SSR을 사용해야 합니다.

✔️ SSR의 이점

CSR과 달리 모든 HTML이 서버에서 미리 생성되기 때문에, SEO 측면에서 웹 크롤러가 이를 크롤링하는데 문제가 없어 좋습니다.
FCP와 LCP가 꽤 빠릅니다. 따라서 사용자는 CSR 앱과 달리 빈 화면 대신 무언가 볼 화면이 있을 것입니다.

️️✔️ ️SSR의 문제점

페이지에 대한 데이터 요구사항이 있는 경우, 모든 요청을 서버에서 기다렸다가 렌더링해야 하므로 느린 TTFB가 발생할 수 있습니다. 이 때문에 사용자는 브라우저 로딩 스피너를 계속해서 봐야 할 수 있습니다. 이는 최적화되지 않은 서버 코드 또는 많은 동시 서버 요청 등 여러 이유로 발생할 수 있습니다. 하지만 Next.js와 같은 프레임워크가 SSG나 ISR같은 기술을 사용해 미리 페이지를 생성하고 캐싱할 수 있도록 해 이런 문제는 어느 정도 해결되었습니다.
마지막으로 초기 로드가 아무리 빠르더라도, 사용자는 여전히 페이지가 모든 자바스크립트를 다운로드하고 페이지가 리하이드레이션(rehydrate)된 뒤 상호작용이 가능할 때까지 기다려야 합니다.

새로운 렌더링 패턴

이전 섹션에서 현재 리액트 렌더링 패턴과 어떤 문제가 있는지 살펴봤습니다. 정리해보면,

CSR 앱에서 사용자는 필요한 모든 자바스크립트를 다운로드하고 실행해야 페이지를 실행/상호작용할 수 있습니다.
SSR을 사용하면 서버에서 HTML을 생성해 CSR의 문제 일부를 해결합니다. 하지만 모든 데이터를 먼저 가져오고 HTML을 생성하기 위해 서버에서 기다려야하기 때문에 아직 최적은 아닙니다. 이후 클라이언트는 전체 페이지에 대한 자바스크립트를 다운로드 합니다. 마지막으로 서버에서 생성한 HTML과 자바스크립트 로직을 실행하기 위해 자바스크립트 코드를 실행해 리액트 하이드레이션 과정을 거칩니다. 이런 과정의 가장 큰 문제는 다음 단계를 시작하기 전에 각 단계가 완료될 때까지 기다려야 한다는 것입니다.

리액트 팀은 이런 문제를 해결하기 위해 몇 가지 새로운 패턴을 연구하고 있습니다.

스트리밍 SSR

브라우저의 멋진 점 중 하나는 HTTP 스트림을 통해 HTML을 수신할 수 있다는 점입니다. 스트리밍을 사용하면 웹 서버가 무기한으로 열려있을 수 있는 단일 HTTP 연결을 통해 클라이언트에 데이터를 보낼 수 있습니다. 따라서 네트워크를 통해 여러 청크로 데이터를 로드할 수 있으며, 이는 렌더링과 동시에 순서 없이 로드됩니다.

만약 스트리밍이 실제로 어떻게 작동하는지 궁금하다면 Hydrogen팀의 스트리밍 SSR글을 확인해보세요.

리액트 18 이전의 스트리밍

스트리밍 렌더링은 리액트 18에서 새롭게 등장한 것은 아닙니다. 사실, 리액트 16부터 존재했습니다. 리액트 16에서는 renderToString과는 다른 renderToNodeStream라는 API가 존재했습니다. 이 API는 브라우저 HTTP 스트림을 통해 렌더링을 수행합니다.

이를 통해 HTML을 렌더링과 동시에 청크로 보낼 수 있게 되어 브라우저에 초기 마크업이 더 빠르게 도착하기 때문에 더 나은 FTTB 및 LCP 지표를 얻게 됩니다.

Max Stoiber는 자신의 글에서 사용한 스펙트럼을 통해 차이점을 잘 설명했습니다.

리액트 18에서의 스트리밍 SSR

리액트 18에서는 renderToNodeStream API를 deprecate 시키고 renderToPipeableStream이란 새로운 API를 소개했습니다. 이 API는 Suspense로 몇 가지 새로운 기능을 가능하게 했습니다. Suspense는 앞서 봤던 SSR의 단계를 독립적으로 수행 가능한 더 작은 독립 단위로 나눌 수 있습니다. 이것은 Suspense에 추가된 두 주요 기능 때문에 가능합니다.

서버에서의 스트리밍 HTML
클라이언트에서의 선택적 하이드레이션

✔️ 서버에서의 스트리밍 HTML

앞서 말했듯이, 리액트 18 이전의 SSR은 전부 아니면 전무(all or nothing)방식으로 접근했습니다. 페이지에 필요한 모든 데이터를 페칭한 뒤 HTML을 생성하고 클라이언트에 보내야 했습니다. 하지만 HTTP 스트리밍 덕분에 더 이상 그러지 않아도 됩니다.

리액트 18에서는 로드 시간이 오래 걸리거나 화면에 즉시 나타내 주지 않아도 되는 컴포넌트를 Suspense로 래핑해 처리할 수 있습니다. 작동 방식을 이해하기 위해 Comments API가 느리다고 가정하고 Comments 컴포넌트를 Suspense로 래핑 하겠습니다.

이렇게 하면 초기 HTML에는 Comments 컴포넌트가 없고, 초기에는 해당 위치에 폴백 스피너를 가져옵니다.

마지막으로 서버에서 Comments에 대한 데이터가 준비되면 리액트는 HTML을 올바른 위치에 배치하기 위해 인라인 스크립트 태그를 사용해 동일한 스트림에 최소한의 HTML을 보냅니다.

이런 방식으로 서버에서 모든 데이터를 페칭할 때까지 기다릴 필요가 없어졌습니다. 또한, 일부가 준비되지 않은 경우에도 브라우저가 앱의 나머지 부분을 렌더링할 수 있기 때문에 첫 번째 문제를 해결합니다.

✔️ 선택적 하이드레이션

HTML이 스트리밍 되더라도 페이지에 대한 전체 자바스크립트가 다운로드되지 않는 한 사용자와의 상호작용은 이뤄지지 않습니다. 선택적 하이드레이션이 필요한 지점입니다.

클라이언트 사이드 렌더링 중 페이지의 큰 번들을 피하는 방법 중 한 가지는 React.lazy를 통한 코드 스플리팅이었습니다. 앱의 특정 부분이 동기식으로 로드될 필요가 없을 때 번들러가 이를 별도의 스크립트 태그로 분할해줍니다.

React.lazy의 한계는 서버 사이드 렌더링에서 작동하지 않는 점이었지만, 리액트 18에서는 <Suspense>를 사용해 HTML을 스트리밍 하는 것뿐만 아니라 나머지 앱에 대한 하이드레이션을 차단하지 않게 할 수 있습니다.

이제 React.lazy는 서버에서 바로 사용할 수 있습니다. <Suspense>를 지연 로드되는 컴포넌트에 래핑 하면 이 컴포넌트가 스트리밍을 원한다는 것을 알려줄 뿐만 아니라 <Suspense>로 래핑 된 컴포넌트가 스트리밍 되는 경우에도 나머지의 하이드레이션을 허용합니다. 이런 점은 기존 서버 사이드 렌더링에서 봤던 두 번째 문제를 해결합니다. 더 이상 하이드레이션을 시작하기 전에 모든 자바스크립트가 다운로드될 때까지 기다릴 필요가 없습니다.

다시 Suspense로 래핑 된 Comments와 Suspense 아키텍처를 사용하는 앱의 수명 주기를 살펴보겠습니다.

이 예제는 다음과 같은 네트워크 그래프를 갖습니다.

다시 말하지만, 이 예시는 매우 인위적입니다. 그러나 이 예제가 말하려는 것은 Suspense를 사용하면 연속적으로 일어나던 많은 일들이 병렬적으로 일어난다는 것입니다.

이는 HTML이 스트리밍되기 때문에 더 빠른 TTFB를 얻는 데 도움이 될 뿐만 아니라 사용자가 앱과 상호작용하기 위해 모든 자바스크립트가 다운로드될 때까지 기다릴 필요가 없다는 것을 말합니다. 이 네트워크에 나타나지 않은 또 다른 이점으로는 Ryan이 그의 발표에서 이야기했듯이 페이지가 스트리밍을 시작하는 즉시 다른 자산(CSS, 자바스크립트, 폰트 등)을 로드하여 더 많은 요청을 병렬화 하는데 도움이 된다는 것입니다.

또 다른 멋진 점은 Suspense로 래핑 된 여러 컴포넌트가 있고 아직 클라이언트에서 하이드레이션이 발생하지 않았을 때 사용자가 특정 컴포넌트와 상호작용하기 시작한다면 해당 컴포넌트 하이드레이션을 우선시한다는 점입니다. 이 새로운 Suspense 아키텍처 토론에서 이 내용과 위에서 논의한 모든 사항을 더 자세히 확인할 수 있습니다.

서버 컴포넌트 (알파)

마지막 섹션에서 우리는 앱을 더 작은 단위로 나누고 별도 스트리밍 및 하이드레이션으로 서버 사이드 렌더링 성능을 향상시키는 방법을 살펴봤습니다. 그러나 애플리케이션의 일부를 하이드레이션 할 필요가 없는 방법이 있다면 어떤가요?

자, 이 지점이 서버 컴포넌트 RFC가 등장한 지점입니다. 서버 사이드 렌더링을 보완하고 새로운 서버 컴포넌트를 통해 서버에서만 렌더링 되고 상호 작용이 없는 컴포넌트를 사용할 수 있습니다.

간단한 개요를 말하자면, 작동 방식은 .server.js/jsx/ts/tsx 확장자를 통해 상호작용이 필요 없는 서버 컴포넌트를 생성할 수 있습니다. 그다음 페이지의 상호작용이 필요한 클라이언트 컴포넌트(.client.js/jsx/ts/tsx 확장자로 작성된)에 프로퍼티를 원활하게 통합하고 전달할 수 있습니다. 제공하는 기능에 대한 자세한 목록은 다음과 같습니다.

제로 클라이언트 사이드 번들: 서버 컴포넌트는 서버에서만 렌더링 되며 하이드레이션이 필요가 없습니다. 클라이언트 사이드 번들 크기에 영향을 미치지 않으면서 서버에서 정적 콘텐츠를 렌더링 할 수 있습니다. 이런 점은 무거운 라이브러리를 사용하고 상호 작용이 필요 없는 경우 특히 유용할 수 있으며, 클라이언트 사이드 번들에 영향을 주지 않고 서버에서 완전히 렌더링 될 수 있습니다. 이에 대한 훌륭한 예제로 RFC의 Note 미리보기가 있습니다.

서버 컴포넌트는 상호 작용이 없지만, 필요하다면 클라이언트 컴포넌트와 함께 구성할 수 있습니다: 서버에서만 렌더링 하므로, 오직 프로퍼티를 받아 뷰를 렌더링 하는 리액트 컴포넌트일 뿐입니다. 따라서 일반 클라이언트 컴포넌트와 같이 state, effect 및 이벤트 핸들러와 같은 것들을 가질 수 없습니다.

일반 SSR에서 봤듯이 클라이언트에서 렌더링 될 때 상호 작용이 가능하고 하이드레이션 할 수 있는 클라이언트 컴포넌트를 가져올 수 있습니다. 서버 컴포넌트와 유사하게 클라이언트 컴포넌트는 .client.jsx 또는 .client.tsx 접미사로 정의됩니다.

이런 합성 가능성을 통해 개발자는 대화형 요소가 거의 없고 대부분 정적 콘텐츠가 포함된 세부 정보 같은 페이지에서 상당한 번들 크기를 절약할 수 있습니다. 예를 들어,

위 코드 조각은 서버 컴포넌트가 클라이언트 컴포넌트와 합성되는 방식에 대한 인위적인 예시입니다. 한번 구체적으로 살펴보겠습니다.

게시물 제목, 콘텐츠 및 게시 날짜를 포함해 대부분 정적 데이터를 갖는 Post 서버 컴포넌트가 있습니다.
서버 컴포넌트는 상호 작용이 없으므로 사용자가 댓글을 추가할 수 있도록 하는 AddComponent 클라이언트 컴포넌트를 불러왔습니다.

여기서 제가 가장 맘에 드는 점은 서버 컴포넌트에서 가져온 모든 날짜 및 마크다운 파싱 라이브러리가 클라이언트에 다운로드되지 않는다는 점입니다. 클라이언트에서 다운로드하는 유일한 자바스크립트는 AddComponent 컴포넌트를 위한 코드뿐입니다.

서버 컴포넌트는 백엔드에 직접 접근할 수 있습니다: 서버에서만 렌더링 되기 때문에 다음과 같이 컴포넌트에서 직접 데이터베이스 및 기타 백엔드 전용 데이터 소스에 접근하는 데 사용할 수 있습니다.

이걸 보면 이미 전통적인 서버 사이드 렌더링에서 이 작업을 수행할 수 있다고 주장할 수 있습니다. 예를 들어, Next.js를 사용하면 getServerSideProps 및 getStaticProps에서 직접 서버 데이터에 접근할 수 있습니다. 당신이 틀리지는 않았지만, 둘의 차이점은 전통적인 SSR에서는 전부 아니면 전무의 접근 방식이며 최상위 페이지에서만 수행할 수 있습니다. 하지만 서버 컴포넌트를 사용하면 컴포넌트별로 수행할 수 있습니다.

자동 코드 스플리팅: 코드 스플리팅은 앱을 더 작은 청크로 분할해 클라이언트에 더 적은 코드를 보낼 수 있는 개념입니다. 앱의 코드를 분할하는 가장 일반적인 방법은 경로 기반으로 나누는 것입니다. 이 방식은 Next.js와 같은 프레임워크가 기본적으로 번들을 분할하는 방식이기도 합니다.

자동 코드 스플리팅 외에도, React를 사용하면 React.lazy API를 사용해 런타임에 다른 모듈의 로드를 지연시킬수 있습니다. 이에 대해 다시 한번 RFC에 있는 훌륭한 예시를 가져와봤습니다.

이 기술은 런타임에 필요한 컴포넌트만 동적으로 가져와 성능을 개선하지만 나름의 몇 가지 주의사항이 있습니다. 예를 들어, 이 접근 방식은 앱이 코드 로드를 시작할 수 있을 때를 지연시켜 처음부터 더 적은 코드를 로드하는 이점을 무효화합니다.

클라이언트 컴포넌트가 서버 컴포넌트와 합성되는 방식에 대해 앞에서 보았듯이 모든 클라이언트 컴포넌트 import 지점을 코드 스플리팅 지점으로 처리합니다. 이를 통해 개발자가 서버에서 훨씬 더 일찍 렌더링할 항목을 선택할 수 있도록 해 이 문제를 해결합니다. 다음은 서버 컴포넌트로 된 RFC에 있는 동일한 PhotoRenderer 예제입니다.

클라이언트 상태를 유지하면서 서버 컴포넌트를 다시 로드할 수 있습니다: 클라이언트 측에서는 언제든지 업데이트된 서버의 상태를 받아오기 위해 서버 트리 리페칭을 진행할 수 있습니다. 이 과정에서 로컬 클라이언트의 상태, 포커스 및 진행중인 애니메이션을 날리지 않습니다.

이런 동작은 수신된 UI의 설명이 일반 HTML이 아닌 데이터이기 때문에 가능합니다. 이를 통해 리액트는 데이터를 기존 컴포넌트에 병합해 클라이언트 상태가 날아가지 않도록 할 수 있습니다.

하지만 현재의 RFC를 기반으로는, 일부 시작 서버 컴포넌트 및 프로퍼티를 고려할 때 전체 하위 트리는 미리 페칭되어야 합니다.

서버 컴포넌트는 즉시 Suspense와 통합됩니다: 이전 섹션에서 본 것처럼 서버 컴포넌트는 <Suspense>를 사용해 점진적으로 스트리밍 할 수 있습니다. 따라서 의도적인 로딩 상태를 만들고 페이지의 나머지 부분을 기다리는 동안 중요 컨텐츠를 빠르게 표시할 수 있습니다.

이제 이 글 전체에서 살펴본 앱이 리액트 서버 컴포넌트와 함께 어떻게 보일지 살펴보겠습니다. 이번에는 Sidebar와 Post가 서버 컴포넌트이고 Navbar와 Comments가 클라이언트 컴포넌트입니다. 또한 Post를 Suspense로 래핑했습니다.

이에 대한 네트워크 그래프는 Suspense를 사용한 스트리밍 렌더링과 유사하지만 자바스크립트가 훨씬 적어집니다.

따라서 서버 컴포넌트는 저희가 겪는 자바스크립트 다운로드 문제를 해결하는 데 그치지 않고, 한 단계 더 나아가 개발자 경험을 크게 개선하는 데 도움이 됩니다.

리액트 팀이 RFC FAQ에서 언급했듯이, 페이스북의 단일 페이지에서 소수의 사용자를 대상으로 실험했으며, 제품 코드가 30% 감소하는 고무적인 결과를 얻었다고 언급했습니다.

언제 이 기능을 사용할 수 있을까요?

음. 아직은 아닙니다.

이 섹션에서 링크한 몇 가지 데모를 시도할 수 있지만 이 글을 작성하는 시점에서 서버 컴포넌트는 아직 알파 상태입니다. 또한, 스트리밍 SSR에 필요한 데이터 페칭이 포함된 새로운 아키텍처를 갖는 Suspense는 아직 공식적이지 않으며 리액트 18의 마이너 업데이트와 함께 출시될 예정입니다.

또한, 리액트 팀은 이 모든 것이 매우 복잡할 것이라 언급했으며 초기 채택은 프레임워크를 통해 이뤄질 것으로 예상합니다. 따라서 Next.js 레이아웃 RFC를 주시해야 합니다. 이 RFC는 처음부터 Next.js에 대한 가장 큰 업데이트가 될 것이며 이 글에서 논의한 새로운 리액트 18 기능 위에서 구축될 것이라고 합니다.

역주: next.js layout RFC의 번역은 이 링크에서 확인할 수 있습니다.

데모

리액트 팀과 Next.js 팀에서 제공한 데모를 여기서 확인할 수 있습니다.

참고

이 글을 작성하면서 참고했던 글입니다.

이 글의 대부분 콘텐츠는 새로운 Suspense 아키텍처 토론과 서버 컴포넌트 RFC 그리고 이야기에서 영감받았습니다.
진보된 렌더링 패턴: Lydia Hallie
웹에서의 렌더링