[번역] 레이아웃 RFC

원문: https://nextjs.org/blog/layouts-rfc

이 글에서는 2016년 이후 가장 큰 Next.js 업데이트가 될 예정인 RFC에 대해서 간략하게 설명하려고 합니다.

• 중첩된 레이아웃: 중첩 라우트를 사용하여 복잡한 애플리케이션을 구축합니다.
• 서버 컴포넌트에 대한 설계: 하위 트리 탐색을 최적화합니다.
• 데이터 페칭 개선: 워터폴을 피하면서 레이아웃에서 페치합니다.
• 리액트 18 기능 사용: Streaming, Transitions, 그리고 Suspense가 있습니다.
• 클라이언트, 서버 라우팅: SPA와 같은 동작을 사용하는 서버 중심 라우팅을 제공합니다.
• 100% 점진적으로 적용 가능: 주요 변경 사항이 없으므로 점진적으로 적용할 수 있습니다.
• 고급 라우팅 컨벤션: Offscreen stashing, instant transitions 등 이 있습니다.

새로운 Next.js 라우터는 최근에 출시된 리액트 18 기능을 기반으로 구축될 것 입니다. 우리는 기본 개념 및 컨벤션을 도입해 사용자들이 새로운 기능을 쉽게 채택하고 이점을 활용할 수 있도록 도와줄 계획입니다.

타임라인

RFC는 두 파트로 나눠서 진행될 예정입니다.

• 파트 1 (이 글): 새로운 라우팅 시스템에 대한 개요와 이 시스템이 리액트 서버 컴포넌트, 데이터 페칭과 통합하는 방법에 대해서 다룹니다.
• 파트 2 (다음 글): 고급 라우팅 예제 및 규칙. Next.js가 streaming 및 선택적 하이드레이션을 위해 내부적으로 Suspense를 사용하는 방법.

동기

깃헙, 디스코드, 레딧 그리고 개발자 설문 조사 같은 다양한 창구를 통해 Next.js의 라우팅 기능이 가지고 있는 제약에 대해 피드백을 수집했습니다. 그리고 다음과 같은 점을 알게 되었습니다.

• 레이아웃 생성에 대한 개발자 경험이 향상될 수 있습니다. 중첩이 가능하고 여러 경로에서 공유할 수 있으며 페이지 이동 시 상태를 유지할 수 있는 레이아웃을 쉽게 생성할 수 있어야 합니다.
• 많은 Next.js 애플리케이션은 대시보드 또는 콘솔입니다. 이러한 유형의 애플리케이션에서는 고급 라우팅 솔루션의 이점을 충분히 누릴 수 있습니다.

현재의 라우팅 시스템은 Next.js가 시작된 이후로 잘 작동하고 있지만, Next.js팀은 개발자가 더 성능이 좋고 기능이 풍부한 웹 애플리케이션을 쉽게 구축할 수 있도록 하고 싶습니다.

또한, 프레임워크 메인테이너로서 하위 버전과 호환되고 리액트의 미래 발전 방향과 함께하는 라우팅 시스템을 구축하고 싶습니다.

참고: 일부 라우팅 컨벤션은 서버 컴포넌트의 일부 기능이 원래 개발되었던 Meta의 Relay 기반 라우터와 리액트 Router 및 Ember.js와 같은 클라이언트 사이드 라우터에서 영감을 받았습니다. layout.js 파일 컨벤션은 SvelteKit에서 영감을 받았습니다. 레이아웃에 대한 초기 RFC를 제안해주신 Cassidy에게도 감사드립니다.

용어

이 RFC에서는 새로운 라우팅 컨벤션과 구문이 도입됩니다. 용어는 리액트와 표준 웹 플랫폼 용어에 기반을 두고 있습니다. RFC 전체에서 아래의 용어들은 아래의 정의된 내용으로 연결되어 있습니다.

• 트리: 계층 구조를 시각화하기 위한 컨벤션입니다. 예를 들어 부모 컴포넌트와 자식 컴포넌트로 구성되어 있는 컴포넌트 트리, 폴더 구조 등이 있습니다.
• 서브트리: 루트(첫 번째)에서 시작하여 리프(마지막)에서 끝나는 트리의 일부입니다.

• URL Path: 도메인 뒤에 오는 URL의 부분 요소입니다.
• URL Segment: 빗금으로 구분되는 URL의 부분 요소입니다.

현재의 라우팅 작동 방식

