Ability to opt in/out of Incremental Static Regeneration on a per route basis on dynamic route group

[pranaypratyush]

Feature request

Ability to opt in/out of Incremental Static Regeneration on a per route basis on dynamic route group

Is your feature request related to a problem? Please describe.

When getStaticProps is used in combination with dynamic routes we need a method getStaticPaths that returns {paths: [{params:{...}], fallback: true|false} but I want to be able to choose ISR on a per path basis.

Describe the solution you'd like

Change the config object type to [{params:{...}, fallback: true|false}, {params:{...}, fallback: true|false}, ... ]

[Timer]

You can choose this in the return value within getStaticProps.

[pranaypratyush]

One getStaticProps is common for one dynamic group. Then how can we do that there?

[balazsorban44]

If I understand your problem correctly, you can use a simple if else in getStaticProps, in one block you return revalidate, in the other you do not. I have actually just done this today, where we use the url as an id to fetch data for a page, but the page can have multiple types. I use the page type to indicate if they need to be revalidated or not. Some pages we have can stay the same until the next build, some we want to keep up to date.

Tip, depending on your case, it may be OK to return an empty array in getStaticPaths with fallback true, and let everything be generated runtime for a faster build. You may be aware of this, I just wanted to share. :)

[pranaypratyush]

"... in one block you return revalidate ..." what do you mean by this?
What I really want to do is to render on build only the monthly active pages and let others be rendered at runtime. Otherwise when I redeploy there would be a sudden drop in performance as lots of pages get requested for render at once. Is that a correct assumption?

[pranaypratyush]

I never knew that we could actually pass feedback: true key from getStaticProps. I am quite confused.

[balazsorban44]

An (oversimplified) example:

export async function getStaticPaths() {
  return {
    paths: [
      "/any/url",
      "/you/want",
      "/to/render",
      "/at/buildtime"
    ],
   fallback: true
  }
}

export async function getStaticProps(ctx) {
 const props = await getProps(ctx)
  return {
    props
  }
}

Any path not defined in getStaticPaths will be generated at build time. You do not necessarily have to define all pages in getStaticPaths.

From the docs:

The paths returned from getStaticPaths will be rendered to HTML at build time.
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 “Fallback pages” below for details).
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.

What I really want to do is to render on build only the monthly active pages and let others be rendered at runtime.

So you only list your "monthly active pages" in getStaticPaths, and leave out the rest. they will be handled at runtime.

[pranaypratyush]

Thanks. I see now that I had interpreted the docs all wrong.

[balazsorban44]

You are welcome! Could you mark this discussion as answered? :)