데이터 요청
알아두면 좋은 점 :
- 이것은 리액트 팀에 의해 개발된 새로운 데이터 요청 모델이다. 우리는 클라이언트 컴포넌트들에서 사용되는 use hook과 서버컴포넌트들에서 사용하는 async/await 을 소개하는 리액트 팀의 글을 읽어 볼 것을 추천한다.
- 너가 이것을 사용할때 아직 불안정 할 수 있다. 우리는 이 문서들을 최신 개발들이 반영되는대로 업데이트 할 예정이다.
리액트와 Next.js 13 은 너의 어플리케이션에서 데이터를 관리하고 요청하는 새로운 방식을 소개한다.
app 경로에서 작동하는 새로운 데이터 요청 시스템은 fetch() Web API 최상단에서 만들어졌다.
fetch()는 프로미스를 리턴하는 원격 리소스들을 요청하기 위해 사용된다. 리액트 팀은 자동으로 중복된 요청드를 제거하는 기능을 제공하도록 fetch를 확장시켰고, Next.js 팀은 fetch에 각각 요청마다 그들만의 캐싱과 재검증 옵션객체를 추가할수있도록 확장시켰다.
서버컴포넌트들에서 async / await 사용
리액트 팀이 제안했던것처럼, 너는 서버 컴포넌트들에서 데이터를 요청하기 위해 async 와 await을 사용할 수 있다.
주의할점: 너는 서버컴포넌트들의 레이아웃과 페이지에서 async/await 을 사용할 수 있다. 다른 컴포넌트들에서 async/await을 타입스크립트와 함께 사용하는 것은 JSX로부터 응답 형식의 에러들이 나타날 수 있다. 이 문제를 지금 해결하기위해 타입스크립트 팀과 작업중이다. 현재의 작업환경에서는 너는 컴포넌트의 타입체킹을 불가능하도록 하기 위해 {/ @ts-expect-error Server Component /} 를 사용할 수 있다.
서버컴포넌트 기능들
Next.js 는 서버 컴포넌트들에서 데이터 요청을 할때, 너가 필요한 도움되는 서버 함수들을 제공한다.
- cookies()
- headers()
클라이언트 컴포넌트들 내에서 use 사용
use 는 await과 개념적으로 비슷한 promise를 받아들이는 새로운 리액트 함수이다. use 함수는 컴포넌트들과, hook들과, suspense들과 호환 되는 방식으로 함수에서 반환된 promise를 조작한다.
클라이언트 컴포넌트들 안에서 use안에 fetch를 감싸서 사용하는것은 많은 리렌더를 유발할수 있기때문에 추천하지 않는다. 지금은, 너가 만약 클라이언트 컴포넌트 안에서 데이터요청을 해야한다면, 우리는 SWR이나 React Query같은 써드파티 라이브러리를 사용하길 추천한다.
알아둘점: 우리는 클라이언트 컴포넌트들 안에서 더 많은 use와 fetch 의 사용예를 추가할 예정이다.
정적인 데이터 요청
기본적으로, fetch는 자동으로 데이터 요청을하고 데이터를 캐싱한다.
데이터 재검증
일정한 시간 간격을 두고 캐시된 데이터들을 재검증 하기 위해, 너는 리소스의 캐시된 생애를 설정하기 위해 fetch 안에서 next.revalidate 옵션을 사용할수 있다.
동적인 데이터 요청
각 요청마다 최신 데이터들을 요청하고 싶다면, cache : 'no-store' 옵션을 사용해라.
데이터 요청 패턴
병렬적인 데이터 요청
클라이언트 서버의 waterfalls를 최소화 하기 위해, 우리는 병럴적으로 데이터를 요청하는 패턴을 추천한다.
서버컴포넌트 내에서 await을 데이터 요청에 앞서서 호출함으로써, 각각 요청들은 동시에 데이터를 열심히 요청하기 시작할 수 있다. 컴포넌트들을 이런식으로 설정함으로써 너가 waterfalls들을 피할수 있도록 한다.
우리는 각각 요청들을 병렬적으로 초기화 함으로써 시간을 아낄수 있지만, 사용자들은 모든 promise들이 resolve 될때까지 렌더링 된 결과물들을 볼 수 없다.
사용자 경험 (UX)를 향상시키기 위해, 너는 가능한 빨리 결과물들의 부분들을 보여주고 렌더링하는것을 중단시키기 위해 suspense boundary 를 추가할수 있다.
순차적으로 데이터를 가져오기
순차적으로 데이터를 요청하기 위해서, 우리는 그것이 필요한 컴포넌트에서 직접적으로 fetch를 하거나, 너는 순차적으로 데이터를 요청하는것이 필요한 컴포넌트 안에서 fetch의 결과물을 await 할 수 있다.
컴포넌트 안에서 데이터를 요청함으로써, 라우트 안에 있는 각각 요청들과 중첩된 segment는 전의 요청이나 segement가 완료되기 전까지 데이터 요청과 렌더링을 시작할 수 없다.
라우트 내에서 렌더링 차단
레이아웃 안에서 데이터를 요청함으로써, 그 레이아웃 밑에 있는 모든 경로의 segements들을 렌더링 하는것은 데이터 로딩이 다 끝난 후에 가능하다.
pages 경로에서, 서버렌더링을 사용하는 pages들은 getServerSideProps가 끝날때까지 loading spinner를 브라우저 상에서 보여줄수 있고, 그 후에 그 페이지에 맞는 리액트 컴포넌트를 렌더한다. 이것은 "all or nothing" 데이터 요청이라고 명시된다. 너의 페이지에 해당하는 전체 데이터를 가지거나, 아니면 아무것도 가지지 못한다.
앱 경로에서, 너는 탐색하기 위한 추가적인 옵션들을 가진다.
1. 첫번째, 너는 너의 데이터 요청 함수로부터의 결과가 streaming 되는동안 서버로부터 즉시 loading 상태를 보여주기 위해 loading.js 를 사용할 수 있다.
2. 두번째, 너는 필요한 페이지에 대한 부분들만 렌더링을 차단하기 위해서, 컴포넌트 tree에서 데이터 요청을 더 아래로 이동시킬 수 있다. 예를들어서, 데이터 요청을 root layout에 두는것이 아니라, 특정한 컴포넌트로 이동시키는 것이다.
가능한, 데이터를 사용하는 segment에서 데이터를 요청하는것이 가장 좋은 방법이다. 이것은 전체 페이지가 아닌 오직 로딩되는 페이지의 부분의 loading state를 보여주도록 한다.
fetch() 없이 데이터 요청
너가 만약 ORM이나 DATABASE 클라이언트 같은 써드파티 라이브러리를 사용한다면, 너는 항상 fetch 요청을 직접적으로 사용할 수 있는것은 아닐 것이다.
이렇듯 너가 fetch 요청을 사용할수 없는 상황이지만, 페이지나 레이아웃의 동작을 재검증하고 캐싱하고 싶다면 너는 segment 캐시 확인이나 segment의 기본 캐싱 동작에 의존할 수 있다.
Segement 캐시 확인
써드파티 쿼리들의 캐싱 동작이 확인되기 전까지 현재 해결방법은, 너는 전체 segment의 캐시 동작을 맞춤화 하기 위해서 segment configuration을 사용할 수 있다.
