Вопрос проверяет знание эволюции методов получения данных для серверного рендеринга в Next.js: от Pages Router с функциями getServerSideProps к современному App Router с асинхронными Server Components.
В старом Pages Router для получения данных на сервере использовалась специальная функция getServerSideProps, которая передавала данные в компонент страницы через пропсы. В новом App Router Server Components (помеченные как async) могут напрямую получать данные с помощью fetch или других библиотек, а затем рендерить JSX.
1. Pages Router (getServerSideProps):
Это специальная функция, которую нужно было экспортировать из файла страницы. Она выполнялась на сервере при каждом запросе.
// pages/blog/[slug].js (Pages Router)
export async function getServerSideProps(context) {
const { params } = context;
const postData = await getPostData(params.slug); // Запрос к API или БД
return {
props: {
postData, // Данные передаются в компонент страницы как пропсы
},
};
}
export default function BlogPost({ postData }) { // Получаем данные через пропсы
return (
<article>
<h1>{postData.title}</h1>
<div dangerouslySetInnerHTML={{ __html: postData.content }} />
</article>
);
}2. App Router (Async Server Components):
В App Router сама компонентная функция может быть асинхронной. Это упрощает логику, делая получение данных прямолинейным.
// app/blog/[slug]/page.js (App Router)
export default async function BlogPost({ params }) {
// Прямо в компоненте делаем асинхронный запрос
const postData = await getPostData(params.slug);
return (
<article>
<h1>{postData.title}</h1>
<div dangerouslySetInnerHTML={{ __html: postData.content }} />
</article>
);
}Ключевые различия:
App Router интуитивно понятнее, такую логику проще писать и читать.
App Router позволяет более гибко комбинировать компоненты, получающие данные, с обычными компонентами.
Pages Router явно отделял логику данных от компонента.