오늘날 Next.js는 파일 시스템을 사용하여 Pages 디렉토리의 개별 폴더와 파일에 URL을 통해 접근할 수 있는 라우트로 매핑합니다. 각 Page 파일은 리액트 컴포넌트를 export하고 파일 이름을 기반으로 연결된 Route가 있습니다. 예를 들면 다음과 같습니다.

• 동적 라우트: Next.js는 또한 [param].js, […param].js, [[…param]].js 컨벤션으로 동적 라우트(모든 변형을 포함)를 지원합니다.
• 레이아웃: Next.js는 간단한 컴포넌트 기반 레이아웃, 컴포넌트 속성 패턴을 사용하는 페이지별 레이아웃, 커스텀 앱을 사용하는 단일 전역 레이아웃을 제공합니다.
• 데이터 페칭: Next.js는 페이지(라우트) 수준에서 사용할 수 있는 데이터 페칭 메서드(getStaticProps, getServerSideProps)를 제공합니다. 이 메서드들은 페이지가 정적으로 생성되어야 하는지(getStaticProps) 또는 서버 사이드에서 렌더링 되어야 하는지 결정하는데 사용됩니다. 또한, 사이트가 빌드된 이후 페이지를 새로 생성하거나 변경하기 위해 증분 정적 재생성(Incremental Static Regeneration, ISR)을 사용할 수도 있습니다.
• 렌더링: Next.js는 정적 생성, 서버 사이드 렌더링, 클라이언트 사이드 렌더링과 같은 세가지의 렌더링 방법을 제공합니다. 기본적으로 페이지는 데이터 페칭에 필요한 요구 사항인 getServerSideProps를 사용하지 않는 한 정적으로 생성됩니다.

App 폴더 도입

새로운 개선 사항을 점진적으로 채택하고 변경 사항을 방지하기 위해 app이라는 새로운 디렉토리를 제안합니다.

app 디렉토리는 pages 디렉토리와 함께 작동합니다. 이전 버전과의 호환성을 위해 pages 디렉토리의 동작은 동일하게 유지되며 계속 지원됩니다. 새로운 기능을 활용하기 위해 애플리케이션의 일부를 새로운 app 디렉토리로 점진적으로 이동할 수 있습니다.

라우트 정의

app 내부의 폴더 계층 구조를 사용하여 라우트를 정의할 수 있습니다. 라우트는 루트 폴더에서 마지막 리프 폴더까지의 계층 구조를 따르는 중첩 폴더의 단일 경로입니다.

예를 들면, app 디렉터리에 두 개의 폴더를 중첩시켜서 /dashboard/settings 라우트를 추가할 수 있습니다.

참고:

- 이 시스템에서는 폴더를 사용하여 경로를 정의하고 파일을 사용하여 UI를 정의합니다. 새로운 파일 컨벤션으로 layout.js, page.js 그리고 RFC의 두번째 파트에서 소개될 loading.js가 사용됩니다.

- 이를 통해 app 디렉토리 내부에 고유한 프로젝트 파일(UI 컴포넌트, 테스트 파일, 스토리 파일 등)을 함께 배치할 수 있습니다. 이것은 현재 pages 디렉터리에서는 불가능합니다.

라우트 세그먼트

서브트리의 각 폴더는 라우트 세그먼트를 나타냅니다. 각 라우트 세그먼트는 URL Path의 해당 세그먼트에 매핑됩니다.

예를 들어, /dashboard/settings 라우트는 3개의 세그먼트로 구성됩니다.

• / 루트 세그먼트
• dashboard 세그먼트
• settings 세그먼트

참고: 라우트 세그먼트 이름은 URL Path에 대한 기존 용어와 일치하기 위해 선정되었습니다.

레이아웃

새로운 파일 컨벤션: layout.js

지금까지 폴더를 사용하여 애플리케이션의 라우트를 정의했습니다. 그러나 빈 폴더는 자체적으로 아무 작업도 수행하지 않습니다. 새로운 파일 컨벤션을 사용하여 빈 폴더에 정의된 라우트에서 렌더링할 UI를 정의하는 방법에 대해 논의해 보겠습니다.

레이아웃은 서브트리의 라우트 세그먼트에서 공유되는 UI입니다. 레이아웃은 URL paths에 영향을 주지 않고 같은 레이아웃을 공유하는 세그먼트 간에 이동을 해도 재렌더링 되지않습니다(리액트 상태가 유지).

