Fetching Data
Last updated
Was this helpful?
Last updated
Was this helpful?
We’ll talk about the three unique Next.js functions you can use to fetch data for pre-rendering:
(Static Generation): Fetch data at build time.
(Static Generation): Specify to pre-render based on data.
(Server-side Rendering): Fetch data on each request.
In addition, we’ll talk briefly about how to do fetch data on the client side.
getStaticProps
(Static Generation)If you export an async
function called getStaticProps
from a page, Next.js will pre-render this page at build time using the props returned by getStaticProps
.
The context
parameter is an object containing the following keys:
params
contains the route parameters for pages using dynamic routes. For example, if the page name is [id].js
, then params
will look like { id: ... }
. To learn more, take a look at the . You should use this together with getStaticPaths
, which we’ll explain later.
preview
is true
if the page is in the preview mode and false
otherwise. See the .
previewData
contains the preview data set by setPreviewData
. See the .
You should use getStaticProps
if:
The data required to render the page is available at build time ahead of a user’s request.
The data comes from headless CMS.
The data can be publicly cached (not user-specific).
The page must be pre-rendered (for SEO) and be very fast — getStaticProps
generates HTML and JSON files, both of which can be cached by a CDN for performance.
For TypeScript, you can use the GetStaticProps
type from next
:
If you want to get inferred typings for your props, you can use InferGetStaticPropsType<typeof getStaticProps>
, like this:
Files can be read directly from the filesystem in getStaticProps
.
In order to do so you have to get the full path to a file.
Since Next.js compiles your code into a separate directory you can't use __dirname
as the path it will return will be different from the pages directory.
Instead you can use process.cwd()
which gives you the directory where Next.js is being executed.
Only runs at build time
Because getStaticProps
runs at build time, it does not receive data that’s only available during request time, such as query parameters or HTTP headers as it generates static HTML.
Write server-side code directly
Note that getStaticProps
runs only on the server-side. It will never be run on the client-side. It won’t even be included in the JS bundle for the browser. That means you can write code such as direct database queries without them being sent to browsers. You should not fetch an API route from getStaticProps
— instead, you can write the server-side code directly in getStaticProps
.
Statically Generates both HTML and JSON
When a page with getStaticProps
is pre-rendered at build time, in addition to the page HTML file, Next.js generates a JSON file holding the result of running getStaticProps
.
Only allowed in a page
getStaticProps
can only be exported from a page. You can’t export it from non-page files.
One of the reasons for this restriction is that React needs to have all the required data before the page is rendered.
Also, you must use export async function getStaticProps() {}
— it will not work if you add getStaticProps
as a property of the page component.
Runs on every request in development
In development (next dev
), getStaticProps
will be called on every request.
Preview Mode
In some cases, you might want to temporarily bypass Static Generation and render the page at request time instead of build time. For example, you might be using a headless CMS and want to preview drafts before they're published.
If you export an async
function called getStaticPaths
from a page that uses dynamic routes, Next.js will statically pre-render all the paths specified by getStaticPaths
.
The paths key (required)
The paths
key determines which paths will be pre-rendered. For example, suppose that you have a page that uses dynamic routes named pages/posts/[id].js
. If you export getStaticPaths
from this page and return the following for paths
:
Then Next.js will statically generate posts/1
and posts/2
at build time using the page component in pages/posts/[id].js
.
Note that the value for each params
must match the parameters used in the page name:
If the page name is pages/posts/[postId]/[commentId]
, then params
should contain postId
and commentId
.
If the page name uses catch-all routes, for example pages/[...slug]
, then params
should contain slug
which is an array. For example, if this array is ['foo', 'bar']
, then Next.js will statically generate the page at /foo/bar
.
The fallback key (required)
The object returned by getStaticPaths
must contain a boolean fallback
key.
fallback: false
If fallback
is false
, then any paths not returned by getStaticPaths
will result in a 404 page. You can do this if you have a small number of paths to pre-render - so they are all statically generated during build time. It’s also useful when the new pages are not added often. If you add more items to the data source and need to render the new pages, you’d need to run the build again.
fallback: true
If fallback
is true
, then the behavior of getStaticProps
changes:
The paths returned from getStaticPaths
will be rendered to HTML at build time.
In the background, Next.js will statically generate the requested path HTML and JSON. This includes running getStaticProps
.
When that’s done, 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, just like other pages pre-rendered at build time.
Fallback pages
In the “fallback” version of a page:
The page’s props will be empty.
Here’s an example that uses isFallback
:
When is fallback: true useful?
fallback: true
is useful if your app has a very large number of static pages that depend on data (think: a very large e-commerce site). You want to pre-render all product pages, but then your builds would take forever.
Instead, you may statically generate a small subset of pages and use fallback: true
for the rest. When someone requests a page that’s not generated yet, the user will see the page with a loading indicator. Shortly after, getStaticProps
finishes and the page will be rendered with the requested data. From now on, everyone who requests the same page will get the statically pre-rendered page.
This ensures that users always have a fast experience while preserving fast builds and the benefits of Static Generation.
You should use getStaticPaths
if you’re statically pre-rendering pages that use dynamic routes.
For TypeScript, you can use the GetStaticPaths
type from next
:
Use together with getStaticProps
When you use getStaticProps
on a page with dynamic route parameters, you must use getStaticPaths
.
You cannot use getStaticPaths
with getServerSideProps
.
Only runs at build time on server-side
getStaticPaths
only runs at build time on server-side.
Only allowed in a page
getStaticPaths
can only be exported from a page. You can’t export it from non-page files.
Also, you must use export async function getStaticPaths() {}
— it will not work if you add getStaticPaths
as a property of the page component.
Runs on every request in development
In development (next dev
), getStaticPaths
will be called on every request.
If you export an async
function called getServerSideProps
from a page, Next.js will pre-render this page on each request using the data returned by getServerSideProps
.
The context
parameter is an object containing the following keys:
query
: The query string.
You should use getServerSideProps
only if you need to pre-render a page whose data must be fetched at request time. Time to first byte (TTFB) will be slower than getStaticProps
because the server must compute the result on every request, and the result cannot be cached by a CDN without extra configuration.
For TypeScript, you can use the GetServerSideProps
type from next
:
If you want to get inferred typings for your props, you can use InferGetServerSidePropsType<typeof getServerSideProps>
, like this:
Only runs on server-side
getServerSideProps
only runs on server-side and never runs on the browser. If a page uses getServerSideProps
, then:
When you request this page directly, getServerSideProps
runs at the request time, and this page will be pre-rendered with the returned props.
Only allowed in a page
getServerSideProps
can only be exported from a page. You can’t export it from non-page files.
Also, you must use export async function getServerSideProps() {}
— it will not work if you add getServerSideProps
as a property of the page component.
If your page contains frequently updating data, and you don’t need to pre-render the data, you can fetch the data on the client side. An example of this is user-specific data. Here’s how it works:
First, immediately show the page without data. Parts of the page can be pre-rendered using Static Generation. You can show loading states for missing data.
Then, fetch the data on the client side and display it when ready.
This approach works well for user dashboard pages, for example. Because a dashboard is a private, user-specific page, SEO is not relevant and the page doesn’t need to be pre-rendered. The data is frequently updated, which requires request-time data fetching.
Note: You can import modules in top-level scope for use in getStaticProps
. Imports used in getStaticProps
will not be bundled for the client-side, as .
Here’s an example which uses getStaticProps
to fetch a list of blog posts from a CMS (content management system). This example is also in the .
You can use to verify what Next.js eliminates from the client-side bundle.
This JSON file will be used in client-side routing through next/link
() or next/router
(). When you navigate to a page that’s pre-rendered using getStaticProps
, Next.js fetches this JSON file (pre-computed at build time) and uses it as the props for the page component. This means that client-side page transitions will not call getStaticProps
as only the exported JSON is used.
This use case is supported by Next.js by the feature called Preview Mode. Learn more on the .
If a page has dynamic routes () and uses getStaticProps
it needs to define a list of paths that have to be rendered to HTML at build time.
Here’s an example which pre-renders one blog post per page called pages/posts/[id].js
. The list of blog posts will be fetched from a CMS and returned by getStaticPaths
. Then, for each page, it fetches the post data from a CMS using getStaticProps
. This example is also in the .
The paths that have not been generated at build time will not result in a 404 page. Instead, Next.js will serve a “fallback” version of the page on the first request to such a path (see below for details).
fallback: true
is not supported when using .
Using the , you can detect if the fallback is being rendered, router.isFallback
will be true
.
params
: If this page uses a dynamic route, params
contains the route parameters. If the page name is [id].js
, then params
will look like { id: ... }
. To learn more, take a look at the .
req
: .
res
: .
preview
: preview
is true
if the page is in the preview mode and false
otherwise. See the .
previewData
: The preview data set by setPreviewData
. See the .
Note: You can import modules in top-level scope for use in getServerSideProps
. Imports used in getServerSideProps
will not be bundled for the client-side, as .
Here’s an example which uses getServerSideProps
to fetch data at request time and pre-renders it. This example is also in the .
If you don’t need to pre-render the data, then you should consider fetching data on the client side. .
When you request this page on client-side page transitions through next/link
() or next/router
(), Next.js sends an API request to the server, which runs getServerSideProps
. It’ll return JSON that contains the result of running getServerSideProps
, and the JSON will be used to render the page. All this work will be handled automatically by Next.js, so you don’t need to do anything extra as long as you have getServerSideProps
defined.
You can use to verify what Next.js eliminates from the client-side bundle.
The team behind Next.js has created a React hook for data fetching called . We highly recommend it if you’re fetching data on the client side. It handles caching, revalidation, focus tracking, refetching on interval, and more. And you can use it like so: