Dev Diary
[ 살펴보기 ] NextJS - v15 Release Candidate

[ 살펴보기 ] NextJS - v15 Release Candidate

Chan's photo
Chan
·

3 min read

React가 Server Component와 Concurrent Mode와 같은 새로운 변화를 들고 나온 이후 생태계는 이에 발 맞춰 함께 변화해가고 있다. NextJS 역시 React 팀과 긴밀히 협력하며 이러한 변화해 맞추어 나아가고 있다. 그리고 Next 13에서 도입된 app routing와 client component, server component의 구분은 우리가 기존에 Next와 React를 사용해 개발해왔던 Mental Model의 변화를 요구하기에 초기에 혼동이 많았지만 이제는 생태계도 이러한 변화에 서서히 적응해 나가고 있는 듯 보인다.

App route는 server component의 사용, 보다 나은 file co-location등 좋은 기능을 제공하지만 많은 개발자들을 당황스럽게 만든 부분 역시 존재했는데 그 부분이 바로 cache behavior다.

개발자의 의도와는 관계없이 framework가 default로 fetch data를 cache 하거나 route cache의 경우에는 개발자가 원치 않더라도 framework에서 cache를 강제하는 부분까지 존재했다. 이러한 불만을 Next 팀에서 인지하였는지 새롭게 배포될 Major Update에서는 기존의 cache behavior가 변경될 예정이다.

Next 공식 페이지에 올라온 NextJS 15 RC 블로그를 통해 다음 Major Update에선 어떤 부분이 변경되는지 살펴보자

React 19 RC 적용

NextJS 15 RC에선 React 19 RC를 지원한다. 다가오는 React 19에선 많은 변경사항이 있지만 그 중에서 가장 큰 변화라면 compiler의 도입일 것이다. 그리고 Next 15 RC에선 compiler를 포함한 React 19 RC의 새로운 기능을 사용할 수 있게 된다. React 19 RC에 관해선 별도의 Post에 정리를 해두었다.

Hydration Error 개선

Hyration error가 발생했을 때 보다 쉽게 원인을 파악할 수 있도록 error에 문제가 되는 코드 정보와 더불어 suggestion도 제공된다. 아래는 공식 Blog에서 발췌한 참고 이미지다.

Hydration error message improved in Next.js 15 RC

Caching 관련 업데이트

NextJS 15부터는 fetch api로 data를 fetch할 때 default cache behavior는 no-store가 된다. 기존은 force-cache가 default였기에 아무런 옵션을 설정하지 않으면 fetch api로 요청한 데이터가 cache되었지만 이제는 caching을 원하면 caching이 필요한 fetch api에 직접 옵션을 설정 해준다.

또한 NextJS 14에선 dynamic function이나 dynamic config를 사용하지 않는 get method route handler는 자동으로 cache 되었지만 NextJS 15부터 Get method를 사용하는 route handler는 default로 cache되지 않는다. 만약 기존처럼 route handler를 caching하고자 한다면 export const dynamic = "force-static" config option을 선언 해주어야 한다.

그리고 Route cache 또한 framework에서 강제되지 않는다. 기존 NextJS에선 route에 대한 cache를 특정 시간 동안 강제했지만 Next15에선 route cache를 강제하지 않는다. 만약 기존처럼 route cache를 적용하고 싶다면 next.config의 experimental.staleTime property를 통해 route cache에 대한 설정을 조정할 수 있다.

const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};

module.exports = nextConfig;

Partial Rendering ( Experimental )

현재 NextJS에선 page 하위 server component에서 cookie()나 header()와 같은 dynamic function을 사용하면 해당 page 전체가 dynamic rendering으로 변환되지만 Next팀은 Partial Rendering을 통해 page 전체를 dynamic rendering으로 변환하는 대신 필요한 UI component만 dynamic rendering 처리를 할 수 있는 기능을 안정화 시키기 계속해서 개발을 진행하고 있다.

아직은 experimental 단계이지만 사용해 보고자 한다면 experimental_ppr route config를 page에 추가해 준다. Dynamic rendering으로 처리되어야 하는 부분은 Suspense로 감싸줘야 한다.

 import { Suspense } from "react"
import { StaticComponent, DynamicComponent } from "@/app/ui"

export const experimental_ppr = true

export default function Page() {
  return {
     <>
         <StaticComponent />
         <Suspense fallback={...}>
             <DynamicComponent />
         </Suspense>
     </>
  };
}

그리고 next.config.js의 experimental option을 다음과 같이 업데이트 해준다

const nextConfig = {
  experimental: {
    ppr: 'incremental',
  },
};

module.exports = nextConfig;

Experimental after API

아직 experimental 단계인 after api가 추가된다. after api는 server에서 response 작업을 마치고 실행할 작업들을 관리한다.

만약 server에서 request에 대한 처리 외에 log나 analytics와 같은 t작업을 response 처리에 대한 blocking 없이 수행되어야 한다면 response 작업을 우선 처리하고 기타 다른 작업을 수행할 수 있게 해준다

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';

export default function Layout({ children }: { children: React.ReactNode }) {
  after(() => {
    // layout이 render되어 client에 전달되고 나서 실행된다
    log()
  })
  return <>{children}</>
}

after api를 사용하고자 한다면 next.config.js 파일을 다음과 같이 업데이트 해준다

const nextConfig = {
  experimental: {
    after: true,
  },
};

module.exports = nextConfig;
Next.jsFrontend Development