레이아웃은 기본적으로 layout.js 파일에서 리액트 컴포넌트를 default로 export하여 정의할 수 있습니다. 컴포넌트에서는 레이아웃이 래핑하는 세그먼트로 채워질 children 프로퍼티를 포함해야 합니다.

2가지 유형의 레이아웃이 있습니다.

• 루트 레이아웃: 모든 라우트에 적용
• 일반 레이아웃: 특정 라우트 세그먼트에 적용

두개 이상의 레이아웃을 함께 중첩해서 사용하여 중첩된 레이아웃을 사용할 수 도 있습니다.

루트 레이아웃

app폴더에 layout.js를 추가하여 애플리케이션의 모든 라우트에 적용되는 루트 레이아웃을 만들 수 있습니다.

참고:

- 루트 레이아웃은 모든 라우트에 적용되기 때문에 커스텀 App(`_app.js`)과 커스텀 Document(`_document.js`)를 대체합니다.

- 초기 document 형태를 커스터마이즈하기 위해 루트 레이아웃을 사용할 수 있습니다(예. <html>, <body> 태그).

- 루트 레이아웃과 다른 레이아웃에서 데이터 페칭 메서드를 사용할 수 있습니다.

일반 레이아웃

특정 폴더에 layout.js 파일을 추가하여 애플리케이션의 일부분에서만 적용되는 레이아웃을 만들 수 있습니다.

예를 들면, dashboard 라우트 세그먼트에서만 적용하기 위해 dashboard 폴더에 layout.js 파일을 만들 수 있습니다.

중첩 레이아웃

레이아웃은 기본적으로 중첩이 가능합니다.

