Next.js v — 실수에 대한 반성
- Mary-Kate Olsen원래의
- 2024-10-26 04:06:02936검색
안녕하세요! 이것은 next.js에 관한 또 다른 글입니다. 그리고 마지막으로 새 버전에 대해 설명합니다! 각 릴리스에는 새롭고 흥미롭고 논란이 많은 기능이 포함되어 있습니다. 이 버전도 예외는 아닙니다. 그러나 새 버전은 새로운 기능이 아니라 next.js의 우선 순위와 구성이 변경되었다는 점에서 흥미롭습니다. 그리고 네, 제목에서 짐작하셨겠지만 이번 릴리스의 상당 부분은 이전의 실수를 반성하는 데 가치가 있습니다.
저는 next.js 버전 8부터 작업해왔습니다. 그동안 관심을 가지고 개발을 지켜보았습니다(가끔 실망스럽기도 했습니다). 최근에 저는 새로운 App Router와 관련된 고군분투에 대한 일련의 기사를 게시했습니다 - "Next.js App Router. 미래로 가는 길 아니면 잘못된 방향", "Next.js 캐싱. 선물인가 저주", " 도서관의 신을 위한 더 많은 도서관 또는 i18n을 어떻게 다시 생각했는지." 이 모든 것은 이전 버전의 next.js에서 아이디어와 기능이 매우 취약하게 개발된 결과였습니다. 이로 인해 새 버전에 대한 관심이 더욱 커졌습니다. 이와 함께 프레임워크의 변화 벡터를 이해하려는 욕구도 있습니다.
이 기사에서는 앱 라우터 또는 서버 구성 요소가 무엇인지 다루지 않겠습니다. 이에 대해서는 이전 기사에서 자세히 설명했습니다. 새 버전과 새로운 변경 사항에만 집중하겠습니다.
참고: 이 기사에는 저자의 관점에서 가장 흥미로운 변화가 반영되어 있습니다. 작성자가 프레임워크의 커밋 및 PR에서 선택했기 때문에 공식 목록과 다릅니다.
Next.js v15 릴리스
먼저 next.js 내부 개발 프로세스의 변화에 대해 조금 말씀드리겠습니다. 프레임워크 팀은 처음으로 릴리스 후보(RC 버전)를 게시했습니다. 분명히 React.js 팀이 React v19 RC를 게시하기로 결정했기 때문에 이렇게 된 것입니다.
일반적으로 next.js 팀은 안정 릴리스에서 "Canary" 릴리스 브랜치의 반응을 침착하게 사용합니다(이 브랜치는 안정적인 것으로 간주되며 프레임워크에서 사용하도록 권장됩니다). 하지만 이번에는 다르게 행동하기로 결정했습니다(스포일러 - 헛되지 않음).
두 팀의 계획은 간단했습니다. 시험판 버전을 게시하고 커뮤니티에서 문제를 확인하도록 한 후 몇 주 안에 정식 릴리스를 게시하는 것이었습니다.
React.js의 출시 후보가 공개된 지 6개월이 넘었지만 아직 안정 버전이 공개되지 않았습니다. React.js의 안정적인 버전 출시 지연은 next.js의 계획에도 영향을 미쳤습니다. 따라서 전통과는 달리 이미 15번째 버전을 작업하면서 총 15개의 추가 패치 버전을 게시했습니다(보통 3~5개의 패치 후 릴리스). 여기서 주목할만한 점은 이번 패치 버전에는 누적된 변경 사항이 모두 포함되지 않고 중요한 문제만 해결되었으며, 이 역시 next.js의 일반적인 프로세스에서 벗어났습니다.
next.js의 기본 릴리스 프로세스는 모든 것이 카나리아 브랜치로 병합된 후 어느 시점에 이 브랜치가 안정적인 릴리스로 게시되는 것입니다.
그러나 결과적으로 next.js 팀은 React.js 릴리스에서 분리하여 React.js의 안정적인 버전이 출시되기 전에 프레임워크의 안정적인 버전을 게시하기로 결정했습니다.
문서 버전 관리
또 다른 매우 유용한 조직 변화입니다. 마지막으로 다양한 버전의 문서를 볼 수 있습니다. 이것이 중요한 이유는 다음과 같습니다.
첫째, 주요 변경 사항으로 인해 next.js를 업데이트하는 것이 상당히 어려운 작업인 경우가 많습니다. 실제로 이것이 바로 버전 12의 경우 여전히 200만 건이 넘는 다운로드가 있고, 버전 13의 경우 월별 400만 건이 넘는 다운로드가 있는 이유입니다(공평하게 말하면 버전 14의 다운로드 건수는 2천만 건이 넘습니다).
따라서 이전 버전 사용자는 새 버전이 절반만 다시 작성될 수 있으므로 해당 버전에 맞는 문서가 필요합니다.
또 다른 문제는 Next.js가 기본적으로 단일 채널을 사용한다는 것입니다. 문서 변경 사항도 적용됩니다. 따라서 카나리아 버전의 변경 사항에 대한 설명이 기본 문서에 즉시 표시되었습니다. 이제 "카나리아" 섹션 아래에 표시됩니다.
반응 사용
처음에 Next.js가 현재 React.js의 RC 버전을 사용하고 있다고 언급했습니다. 그러나 실제로 이것은 완전히 사실이 아니거나 오히려 완전히 사실이 아닙니다. 실제로 Next.js는 현재 App Router용 19번째 Canary 버전과 Pages Router용 18번째 버전이라는 두 가지 React.js 구성을 사용하고 있습니다.
흥미롭게도 한때 Pages Router의 19번째 버전도 포함하고 싶었지만 이러한 변경 사항을 롤백했습니다. 이제 안정적인 버전 출시 이후 React.js 버전 19에 대한 완전한 지원이 약속됩니다.
이와 함께 새 버전에는 서버 액션 기능에 대한 몇 가지 유용한 개선 사항이 포함됩니다(예, React 팀에서 이름을 변경했습니다).
- 무게 및 성능 최적화
- 오류 처리 개선
- 서버 기능에서 재검증 및 리디렉션이 수정되었습니다.
이 섹션에는 Next.js의 새로운 기능인 Form 구성 요소도 포함할 것 같습니다. 전반적으로 이는 React-dom의 친숙한 형식이지만 몇 가지 개선 사항이 있습니다. 이 구성 요소는 양식 제출에 성공하여 다른 페이지로 이동하는 경우 주로 필요합니다. 다음 페이지에는 loading.tsx 및layout.tsx 추상화가 미리 로드됩니다.
import Form from 'next/form'
export default function Page() {
return (
<Form action="/search">;
{/* On submission, the input value will be appended to
the URL, e.g. /search?query=abc */}
<input name="query" />;
<button type="submit">Submit</button>;
</Form>;
)
}
개발자 경험(DX)
Next.js에 관해 이야기할 때 개발자 경험을 무시할 수 없습니다. 표준 "더 빠르게, 더 높게, 더 강하게"(또한 논의하겠지만 조금 나중에), 몇 가지 유용한 개선 사항이 출시되었습니다.
오랫동안 기다려온 최신 ESLint 지원입니다. Next.js는 지금까지 ESLint v9를 지원하지 않았습니다. 이는 eslint 자체(v8)와 해당 하위 종속성 중 일부가 이미 더 이상 사용되지 않는 것으로 표시되어 있다는 사실에도 불구하고 발생합니다. 이로 인해 프로젝트가 본질적으로 더 이상 사용되지 않는 패키지를 유지해야 하는 불쾌한 상황이 발생했습니다.
오류 인터페이스가 약간 개선되었습니다(Next.js에서는 이미 명확하고 편리합니다).
- 스택 추적을 복사하는 버튼을 추가했습니다.
- 특정 줄에서 편집기의 오류 소스를 여는 기능이 추가되었습니다.
"정적 표시기"가 추가되었습니다. 페이지 모서리에 페이지가 정적 모드로 구축되었음을 보여주는 요소입니다.
전체적으로는 사소한 일이지만 핵심 변경 사항에 새로운 것으로 포함시켰다는 점이 재미있습니다. "사전 구축된" 페이지에 대한 표시는 대략 버전 8(2019)부터 있었으며 여기서는 기본적으로 페이지를 약간 업데이트하여 앱 라우터에 맞게 조정했습니다.
디버깅 정보가 포함된 디렉터리(.next/diagnostics)도 추가되었습니다. 여기에는 빌드 프로세스 및 발생하는 모든 오류에 대한 정보가 포함됩니다. 이것이 일상적인 사용에 유용할지는 아직 확실하지 않지만 Vercel 개발자의 문제를 해결할 때 확실히 사용될 것입니다(예, 때로는 문제 해결에 도움이 됩니다).
빌드 프로세스의 변경 사항
DX에 대해 논의한 후 빌드 프로세스에 대해 이야기해 볼 가치가 있습니다. 그리고 터보팩도 함께.
터보팩
그리고 이 분야의 가장 큰 뉴스입니다. 이제 터보팩이 개발 모드로 완전히 완성되었습니다! "Turbopack으로 기존 테스트 100% 오류 없이 통과"
현재 터보 팀은 프로덕션 버전을 작업 중이며, 점진적으로 테스트를 거쳐 개선하고 있습니다(현재 약 96% 완료)
Turbopack에는 새로운 기능도 추가되었습니다.
- Turbopack을 사용한 빌드에 대한 메모리 제한 설정
- Tree Shaking(사용하지 않는 코드 제거).
import Form from 'next/form'
export default function Page() {
return (
<Form action="/search">;
{/* On submission, the input value will be appended to
the URL, e.g. /search?query=abc */}
<input name="query" />;
<button type="submit">Submit</button>;
</Form>;
)
}
Turbopack의 이러한 개선 사항은 "메모리 사용량을 25-30% 줄였고" "무거운 페이지 빌드를 30-50% 가속화"했습니다.
다른
중요한 스타일 문제가 수정되었습니다. 버전 14에서는 탐색 중에 스타일 순서가 깨져서 스타일 A가 스타일 B보다 높아지거나 그 반대가 되는 상황이 자주 발생했습니다. 이로 인해 우선순위가 변경되었고 결과적으로 요소가 다르게 보였습니다.
대망의 다음 개선 사항입니다. 이제 구성 파일을 TypeScript로 작성할 수 있습니다 - next.config.ts
const nextConfig = {
experimental: {
turbo: {
treeShaking: true,
memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
},
},
}
또 다른 흥미로운 업데이트는 정적 페이지 빌드 시도를 다시 시도하는 것입니다. 이는 페이지가 빌드 시 실패하는 경우(예: 인터넷 문제로 인해) 다시 빌드를 시도한다는 의미입니다.
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
/* config options here */
};
export default nextConfig;
그리고 이 섹션을 마무리하기 위해 커뮤니티에서 매우 원하는 기능, 즉 빌드를 위한 추가 파일의 경로를 지정하는 기능입니다. 예를 들어 이 옵션을 사용하면 파일이 앱 디렉터리가 아닌 모듈/메인, 모듈/인보이스 같은 디렉터리에 위치하도록 지정할 수 있습니다.
그러나 현재는 내부 팀 목적으로만 추가했습니다. 그리고 이 버전에서는 확실히 그것을 제시하지 않을 것입니다. 앞으로는 Vercel 요구 사항에 사용되거나 테스트하여 다음 릴리스에서 선보일 예정입니다.
프레임워크 API의 변경 사항
Next.js 업데이트에서 가장 괴로운 부분은 API 변경입니다. 그리고 이번 버전에는 브레이킹 업데이트도 있습니다.
쿠키, 헤더, 매개변수, searchParams(소위 동적 API) 등 여러 내부 프레임워크 API가 비동기화되었습니다.
const nextConfig = {
experimental: {
staticGenerationRetryCount: 3,
},
}
큰 변화이지만 Next.js 팀에서는 codemod를 호출하여 이 모든 기능을 자동으로 업데이트할 수 있다고 약속합니다.
npx @next/codemod@canary next-async-request-api .
또 다른 변경 사항이지만 아마도 많은 사람들에게는 관련이 없을 것입니다. geo 및 ip 키가 NextRequest에서 제거되었습니다(미들웨어 및 API 경로에 사용). 기본적으로 이 기능은 Vercel에서만 작동했지만 다른 곳에서는 개발자가 자신만의 방법을 만들었습니다. Vercel의 경우 이 기능은 @vercel/functions 패키지로 이동됩니다
그리고 몇 가지 추가 업데이트:
- revalidateTag에서는 이제 여러 태그를 한 번에 전달할 수 있습니다.
- image.remotePatterns.search 및 Images.localPatterns 키가 next/image 구성에 추가되었습니다. 이를 통해 이미지 압축에 대한 주소 제한을 더 효과적으로 제어할 수 있습니다.
import Form from 'next/form'
export default function Page() {
return (
<Form action="/search">;
{/* On submission, the input value will be appended to
the URL, e.g. /search?query=abc */}
<input name="query" />;
<button type="submit">Submit</button>;
</Form>;
)
}
캐싱
내 개인적인 의견으로는 이것이 Next.js의 가장 중요한 변화가 발생한 곳입니다. 그리고 가장 큰 소식은 이제 기본적으로 캐싱이 비활성화되어 있다는 것입니다! 캐싱 문제에 대해 자세히 설명하지는 않겠습니다. 이 문제는 "Next.js 캐싱. 선물 또는 저주" 기사에서 주로 다루었습니다.
캐싱의 모든 주요 변경 사항을 살펴보겠습니다.
- 구체적으로, 이제 가져오기는 기본적으로 강제 캐시 대신 no-store 값을 사용합니다.
- API 경로는 이제 기본적으로 강제 동적 모드에서 작동합니다. >); 클라이언트 라우터의 캐싱도 비활성화되었습니다. 이전에는 클라이언트가 경로 내의 페이지를 방문하면 클라이언트에 캐시되어 페이지가 다시 로드될 때까지 해당 상태를 유지했습니다. 이제 현재 페이지가 매번 로드됩니다. 이 기능은 next.config.js를 통해 재구성할 수 있습니다.
const nextConfig = {
experimental: {
turbo: {
treeShaking: true,
memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
},
},
}
게다가 클라이언트 측 캐싱이 활성화된 경우에도 적절한 순간에 업데이트될 것으로 보입니다. 특히, 서버에서 활성화된 페이지의 캐시가 만료되는 경우.- 이제 서버 구성 요소가 개발 모드에서 캐시됩니다. 이를 통해 개발 중 업데이트가 더 빠르게 이루어집니다. 페이지를 다시 로드하면 캐시를 지울 수 있습니다. next.config.js를 통해 이 기능을 완전히 비활성화할 수도 있습니다.
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
/* config options here */
};
export default nextConfig;
이제 'Cache-Control' 헤더를 관리할 수 있습니다. 이전에는 항상 Next.js의 내부 값으로 엄격하게 덮어썼습니다. 이로 인해 CDN을 통한 캐싱으로 인해 아티팩트가 발생했습니다.- next/dynamic은 매번 모듈을 다시 로드하는 대신 모듈을 캐시하고 재사용합니다.
- '역사적 오해'에 관한 내용입니다. 새로운 API도 Next.js에 나타날 것입니다. 즉, 소위 동적 I/O입니다. 아직 어디에도 쓰여진 바가 없으므로, 다음은 변경 사항을 토대로 작가가 추측한 내용입니다.
동적 I/O는 동적 구축의 고급 모드인 것으로 보입니다. PPR(
부분 사전 렌더링), 더 정확하게는 PPR의 보완물입니다. 간단히 말해서 부분 사전 렌더링은 대부분의 요소가 빌드 시 빌드되고 캐시되는 반면 개별 요소는 각 요청에 대해 빌드되는 페이지 빌드 모드입니다. 따라서 동적 I/O는 [아마도] 이 논리에 대한 아키텍처를 마무리합니다. 모드와 사용 장소(
"동적" 블록인지 여부)에 따라 정확하게 활성화 및 비활성화할 수 있도록 캐싱 기능을 확장합니다.
import Form from 'next/form'
export default function Page() {
return (
<Form action="/search">;
{/* On submission, the input value will be appended to
the URL, e.g. /search?query=abc */}
<input name="query" />;
<button type="submit">Submit</button>;
</Form>;
)
}
이와 함께 "캐시 사용" 지시문이 추가되었습니다. nodejs와 에지 런타임, 그리고 분명히 모든 서버 세그먼트와 추상화에서 사용할 수 있습니다. 함수 상단이나 함수를 내보내는 모듈 상단에 이 지시문을 지정하면 해당 결과가 캐시됩니다. 이 지시문은 DynamicIO가 활성화된 경우에만 사용할 수 있습니다.
const nextConfig = {
experimental: {
turbo: {
treeShaking: true,
memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
},
},
}
또한 특히 캐시 사용을 위해 캐시 라이프 및 캐시 태그 메소드가 추가되었습니다
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
/* config options here */
};
export default nextConfig;
cacheTag는 revalidateTag를 사용한 재검증에 사용되며, 캐시 라이프는 캐시 수명을 설정합니다. 캐시 라이프 값의 경우 미리 설정된 값 중 하나를 사용해야 합니다. 여러 가지 옵션("초", "분", "시간", "일", "주", "최대")을 즉시 사용할 수 있으며 추가 옵션은 next.config.js에서 지정할 수 있습니다.
const nextConfig = {
experimental: {
staticGenerationRetryCount: 3,
},
}
부분 사전 렌더링(PPR)
아마도 다음 릴리스의 주요 기능일 것입니다. 앞서 언급한 것처럼 PPR은 대부분의 요소가 빌드 타임에 어셈블되어 캐시되는 반면 개별 요소는 각 요청에 대해 어셈블되는 페이지 작성 모드입니다. 동시에 사전 구축된 부분은 즉시 클라이언트에 전송되고 나머지 부분은 동적으로 로드됩니다.
기능 자체는 6개월 전 릴리스 후보에 실험적인 API로 도입되었습니다. 이 API는 이 상태로 유지되며 버전 16에서만 안정적이라고 볼 수 있습니다(주요 기능이 6개월에서 1년 이내에 안정으로 전환되는 경우가 많기 때문에 좋습니다).
변경사항에 대해 안내드립니다. 앞서 언급했듯이 주로 작동 원리를 업데이트했습니다. 그러나 PPR을 사용하는 관점에서는 이는 거의 영향을 미치지 않습니다. 동시에 다음과 같은 몇 가지 개선 사항이 적용되었습니다.
이전에는 구성에 플래그만 있었지만 이제 PPR을 활성화하려면 'incremental'을 지정해야 합니다. 이는 로직을 보다 투명하게 만들기 위한 것으로 보입니다. 개발자는 PPR에서도 콘텐츠를 캐시할 수 있으며 이를 업데이트하려면 재검증 메서드를 호출해야 합니다.
import { cookies } from 'next/headers';
export async function AdminPanel() {
const cookieStore = await cookies();
const token = cookieStore.get('token');
// ...
}
또한 이전에는 PPR이 전체 프로젝트에 대해 실행되었지만 이제는 각 세그먼트(레이아웃 또는 페이지)에 대해 활성화해야 합니다.
const nextConfig = {
images: {
localPatterns: [
{
pathname: '/assets/images/**',
search: 'v=1',
},
],
},
}
또 다른 변경 사항은 부분 폴백 사전 렌더링(PFPR)입니다. 이러한 개선 덕분에 사전 제작된 부분은 즉시 클라이언트로 전송되고 나머지 부분은 동적으로 로드됩니다. 이 시간에는 동적 요소 대신 콜백 구성 요소가 표시됩니다.
import Form from 'next/form'
export default function Page() {
return (
<Form action="/search">;
{/* On submission, the input value will be appended to
the URL, e.g. /search?query=abc */}
<input name="query" />;
<button type="submit">Submit</button>;
</Form>;
)
}
수단
계측은 안정적인 API로 표시됩니다. 계측 파일을 사용하면 사용자가 Next.js 서버의 수명 주기에 연결할 수 있습니다. 전체 애플리케이션에서 작동합니다(페이지 라우터 및 앱 라우터의 모든 세그먼트 포함).
현재 계측에서는 다음 후크를 지원합니다.
등록 - Next.js 서버를 초기화할 때 한 번 호출됩니다. 관찰 가능성 라이브러리(OpenTelemetry, datadog)와의 통합 또는 프로젝트별 작업에 사용할 수 있습니다.
onRequestError - 모든 서버 오류에 대해 호출되는 새로운 후크입니다. 오류 추적 라이브러리(Sentry)와의 통합에 사용할 수 있습니다.
const nextConfig = {
experimental: {
turbo: {
treeShaking: true,
memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
},
},
}
인터셉터
경로 수준 미들웨어라고도 알려진 인터셉터입니다. 본격적인 [이미 존재하는] 미들웨어와 비슷하지만 후자와는 다릅니다.
- Node.js 런타임에서 작동할 수 있습니다.
- 서버에서 작동합니다(환경 및 통합 캐시에 액세스할 수 있음).
- 여러 번 추가할 수 있으며 중첩 시 상속됩니다(베타 버전의 미들웨어 작동 방식과 유사).
- 서버 기능에도 적용됩니다.
게다가 인터셉터 파일을 생성하면 트리 아래의 모든 페이지가 동적이 됩니다.
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
/* config options here */
};
export default nextConfig;
Vercel에 관해 말하자면, 미들웨어는 이제 CDN 수준에서 기본 단순 검사로 효과적일 것입니다(예를 들어 요청이 허용되지 않으면 즉시 리디렉션을 반환). 반면 인터셉터는 서버에서 본격적인 점검과 복잡한 작업을 수행합니다.
그러나 자체 호스팅에서는 이러한 구분이 분명히 덜 효과적입니다(두 추상화 모두 서버에서 작동하기 때문에). 인터셉터만 사용해도 충분할 수 있습니다.
결론
가져오기 덮어쓰기, 공격적인 캐싱, 수많은 버그 및 커뮤니티 요청 무시. Next.js 팀은 잘못된 결정을 내리고, 성급하게 릴리스했으며, 커뮤니티 피드백에도 불구하고 자신의 견해를 고수했습니다. 문제를 인식하는 데 거의 1년이 걸렸습니다. 그리고 마침내 이제 프레임워크가 다시 한번 커뮤니티 문제를 다루고 있다는 느낌이 들었습니다.
반면에 다른 프레임워크도 있습니다. 1년 전 React.js 프레젠테이션에서는 모든 프레임워크가 곧 Next.js와 동등한 수준이 될 것으로 보였습니다. React는 Next.js를 주요 도구로 자주 언급하기 시작했고, 프레임워크는 곧 출시될 빌드 시스템, 서버 구성 요소 및 기능에 대한 지원, 일련의 전역 변경 및 통합을 선보였습니다. 시간이 지났고, 본질적으로 아직 그 시점에 도달한 사람은 아무도 없습니다.
물론 최종 결론은 시간이 좀 지나야 알 수 있지만 현재로서는 기대되는 프레임워크 평준화 대신 React.js의 변화로 인해 Next.js의 지배력이 더욱 커지고 프레임워크 간의 더 넓은 차이(서버 구성 요소 및 작업의 구현이 프레임워크의 재량에 맡겨졌기 때문에).
동시에 OpenAI는 Remix로 전환했습니다("더욱 향상된 안정성과 편의성으로 인해"):
그리고 분명히 그들은 Next.js의 중요한 변화 이전에 시작했습니다
일반적으로 다음 stateofjs 및 stackoverflow 설문조사에서는 상당한 개편이 있을 가능성이 높습니다.
크레딧
코드 예제 또는 해당 기초는 next.js 문서는 물론 커밋, PR 및 next.js 코어에서 가져왔습니다.
후기
MD 파일을 기반으로 문서를 생성하기 위한 도구가 필요한 경우 robindoc.com을 살펴보고 next.js로 작업하는 경우 nimpl.tech의 솔루션에서 유용한 정보를 찾을 수 있습니다.
위 내용은 Next.js v — 실수에 대한 반성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!