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]>
142 lines
5.1 KiB
Plaintext
142 lines
5.1 KiB
Plaintext
---
|
||
title: getStaticPaths
|
||
description: Fetch data and generate static pages with `getStaticPaths`. Learn more about this API for data fetching in Next.js.
|
||
---
|
||
|
||
If a page has [Dynamic Routes](/docs/pages/building-your-application/routing/dynamic-routes) and uses `getStaticProps`, it needs to define a list of paths to be statically generated.
|
||
|
||
When you export a function called `getStaticPaths` (Static Site Generation) from a page that uses dynamic routes, Next.js will statically prerender all the paths specified by `getStaticPaths`.
|
||
|
||
```tsx filename="pages/repo/[name].tsx" switcher
|
||
import type {
|
||
InferGetStaticPropsType,
|
||
GetStaticProps,
|
||
GetStaticPaths,
|
||
} from 'next'
|
||
|
||
type Repo = {
|
||
name: string
|
||
stargazers_count: number
|
||
}
|
||
|
||
export const getStaticPaths = (async () => {
|
||
return {
|
||
paths: [
|
||
{
|
||
params: {
|
||
name: 'next.js',
|
||
},
|
||
}, // See the "paths" section below
|
||
],
|
||
fallback: true, // false or "blocking"
|
||
}
|
||
}) satisfies GetStaticPaths
|
||
|
||
export const getStaticProps = (async (context) => {
|
||
const res = await fetch('https://api.github.com/repos/vercel/next.js')
|
||
const repo = await res.json()
|
||
return { props: { repo } }
|
||
}) satisfies GetStaticProps<{
|
||
repo: Repo
|
||
}>
|
||
|
||
export default function Page({
|
||
repo,
|
||
}: InferGetStaticPropsType<typeof getStaticProps>) {
|
||
return repo.stargazers_count
|
||
}
|
||
```
|
||
|
||
```jsx filename="pages/repo/[name].js" switcher
|
||
export async function getStaticPaths() {
|
||
return {
|
||
paths: [
|
||
{
|
||
params: {
|
||
name: 'next.js',
|
||
},
|
||
}, // See the "paths" section below
|
||
],
|
||
fallback: true, // false or "blocking"
|
||
}
|
||
}
|
||
|
||
export async function getStaticProps() {
|
||
const res = await fetch('https://api.github.com/repos/vercel/next.js')
|
||
const repo = await res.json()
|
||
return { props: { repo } }
|
||
}
|
||
|
||
export default function Page({ repo }) {
|
||
return repo.stargazers_count
|
||
}
|
||
```
|
||
|
||
The [`getStaticPaths` API reference](/docs/pages/api-reference/functions/get-static-paths) covers all parameters and props that can be used with `getStaticPaths`.
|
||
|
||
## When should I use getStaticPaths?
|
||
|
||
You should use `getStaticPaths` if you’re statically prerendering pages that use dynamic routes and:
|
||
|
||
- The data comes from a headless CMS
|
||
- The data comes from a database
|
||
- The data comes from the filesystem
|
||
- The data can be publicly cached (not user-specific)
|
||
- The page must be prerendered (for SEO) and be very fast — `getStaticProps` generates `HTML` and `JSON` files, both of which can be cached by a CDN for performance
|
||
|
||
## When does getStaticPaths run
|
||
|
||
`getStaticPaths` will only run during build in production, it will not be called during runtime. You can validate code written inside `getStaticPaths` is removed from the client-side bundle [with this tool](https://next-code-elimination.vercel.app/).
|
||
|
||
### How does getStaticProps run with regards to getStaticPaths
|
||
|
||
- `getStaticProps` runs during `next build` for any `paths` returned during build
|
||
- `getStaticProps` runs in the background when using `fallback: true`
|
||
- `getStaticProps` is called before initial render when using `fallback: blocking`
|
||
|
||
## Where can I use getStaticPaths
|
||
|
||
- `getStaticPaths` **must** be used with `getStaticProps`
|
||
- You **cannot** use `getStaticPaths` with [`getServerSideProps`](/docs/pages/building-your-application/data-fetching/get-server-side-props)
|
||
- You can export `getStaticPaths` from a [Dynamic Route](/docs/pages/building-your-application/routing/dynamic-routes) that also uses `getStaticProps`
|
||
- You **cannot** export `getStaticPaths` from non-page file (e.g. your `components` folder)
|
||
- You must export `getStaticPaths` as a standalone function, and not a property of the page component
|
||
|
||
## Runs on every request in development
|
||
|
||
In development (`next dev`), `getStaticPaths` will be called on every request.
|
||
|
||
## Generating paths on-demand
|
||
|
||
`getStaticPaths` allows you to control which pages are generated during the build instead of on-demand with [`fallback`](/docs/pages/api-reference/functions/get-static-paths#fallback-blocking). Generating more pages during a build will cause slower builds.
|
||
|
||
You can defer generating all pages on-demand by returning an empty array for `paths`. This can be especially helpful when deploying your Next.js application to multiple environments. For example, you can have faster builds by generating all pages on-demand for previews (but not production builds). This is helpful for sites with hundreds/thousands of static pages.
|
||
|
||
```jsx filename="pages/posts/[id].js"
|
||
export async function getStaticPaths() {
|
||
// When this is true (in preview environments) don't
|
||
// prerender any static pages
|
||
// (faster builds, but slower initial page load)
|
||
if (process.env.SKIP_BUILD_STATIC_GENERATION) {
|
||
return {
|
||
paths: [],
|
||
fallback: 'blocking',
|
||
}
|
||
}
|
||
|
||
// Call an external API endpoint to get posts
|
||
const res = await fetch('https://.../posts')
|
||
const posts = await res.json()
|
||
|
||
// Get the paths we want to prerender based on posts
|
||
// In production environments, prerender all pages
|
||
// (slower builds, but faster initial page load)
|
||
const paths = posts.map((post) => ({
|
||
params: { id: post.id },
|
||
}))
|
||
|
||
// { fallback: false } means other routes should 404
|
||
return { paths, fallback: false }
|
||
}
|
||
```
|