Next.js — это фреймворк последнего времени. Он построен на плечах своих предшественников и поэтому вобрал в себя все их лучшие черты. Благодаря этому Next.js поставляется с возможностью выбора способа рендеринга контента. Вы можете либо выбрать рендеринг пустого html и динамически заполнить компоненты с помощью javascript, либо заставить сервер посылать вам пакеты контента, предварительно созданные на сервере, а еще лучше — запросить кэшированную копию контента из CDN. И самое приятное, что вам не нужно подписываться на определенную стратегию для всего приложения, вы можете настроить и использовать стратегию, наиболее подходящую для данной страницы/маршрута, для каждой страницы/маршрута отдельно.
В этом блоге я попытаюсь собрать воедино мое понимание этих различных стратегий рендеринга, когда их лучше использовать и как реализовать каждую из них в Next.js. Итак, давайте начнем.
CSR: Рендеринг на стороне клиента
CSR или Client Side Rendering — это именно то, о чем говорится: html-оболочка приложения отправляется с сервера на клиент, а затем javascript заполняет содержимое в соответствии с маршрутом. По умолчанию* приложение Next использует рендеринг на стороне клиента для отображения контента на сайте.
Идеально использовать CSR, когда данные на сайте являются чисто динамическими, т.е. нет ничего определенного о том, какими будут данные, и данные подаются динамически. В качестве примера можно привести платежный портал для магазина электронной коммерции, окно чата в приложении для общения и т.д.
Вам не нужно делать ничего отличного от написания обычных React компонентов в Next, чтобы использовать CSR, как я уже сказал, Next использует CSR по умолчанию*.
export function ReactComponent() {
useEffect(() => {
// fetch data here
}, [])
return (
// render the component
)
}
ПРОТИВ: Ваши страницы динамичны, и не происходит постоянных обращений к серверу.
ПРОТИВ: Если данные будут огромными, скорее всего, будут задержки и состояния загрузки (плохой UX) и ботам браузера нечего будет читать (плохой SEO).
SSR: Рендеринг на стороне сервера
Когда вы используете SSR или Server Side Rendering, Next получает данные, необходимые для пути, на самом сервере и строит страницу для этого маршрута на сервере, а затем отправляет предварительно построенную страницу клиенту и, следовательно, обеспечивает страницу полностью загруженной контентом с самого начала.
SSR идеально подходит для тех случаев, когда вы хотите, чтобы пользователь не заметил задержек в загрузке страницы и данных, поступающих на страницу, что улучшает пользовательский опыт. Он также может быть использован там, где не нужно, чтобы страница была чисто динамической, а нужно улучшить SEO сайта.
В Next.js вы можете просто заставить страницу использовать стратегию рендеринга SSR, добавив метод getServerSideProps() и извлекая все зависимые данные в этом методе, экспортируя реквизиты из него и потребляя их в компоненте React для страницы.
export async function getServerSideProps() {
// fetch data here
return {
props: {
data,
}
}
}
export function ReactComponent(props) {
return (
// render the component
)
}
ПРОТИВ: Лучшее SEO, лучший пользовательский опыт
ПРОТИВ: Больше вызовов сервера
SSG: генерация статических сайтов
Это лучший вариант (объективно 😁), SSG или Static Site Generation — это когда страницы для маршрутов создаются и хранятся в CDN, так что при каждом переходе по маршруту страница с готовностью создается из CDN. (Just WOW)
Эта стратегия лучше всего подходит для случаев, когда данные на странице меняются нечасто, например, для блогов и целевых страниц. Вы можете использовать SSG и для меняющихся данных, но это не идеальный вариант.
В Next.js для реализации страницы/маршрута как статически генерируемой страницы вам просто нужно добавить дополнительный метод, предоставляемый Next, под названием getStaticProps(), получить данные здесь, экспортировать их как props и затем использовать их в компоненте React для страницы/маршрута.
Сложность заключается в том, что когда вам нужно создать динамические маршруты SSG. В таких случаях нужно добавить еще один метод, предоставляемый next, под названием getStaticPaths(), вернуть отсюда все возможные подмаршруты и использовать их в качестве идентификаторов в методе getStaticProps().
export async function getStaticPaths() {
// get data here
return {
params: {
id: *ID for this page*,
}
}
}
export async function getStaticProps() {
// fetch data here
return {
props: {
data,
}
}
}
export function ReactComponent(props) {
return (
// render the component
)
}
ПРОС: Супербыстро, нет вызовов сервера, напрямую сервер из CDN
ПРОТИВ: Не подходит для часто меняющихся данных
Заключение
Все эти стратегии рендеринга — разные инструменты, и каждый из них подходит для разных задач и решает разные задачи. Замечательно то, что в Next.js вы можете настроить для каждой страницы/маршрута, какую стратегию использовать для этой конкретной страницы.
* Ну Next.js не использует CSR на всем пути. Он будет обслуживать серверный рендеринг страниц для пути, а затем CSR возьмет на себя.