What happens when a user navigates to a dynamic route that was not pre-generated by generateStaticParams? How do you control this with dynamicParams?

Question

Accepted Answer

In Next.js App Router, when a user navigates to a dynamic route that wasn't pre-generated by `generateStaticParams`, the behavior is determined by the `dynamicParams` export. This setting controls whether Next.js should generate pages on-demand when they're first requested. With `dynamicParams: true` (default), Next.js will generate the page on the first visit and cache it for subsequent requests. With `dynamicParams: false`, any non-pre-generated path returns a 404. This gives developers fine-grained control over the trade-off between build time and user experience. If you don't explicitly set `dynamicParams`, it defaults to `true`. This means when a user requests a path that wasn't included in your `generateStaticParams` return array, Next.js will generate the page on-demand (server-side render it), cache the result, and serve it to the user. Future requests for the same path will be served from cache. This is perfect for large sites where you can't pre-render everything at build time—you pre-render popular paths and let long-tail content generate as users request it . ```tsx // app/products/[id]/page.tsx // Pre-render only popular products export async function generateStaticParams() { const products = await fetch('https://api.example.com/products?popular=true') .then(res => res.json()); return products.map((product) => ({ id: product.id.toString(), })); } // dynamicParams defaults to true - generate on-demand for other paths export default async function ProductPage({ params }: { params: { id: string } }) { const product = await fetch(`https://api.example.com/products/${params.id}`) .then(res => res.json()); return

{product.name}

; } // When user visits /products/999 (not pre-rendered): // 1. Next.js generates the page on first request (may be slower) // 2. Page is cached for future requests // 3. Subsequent visits get static HTML from cache ``` When you set `dynamicParams: false`, you're telling Next.js that your `generateStaticParams` function returns an exhaustive list of all possible paths. Any path not included should return a 404 page. This is ideal for sites with a known, fixed set of content—like a blog with a finite number of posts that you can generate at build time. It provides the best performance (all pages are static) and ensures that users never encounter a slow first-visit generation, but it requires that you know all possible paths at build time . ```tsx // app/blog/[slug]/page.tsx // Generate ALL blog posts at build time export async function generateStaticParams() { const posts = await fetch('https://api.example.com/posts') .then(res => res.json()); return posts.map((post) => ({ slug: post.slug, })); } // Prevent on-demand generation export const dynamicParams = false; export default async function BlogPost({ params }: { params: { slug: string } }) { const post = await fetch(`https://api.example.com/posts/${params.slug}`) .then(res => res.json()); return

{post.title}

; } // When user visits /blog/non-existent-slug: // Immediately returns 404 - no attempt to generate // When user visits /blog/new-post (published after build): // Also returns 404 until you rebuild the app ``` dynamicParams: true in App Router corresponds to `fallback: true` or `fallback: 'blocking'` in Pages Router, depending on whether you use Suspense . dynamicParams: false directly corresponds to `fallback: false` in Pages Router . The main difference is that App Router's `dynamicParams: true` combines both the loading state (with Suspense) and blocking behavior, whereas Pages Router had separate `true` and `'blocking'` options . In App Router, you control the loading experience with `loading.tsx` files, which automatically provide Suspense boundaries for on-demand generated pages . `dynamicParams` works alongside the `revalidate` export. When `dynamicParams: true` and you set `revalidate: 3600`, on-demand generated pages will also follow the revalidation schedule—they'll be regenerated in the background after 3600 seconds just like pre-rendered pages . This means long-tail content isn't second-class; it gets the same ISR benefits as popular content. When `dynamicParams: false`, the `revalidate` setting only applies to pre-generated pages; non-generated paths are permanently 404 and never revalidated. ```tsx // app/products/[id]/page.tsx // Pre-render popular products export async function generateStaticParams() { const popular = await getPopularProducts(1000); return popular.map(p => ({ id: p.id })); } // Generate other products on-demand, then revalidate every hour export const dynamicParams = true; export const revalidate = 3600; export default async function ProductPage({ params }: { params: { id: string } }) { const product = await getProduct(params.id); return ; } // All products (both pre-rendered and on-demand) revalidate every hour // This creates a truly scalable system

What happens when a user navigates to a dynamic route that was not pre-generated by generateStaticParams? How do you control this with dynamicParams?

When a user visits a non-pre-generated route, behavior is controlled by the dynamicParams export: true generates the page on-demand and caches it, false returns 404, and omitted defaults to true in App Router

What happens when a user navigates to a dynamic route that was not pre-generated by generateStaticParams? How do you control this with dynamicParams?

When a user visits a non-pre-generated route, behavior is controlled by the dynamicParams export: true generates the page on-demand and caches it, false returns 404, and omitted defaults to true in App Router

Scenario Questions

Follow-up Questions