mirror of
https://github.com/hanzoai/next.js.git
synced 2026-10-30 14:46:38 +00:00
c2b4c0815c
This PRs unifies the caching story across the docs, making Cache Components the happy path, while still providing guidance to users in the old model. However, instead of explaining the old model and its caching layers, we've created a new guide focusing on what APIs to use and when. This follow-up PR aligns terminology across the docs: https://github.com/vercel/next.js/pull/90589 ## IA updates Getting Started section: - Improves Getting Started progression: - **Before:** CC → Fetching Data → Updating Data → Caching and Revalidating (old and new model mixed) - **After:** Fetching Data (Dynamic) → Mutating Data (Dynamic) → Caching with CC (Prerendering) → Revalidating with CC. - New: `caching.mdx` (CC-first) - Structure: - Enabling Cache Components - Data vs UI-level caching - Working with request time APIs - Passing request values to cached functions - Working with non-deterministic operations - Working with synchronous operations - How rendering works (PPR and static shell story) - New: `revalidating.mdx` (CC-first) - Explains how to use `cacheLife` and `cacheTag` Guides Section: - New: `caching-and-revalidating.mdx` (Previous Model) - For users who are not using CC, includes `fetch` options and route segment config - Moves route segment config options that don't apply to CC from API reference to this guide (for easy archiving in the future). - New: `migrating-to-cache-components.mdx` (WIP) - Del: `caching.mdx` 😌 ## Terminology We should remove caching layers from the docs. Users only needed to be exposed to them when they were configured independently, but the new CC APIs work across layers. To make it easier to review this PR, I'm consolidating terminology and fixing broken links in a new PR: https://github.com/vercel/next.js/pull/90589 --------- Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com> Co-authored-by: Joseph <[email protected]>
109 lines
4.9 KiB
Plaintext
109 lines
4.9 KiB
Plaintext
---
|
|
title: getServerSideProps
|
|
description: Fetch data on each request with `getServerSideProps`.
|
|
---
|
|
|
|
`getServerSideProps` is a Next.js function that can be used to fetch data and render the contents of a page at request time.
|
|
|
|
## Example
|
|
|
|
You can use `getServerSideProps` by exporting it from a Page Component. The example below shows how you can fetch data from a 3rd party API in `getServerSideProps`, and pass the data to the page as props:
|
|
|
|
```tsx filename="pages/index.tsx" switcher
|
|
import type { InferGetServerSidePropsType, GetServerSideProps } from 'next'
|
|
|
|
type Repo = {
|
|
name: string
|
|
stargazers_count: number
|
|
}
|
|
|
|
export const getServerSideProps = (async () => {
|
|
// Fetch data from external API
|
|
const res = await fetch('https://api.github.com/repos/vercel/next.js')
|
|
const repo: Repo = await res.json()
|
|
// Pass data to the page via props
|
|
return { props: { repo } }
|
|
}) satisfies GetServerSideProps<{ repo: Repo }>
|
|
|
|
export default function Page({
|
|
repo,
|
|
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
|
|
return (
|
|
<main>
|
|
<p>{repo.stargazers_count}</p>
|
|
</main>
|
|
)
|
|
}
|
|
```
|
|
|
|
```jsx filename="pages/index.js" switcher
|
|
export async function getServerSideProps() {
|
|
// Fetch data from external API
|
|
const res = await fetch('https://api.github.com/repos/vercel/next.js')
|
|
const repo = await res.json()
|
|
// Pass data to the page via props
|
|
return { props: { repo } }
|
|
}
|
|
|
|
export default function Page({ repo }) {
|
|
return (
|
|
<main>
|
|
<p>{repo.stargazers_count}</p>
|
|
</main>
|
|
)
|
|
}
|
|
```
|
|
|
|
## When should I use `getServerSideProps`?
|
|
|
|
You should use `getServerSideProps` if you need to render a page that relies on personalized user data, or information that can only be known at request time. For example, `authorization` headers or a geolocation.
|
|
|
|
If you do not need to fetch the data at request time, or would prefer to cache the data and prerendered HTML, we recommend using [`getStaticProps`](/docs/pages/building-your-application/data-fetching/get-static-props).
|
|
|
|
## Behavior
|
|
|
|
- `getServerSideProps` runs on the server.
|
|
- `getServerSideProps` can only be exported from a **page**.
|
|
- `getServerSideProps` returns JSON.
|
|
- When a user visits a page, `getServerSideProps` will be used to fetch data at request time, and the data is used to render the initial HTML of the page.
|
|
- `props` passed to the page component can be viewed on the client as part of the initial HTML. This is to allow the page to be [hydrated](https://react.dev/reference/react-dom/hydrate) correctly. Make sure that you don't pass any sensitive information that shouldn't be available on the client in `props`.
|
|
- When a user visits the page through [`next/link`](/docs/pages/api-reference/components/link) or [`next/router`](/docs/pages/api-reference/functions/use-router), Next.js sends an API request to the server, which runs `getServerSideProps`.
|
|
- You do not have to call a Next.js [API Route](/docs/pages/building-your-application/routing/api-routes) to fetch data when using `getServerSideProps` since the function runs on the server. Instead, you can call a CMS, database, or other third-party APIs directly from inside `getServerSideProps`.
|
|
|
|
> **Good to know:**
|
|
>
|
|
> - See [`getServerSideProps` API reference](/docs/pages/api-reference/functions/get-server-side-props) for parameters and props that can be used with `getServerSideProps`.
|
|
> - You can use the [next-code-elimination tool](https://next-code-elimination.vercel.app/) to verify what Next.js eliminates from the client-side bundle.
|
|
|
|
## Error Handling
|
|
|
|
If an error is thrown inside `getServerSideProps`, it will show the `pages/500.js` file. Check out the documentation for [500 page](/docs/pages/building-your-application/routing/custom-error#500-page) to learn more on how to create it. During development, this file will not be used and the development error overlay will be shown instead.
|
|
|
|
## Edge Cases
|
|
|
|
### Caching with Server-Side Rendering (SSR)
|
|
|
|
You can use caching headers (`Cache-Control`) inside `getServerSideProps` to cache dynamic responses. For example, using [`stale-while-revalidate`](https://web.dev/stale-while-revalidate/).
|
|
|
|
```jsx
|
|
// This value is considered fresh for ten seconds (s-maxage=10).
|
|
// If a request is repeated within the next 10 seconds, the previously
|
|
// cached value will still be fresh. If the request is repeated before 59 seconds,
|
|
// the cached value will be stale but still render (stale-while-revalidate=59).
|
|
//
|
|
// In the background, a revalidation request will be made to populate the cache
|
|
// with a fresh value. If you refresh the page, you will see the new value.
|
|
export async function getServerSideProps({ req, res }) {
|
|
res.setHeader(
|
|
'Cache-Control',
|
|
'public, s-maxage=10, stale-while-revalidate=59'
|
|
)
|
|
|
|
return {
|
|
props: {},
|
|
}
|
|
}
|
|
```
|
|
|
|
However, before reaching for `cache-control`, we recommend seeing if [`getStaticProps`](/docs/pages/building-your-application/data-fetching/get-static-props) with [ISR](/docs/pages/guides/incremental-static-regeneration) is a better fit for your use case.
|