예를 들면, 만약 두개의 레이아웃을 결합한다고 가정해봅시다. 루트 레이아웃(app/layout.js)은 dashboard 레이아웃에 적용되며, dashboard/* 내부의 모든 라우트 세그먼트에도 적용됩니다.

페이지

새로운 파일 컨벤션: page.js

페이지는 라우트 세그먼트의 유일한 UI로서 라우트가 동작하는 데 필요한 파일입니다. 폴더 안에 page.js 파일을 추가하여 페이지를 생성할 수 있습니다.

예를 들면, /dashboard/* 라우트를 위한 페이지를 만들기 위해 각 폴더에 page.js 파일을 추가할 수 있습니다. 사용자가 /dashboard/settings에 접근할 때, Next.js는 서브트리의 상위에 있는 레이아웃으로 래핑된 settings 폴더에 대한 page.js 파일을 렌더링합니다.

dashboard 폴더 안에 직접 page.js 파일을 생성하여 /dashboard 경로와 일치시킬 수 있습니다. dashboard 레이아웃은 이 페이지에도 적용됩니다.

이 라우트는 두개의 세그먼트로 구성됩니다.

• / 루트 세그먼트
• dashboard 세그먼트

참고:

- 라우트가 유효하려면 리프 세그먼트에 페이지가 있어야 합니다. 그렇지 않은 경우 404(페이지를 찾을 수 없음)에러가 발생합니다.

- page.js 파일에서는 리액트 컴포넌트를 default export해야 합니다.

- 이름은 정확히 page.(js|jsx|ts|tsx)여야 합니다. 페이지 컴포넌트를 내보내지 않으면 Next.js에서 오류가 발생합니다.

레이아웃과 페이지 동작

요약:

• 페이지 컴포넌트는 page.js의 default export입니다.
• 레이아웃 컴포넌트는 layout.js의 default export입니다.
• 레이아웃 컴포넌트는 반드시 children 프로퍼티를 포함해야 합니다.

레이아웃 컴포넌트가 렌더링될 때 children 프로퍼티는 하위 레이아웃 컴포넌트(서브트리의 아래에 있는 경우) 또는 페이지 컴포넌트로 채워집니다.

상위 레이아웃이 페이지에 도달할 때까지 가장 가까운 하위 레이아웃을 선택하는 레이아웃 트리로 시각화하는 것이 더 쉬울 수 있습니다.

Basic Example:

위의 레이아웃과 페이지 조합은 아래의 컴포넌트 계층 구조를 렌더링합니다.

리액트 서버 컴포넌트

참고: 리액트 서버 컴포넌트에 익숙하지 않다면, 이 섹션을 읽기 전에 리액트 서버 컴포넌트 RFC를 읽어보는 것을 추천드립니다.

이 RFC에서 제안되는 기술을 사용한다면, 새롭게 적용되는 리액트의 기능을 사용할 수 있고 리액트 서버 컴포넌트를 Next.js 애플리케이션에 점진적으로 도입할 수 있습니다.

새로운 라우팅 시스템은 내부적으로 Streaming, Suspense, Transition과 같은 최근에 출시된 리액트 기능을 활용합니다. 이것은 리액트 서버 컴포넌트의 기본 구성 요소입니다.

서버 컴포넌트는 새로운 기본값입니다.

pages 디렉토리와 app 디렉토리 사이의 가장 큰 변화 중 하나는 기본적으로 app 내부의 파일이 서버에서 리액트 서버 컴포넌트로 렌더링된다는 것입니다.

이렇게 하면 pages에서 app으로 애플리케이션을 점진적으로 마이그레이션할 때 리액트 서버 컴포넌트를 자동으로 채택할 수 있습니다.

렌더링 환경과 컴포넌트 타입

참고: 리액트는 새로운 컴포넌트(모듈) 타입으로 서버, 클라이언트, 공유 컴포넌트를 도입했습니다. 이러한 새로운 타입에 대해 자세히 알아보려면 서버 및 클라이언트 컴포넌트의 기능 및 제약 조건과 서버 모듈 컨벤션 RFC를 읽는 것을 추천드립니다.

새로운 리액트 컨벤션을 사용하여 클라이언트 사이드 자바스크립트 번들에 포함될 컴포넌트를 세부적으로 제어할 수 있습니다. 클라이언트 컴포넌트와 서버 컴포넌트를 정의하기 위한 규칙이 정확히 무엇인지에 대해 진행 중인 토론이 있습니다. 최종적으로는 이 토론의 결과를 따를 것입니다.

지금은 app이 라우트의 컴포넌트(레이아웃 및 페이지)를 서버, 클라이언트 또는 두 곳 모두에서 렌더링할 수 있도록 허용한다는 점에 주목할 가치가 있습니다.

이것은 기본적으로 데이터 페칭 방법에 대한 요구가 없는 한 페이지가 정적으로 생성되는 Next.js의 pages 디렉토리의 동작 방식과 다릅니다. pages에서는 클라이언트 사이드에서 데이터를 페칭하거나 Next.js 데이터 페칭 메서드(getStaticProps, getServerSideProps)를 사용하여 페이지가 렌더링되는 시기(빌드 타임, 런타임)와 위치(서버 사이드, 클라이언트 사이드, 또는 두 가지를 조합)를 유연하게 결정할 수 있습니다.

그러나 app 폴더에서 렌더링 환경은 데이터 페칭 방식과 분리되어 컴포넌트 단에서 설정됩니다. 여전히 클라이언트 및 서버 컴포넌트의 제약 조건을 준수해야 합니다(예. 클라이언트 컴포넌트인 페이지 또는 레이아웃 내에서 getServerSideProps 메서드를 사용할 수 없습니다.).

children 프로퍼티를 사용하여 클라이언트 및 서버 컴포넌트 인터리빙(Interleaving)

리액트에서는 서버 컴포넌트에 서버에서만 실행되어야 하는 서버 전용 코드(예: 데이터베이스 또는 파일 시스템 유틸리티)가 있을 수 있기 때문에 클라이언트 컴포넌트 내에서 서버 컴포넌트를 가져오는 데 제한이 있습니다.

예를 들어, 아래와 같은 패턴은 동작하지 않습니다.

그러나 서버 컴포넌트가 둘 다 다른 서버 컴포넌트에 래핑된 경우 클라이언트 컴포넌트의 자식으로 전달할 수 있습니다. 예를 들어 ServerComponent를 다른 서버 컴포넌트의 자식으로 ClientComponent에 전달할 수 있습니다.

이 패턴을 사용하면 리액트는 결과(서버 전용 코드가 포함되지 않음)를 클라이언트에 보내기 전에 서버에서 ServerComponent를 렌더링해야 함을 알게 됩니다. 클라이언트 컴포넌트의 관점에서 해당 자식 컴포넌트는 이미 렌더링됩니다.

레이아웃에서 이 패턴은 children 프로퍼티와 함께 적용되어 추가적인 래퍼 컴포넌트를 작성할 필요가 없습니다.

예를 들어, ClientLayout 컴포넌트는 ServerPage 컴포넌트를 자식으로 받을 것 입니다.

참고: 이 구성 스타일은 클라이언트 컴포넌트 내에서 서버 컴포넌트를 렌더링하는 데 중요한 패턴입니다. 학습할 패턴의 우선 순위를 설정하고 우리가 children 프로퍼티를 사용하기로 결정한 이유 중 하나입니다.

데이터 페칭

layout.js 파일 내에서 Next.js 데이터 페칭 메서드를 사용할 수 있습니다. 레이아웃은 중첩될 수 있으므로 라우트의 여러 세그먼트에서 데이터를 페칭할 수도 있습니다. 이것은 데이터 페칭 메서드가 페이지 수준으로 제한되었던 pages 디렉토리와 다릅니다.

레이아웃에서 데이터 페칭

Next.js 데이터 페칭 메서드 getStaticProps 또는 getServerSideProps를 사용하여 layout.js 파일에서 데이터를 가져올 수 있습니다.

예를 들어, 블로그 레이아웃은 사이드바 컴포넌트를 채우기 위해 getStaticProps를 사용하여 CMS에서 카테고리 데이터를 가져올 수 있습니다.

한 라우트에서 여러 개의 데이터 페칭 메서드 사용

라우트의 여러 세그먼트에서 데이터를 페칭할 수도 있습니다. 예를 들어, 데이터를 페칭하는 레이아웃은 자체적으로 데이터를 페칭하는 페이지를 래핑할 수도 있습니다.

위의 블로그 예를 사용하면 단일 게시물 페이지에서 getStaticProps 및 getStaticPaths를 사용하여 CMS에서 게시물 데이터를 가져올 수 있습니다.

app/blog/layout.js와 app/blog/[slug]/page.js 모두 getStaticProps를 사용하기 때문에, Next.js는 전체 /blog/[slug] 라우트를 리액트 서버 컴포넌트로 빌드 타임에 정적으로 생성합니다. 리액트 서버 컴포넌트를 사용하여 클라이언트 측 자바스크립트 번들 크기는 작아지고 하이드레이션 속도가 빨라집니다.

정적으로 생성된 라우트는 성능 개선에 더 도움을 줍니다. 클라이언트 탐색이 캐시(서버 컴포넌트 데이터)를 재사용하여 재작업하지 않고, 서버 컴포넌트의 스냅샷을 렌더링하기 때문에 CPU 시간이 줄어듭니다.

동작과 우선순위

Next.js 데이터 페칭 메서드(getServerSideProps, getStaticProps)는 app 폴더의 서버 컴포넌트에서만 사용할 수 있습니다. 단일 라우트의 세그먼트에 있는 서로 다른 데이터 페칭 방법은 서로 영향을 미칩니다.

한 세그먼트에서 getServerSideProps를 사용하면 다른 세그먼트의 getStaticProps에 영향을 미칩니다. 요청은 이미 getServerSideProps 세그먼트에 대한 서버로 이동해야 하므로 서버는 모든 getStaticProps 세그먼트도 렌더링합니다. 빌드 시 가져온 props를 재사용하므로 데이터는 여전히 정적이며 렌더링은 next build 동안 생성된 props를 사용하여 모든 요청에 대해 온디맨드 방식으로 발생합니다.

한 세그먼트에서 재검증 (ISR)과 함께 getStaticProps를 사용하면 다른 세그먼트에서 revalidate와 함께 getStaticProps에 영향을 줍니다. 한 경로에 두 개의 재검증 기간이 있는 경우 더 짧은 재검증이 우선시 됩니다.

참고: 앞으로는 라우트에서 전체 데이터 페칭에 대한 세분성을 허용하도록 최적화될 수 있습니다.

리액트 서버 컴포넌트를 사용한 데이터 페칭 및 렌더링

서버 사이드 라우팅, 리액트 서버 컴포넌트, Suspense 및 Streaming의 조합은 Next.js의 데이터 페칭 및 렌더링에 몇 가지 영향을 미칩니다.

병렬 페칭 및 렌더링

Next.js는 워터폴을 최소화하기 위해 병렬 데이터 페칭을 시작합니다. Suspense와 함께 리액트는 요청이 완료되기 전에 즉시 서버 컴포넌트 렌더링을 시작할 수 있으며 요청이 완료되면 결과를 넣을 수 있습니다.

예를 들어, 데이터 페칭이 순차적인 경우 경로의 각 중첩 세그먼트는 이전 세그먼트가 완료될 때까지 데이터 페칭을 시작할 수 없습니다. 렌더링이 데이터 페칭에 종속된 경우 각 세그먼트는 데이터 페칭이 완료된 이후에만 렌더링될 수 있습니다.

병렬 페칭을 사용하면, 각 세그먼트가 동시에 데이터 페칭을 시작할 수 있습니다. Suspense를 사용하면 데이터가 완전히 로드되지 않은 경우에도 렌더링이 즉시 시작됩니다. 데이터가 사용할 수 있기 전에 읽히게 되면, Suspense가 트리거됩니다.

부분 페칭 및 렌더링

같은 계층의 라우트 세그먼트 사이를 이동할 때, Next.js는 해당 세그먼트만 페칭하고 렌더링합니다. 상위의 요소를 다시 페칭하거나 다시 렌더링할 필요가 없습니다. 즉, 레이아웃을 공유하는 페이지에서 사용자가 형제 페이지 사이를 이동할 때 레이아웃이 유지되고 Next.js는 해당 세그먼트만 페칭하고 렌더링합니다.

이것은 리액트 서버 컴포넌트에 특히 유용합니다. 그렇지 않으면 각 페이지 이동으로 인해 서버에서 페이지의 변경된 부분만 렌더링하는 대신 전체 페이지가 다시 렌더링되기 때문입니다. 이렇게 하면 전송되는 데이터의 양과 실행 시간이 줄어들어 성능이 향상됩니다.

예를 들어, 사용자가 /analytics와 /settings 페이지 사이를 이동하면 리액트는 페이지 세그먼트를 다시 렌더링하지만 레이아웃은 유지합니다.

참고: 트리 상위에 있는 데이터를 강제로 다시 페칭하는 것도 가능합니다. 우리는 세부 사항에 대해 여전히 논의하고 있고 RFC를 업데이트 할 것입니다.

결론

우리는 Next.js의 레이아웃, 라우팅 및 데이터 페칭의 미래를 기대하고 있습니다. 다음 파트에서 소개할 RFC에서는 다음과 같은 내용을 논의할 예정입니다.

• 즉시 로드 상태: 서버 사이드 라우팅을 사용하면 이동이 완료되기 전에 서버에서 렌더링 및 데이터 페칭이 발생합니다. 따라서 애플리케이션이 응답하지 않는 느낌이 들지 않도록 로딩 UI를 표시하는 것이 중요합니다. 인라인 및 글로벌 로딩 인디케이터 및 스켈레톤과 같은 즉각적인 로딩 상태에 대한 프레임워크 수준 지원을 제안합니다.
• Offscreen Stashing을 활용한 즉각적인 앞으로 가기/뒤로 가기: 리액트는 화면에 렌더링하지 않고 리액트 트리와 그 상태를 저장하는 새로운 <Offscreen /> 컴포넌트를 추가할 계획입니다. 이 컴포넌트를 활용하면 방문한 경로를 숨기고 방문하기 전에 경로를 미리 렌더링할 수 있어야 합니다. 이러한 경로를 앞뒤로 탐색하는 것은 즉각적이어야 하며 이전에 저장된 상태를 복원할 수 있어야 합니다.
• 병렬 라우트: 페이지에 탭 막대가 두 개 이상 있는 경우 개념적으로 <iframe />과 유사하게 독립적으로 탐색할 수 있는 두 개 이상의 병렬 중첩 레이아웃이 있어야 합니다.
• 라우트 가로채기: 때때로 다른 페이지 내에서 경로를 가로챌 수 있는 것이 유용합니다. URL은 일반적으로 UI의 다른 부분으로 연결되지만 이 컨텍스트 내에서 방문할 때는 그렇지 않습니다. 예를 들어, 확장되어 인라인으로 표시될 수 있는 트윗이나 독립적으로 실행되는 갤러리 대신 모달 사진 뷰어가 있습니다.
• Streaming 및 선택적 하이드레이션: 서버 중심 라우팅, 리액트 서버 컴포넌트, Suspense 및 Streaming이 결합하여 클라이언트에 전송되는 내용을 줄이고 작업을 더 작은 청크로 분할하여 새로운 라우팅 패러다임을 활성화하고 성능을 향상시키는 방법에 대한 자세한 내용을 공유합니다.

GitHub Discussion에 참여하여 코멘트를 남겨주세요

🚀 한글로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요!