Skip to content

Commit

Permalink
docs: update get-static-paths.md (#40205)
Browse files Browse the repository at this point in the history
I found that `fallback: true` behaves like `fallback: blocking` when client-side page transition, but document doesn't mention the behavior.
I tried following.

* created a SSG page which has getStaticPaths and getStaticProps, and the getStaticProps is too slow(something like `await setTimeout(10000)`)
* `next build && next start`, not `next dev`
* tried page reload and client-side page transition both

getServerSideProps document explains about client-side page transition.
https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props#when-does-getserversideprops-run

On the other hand, getStaticPaths didn't explain this behavior, so I added it.



## Bug

- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`

## Feature

- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`

## Documentation / Examples

- [x] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
  • Loading branch information
sumiren committed Sep 6, 2022
1 parent fa08a17 commit 5c2faad
Showing 1 changed file with 1 addition and 0 deletions.
1 change: 1 addition & 0 deletions docs/api-reference/data-fetching/get-static-paths.md
Expand Up @@ -121,6 +121,7 @@ If `fallback` is `true`, then the behavior of `getStaticProps` changes in the fo

- The paths returned from `getStaticPaths` will be rendered to `HTML` at build time by `getStaticProps`.
- The paths that have not been generated at build time will **not** result in a 404 page. Instead, Next.js will serve a [“fallback”](#fallback-pages) version of the page on the first request to such a path. Web crawlers, such as Google, won't be served a fallback and instead the path will behave as in [`fallback: 'blocking'`](#fallback-blocking).
- When a page with `fallback: true` is navigated to through `next/link` or `next/router` (client-side) Next.js will _not_ serve a fallback and instead the page will behave as [`fallback: 'blocking'`](#fallback-blocking).
- In the background, Next.js will statically generate the requested path `HTML` and `JSON`. This includes running `getStaticProps`.
- When complete, the browser receives the `JSON` for the generated path. This will be used to automatically render the page with the required props. From the user’s perspective, the page will be swapped from the fallback page to the full page.
- At the same time, Next.js adds this path to the list of pre-rendered pages. Subsequent requests to the same path will serve the generated page, like other pages pre-rendered at build time.
Expand Down

0 comments on commit 5c2faad

Please sign in to comment.