[NEXT-1550] App Router with output: export does not support useParams() on client

[styfle]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0
    Binaries:
      Node: 18.17.1
      pnpm: 8.6.12
    Relevant Packages:
      next: 13.4.20-canary.2
      react: 18.2.0
      react-dom: 18.2.0
    Next.js Config:
      output: export

Which area(s) of Next.js are affected? (leave empty if unsure)

App Router, Static HTML Export (output: "export")

Link to the code that reproduces this issue or a replay of the bug

https://github.com/curated-tests/next-issue-48022

To Reproduce

The page in question is /app/blog-app/[slug]/page.tsx

next build

Describe the Bug

Fails with an error:

Error: Page "/blog-app/[slug]" is missing "generateStaticParams()" so it cannot be used with "output: export" config.

This is expected right now because its not implemented, but it would be nice to support this so that App Router can match Pages Router.

Expected Behavior

Ideally, the build should complete and navigation should work client side.

pnpm build
cd out
python3 -m http.server 3000

• Visit http://localhost:3000
• Click on Blog App (/blog-app/)
• Click on One (/blog-app/one)
• Should render the page on the client

Which browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

python3 -m http.server 3000

_NEXT-1550

[xray-robot]

Perhaps there are dates when this is scheduled to be done? Or is it better to use Pages Router?

FYI: Gatsby allows you to use dynamic routers in static exports without configuring server-side redirects. That's the only thing stopping us from moving our PWAs from Gatsby to Next.js

[danbockapps]

I did not see this error on 13.4.13. I started seeing it when I upgraded to 13.5.3.

[petejodo]

Can confirm this is working on 13.4.13. I'm curious if the functionality is therefore a regression or a bug that's become a feature 😅

[GabenGar]

But does it output the static page? If it doesn't and there is no error, then it's definitely a regression.

[styfle]

@petejodo What does "working" mean in this case? Previously there was no error message but it was failing silently. So in 13.5.0, a helpful error message was added explaining how to fix it.

See #48022 (comment) for more details.

However maybe there is a case when the error message shouldn't be printed? If you have code that was working with useParams() 13.14 as is no longer working in 13.15, please share the minimal code by creating a new issue and I'll get it fixed, thanks!

Please do NOT comment on this issue since it describes a new feature that needs to be implemented (not a regression).

[Frtrillo]

@petejodo What does "working" mean in this case? Previously there was no error message but it failing silently. So in 13.5.0, a helpful error message was added explaining how to fix it.

See #48022 (comment) for more details.

However maybe there is a case when the error message shouldn't be printed? If you have code that was working with useParams() 13.14 as is no longer working in 13.15, please share the minimal code by creating a new issue and I'll get it fixed, thanks!

Please do NOT comment on this issue since it describes a new feature that needs to be implemented (not a regression).

I can confirm that this issue persisted in version 13.4.13 as well. It failed silently as you said; there was no error during the build, but accessing the dynamic route resulted in a 404 error.
Sadly it appears that using dynamic routes with the app router and 'use client' is currently not possible. I hope it gets addressed soon, as it's just what's left for me, at least, to fully commit to the app router

[petejodo]

yeah I didn't see that at first and thought that it was working in my testing but I guess I somehow messed something up in my testing where I thought it was working but it definitely was not. Sorry, my mistake!

This put me in a bind because I misinterpreted the opening paragraphs to https://nextjs.org/docs/app/building-your-application/deploying/static-exports which made it seem I could port a SPA to nextjs and we just about finished porting it. That's my problem though, not yours' 😅 I think I can re-hack react-router back in even though that was giving me trouble at the start of the project

[eric-burel]

Hi, is this related to the error encountered in @leerob SPA example? The error message seems surprising, and params are meant to be obtained via page props rather than the useParams hook, but I wonder if it is considered the same root issue

[goerlitz]

Hi, I just started learning Next.js and I want to deploy my app as static SPA on Amazon S3. Hence, I added output: export. But I'm getting errors for the dynamic route pages using App Router.

1. Error: Page "/datasets/[slug]" is missing "generateStaticParams()" so it cannot be used with "output: export" config. when I execute npm run build .
2. After adding generateStaticParams() with some dummy values (because the real route params cannot be known at build time) I'm getting a runtime error (in dev mode) when calling the dynamic path with any other value. Error: Page "/datasets/[slug]/page" is missing param "/datasets/foo" in "generateStaticParams()", which is required with "output: export" config.
3. When further adding 'use client' I get Error: Page "/datasets/[slug]/page" cannot use both "use client" and export function "generateStaticParams()".
4. When I just add 'use client' but remove generateStaticParams() I'm getting Error: Page "/datasets/[slug]" is missing "generateStaticParams()" so it cannot be used with "output: export" config. again.

I'm stuck here. What am I supposed to do to get the dynamic routes working with the static export?

Maybe, I'm don't fully understand generateStaticParams() (yet), but when I use a dynamic route, I typically have many entries in a database that I wanna fetch and render on demand (either client or server side). I don't wanna pre-render millions of pages at build time. Moreover, I don't wanna rebuild the app whenever the database gets updated.

[eric-burel]

@goerlitz starting step 3 and 4 I think you get confused:

• move the code that needs "use client" into a separate file, for instance:

// app/datasets/[slug]/page.tsx
export const generateStaticParams()
export async function YourPage() {
  return <ClientPage />
}
// app/datasets/[slug]/ClientPage.tsx
"use client"
export async function ClientPage() {
  const [someState] = useState("foo")
  return <div>{someState}</div>
}

• As for generating the page with a dummy parameter, I am not sure what cause this error specifically (might but just a bug?), but anyway I think this approach won't work as is.

The thing is that if you use a dummy static param, Next only knows the dummy "/datasets/foo" route. So "/datasets/bar" won't work. You could do an URL rewrite from "/datasets/bar" to "/datasets/foo", but then the route parameter is lost.

You could opt for a query parameter instead.

Sadly until Next.js supports exporting dynamic routes that are not statically rendered like it did in Next 12 pages dir, I don't think you can use a dynamic route and do a static export, you should prefer a query parameter, + optionally an URL rewrite from a route param to a query param.

[goerlitz]

Thanks @eric-burel for the guidance.
Actually, after diving much deeper into Next.js, I realized that I was trying to make two different paradigms work together - which is a bad idea.

Having worked on SPA with Api backends in the past, I thought I could make Next.js output a SPA bundle with separate api code. Actually, I think that the first paragraph in https://nextjs.org/docs/app/building-your-application/deploying/static-exports is quite misleading in that sense:

Next.js enables starting as a static site or Single-Page Application (SPA), then later optionally upgrading to use features that require a server.

No, Next.js is not made for SPAs - it is a totally different paradigm with the goal to NOT do all rendering and routing in the browser but move more code to the server where computing is more efficient (SSR etc.). Hence, a typical Next.js app will never be an SPA (and should not be), because the application code is split up and runs on server and client likewise.

IMHO, for most applications - that usually have dynamic routing - the static export does not make sense to me at all.

[AndonMitev]

Does exists on 13.5.5 as well, I have tried to build a view with this routing structure:

/games
  [id]
     page.tsx

on production i had issues for previous versions, [id] was not found and it was navigating to home page, and now not even able to build to the this issue:

Error: Page "/page/[id]" is missing "generateStaticParams()" so it cannot be used with "output: export" config

[andreasfrey]

Can you please give an update, when this feature is planned? I mainly switchedto nextjs, because of the routing functionality. Now it forces me to host on a node server...

As a workaround i try out useing pages router again. [https://nextjs.org/docs/pages/building-your-application/routing/pages-and-layouts]

[goerlitz]

Now it forces me to host on a node server...

@andreasfrey, this is what I meant with "Next.js follows a different paradigm" than SPA.
Running a Next.js app on a node server is the default deployment.

If you are trying to use Next.js to create a traditional SPA (with dynamic routes) that can be packaged for hosting on a CDN, then you are doing something (conceptually) wrong. This is not what Next.js was designed for.

If you want to move from an SPA to Next.js (with all the nice features, like SSR etc.), you should

1. be okay with deploying everything to a node server (Vercel, Netlify, etc.) and changing your deployment pipelines
2. identify and define suitable boundaries between client and server components in your app (ie. dynamic vs. static parts)

[ifeltsweet]

Friends, it will come, not sure when though.

https://twitter.com/ifeltsweet/status/1782095113080164472

[cometyang]

Friends, we will wait, not sure how long though.😂

[ccmvn]

It's a joke. I'd say if we're lucky we'll see the feature in 2026 or, in the worst case, not at all 😂

[ronny1020]

It is always coming but never arrives. 🙃

[balazsorban44]

Hi all, just wanted to let you know that the issue was moved to discussion, but it not because of de-prioritizing! We have just done some cleanup on the repo, as per our triaging documentation, which states that feature requests are not supposed to be opened as issues. We welcome further discussions on this topic, and will keep tracking it.

[leerob]

@haugseth Good feedback, we can make the docs more clear that for this case, it is totally okay (and supported) to use the Pages Router. And in general, for awareness, the Pages Router continues to be supported with new improvements being landed.

[GabenGar]

@leerob
Should also remove this part from pages router documentation:

[hichemfantar]

@leerob
Should also remove this part from pages router documentation:

I agree, this statement is untrue

[leerob]

Updated: #67181

[wongk]

Updated: #67181

Thank you. This very statement caused us to migrate to the app router, only to have to migrate back to the pages router a few weeks later. I would even go so far as to say you should recommend exactly the opposite, to prevent others from having to go through the same headache for no reason.

Good to know: We recommend using the Pages router for enhanced static export support.

[mattbal]

Just ran into a problem with this :/

Please fix this Vercel

[MohamedKarrab]

I am migrating my code from CRA (create react app) to next.js and I can't use dynamic routes anymore because of this issue. Please fix it or at least put a workaround/explanation in the migration guide.

[haugseth]

Hello friend, the most logical migration path in my opinion, is by using the pages router... this should be fairly comparable to CRA. The docs should be updated, to avoid this pitfall as they frame every use case to migrate using the app router. The way I see it, the pages routers is the classic way of front end react, only by using file based routing, and the app routers is the new server component way of running react. Hope this can help your migration.

[MohamedKarrab]

The problem is that they recommend using app router, I don't know for how long the pages router will be supported. From my perspective, why would I migrate to Next.js if I can't use the full features or if they consider my use case secondary? And why is React recommending this as a rule of thumb as if it suits everyone, when they apparently don't care much about SPAs? This makes me wonder if I want to stick to Next.js or just use Vite with lazy loading. I hope React 19 ends this mess.

[leerob]

It is totally okay (and supported) to use the Pages Router. And in general, for awareness, the Pages Router continues to be supported with new improvements being landed. It is okay to use either router.

[hichemfantar]

@MohamedKarrab Pages Router is the only option for Next but Remix with SPA mode is also an option.
It uses react-router-dom and Vite under the hood in case you didn't know.
But obviously it's much better if the App Router supported dynamic urls.

[durchanek]

the Pages Router continues to be supported with new improvements being landed

I am afraid that every developer who had to migrate from the App Router back to the Pages Router with its clumsy layouts or missing route interception would disagree.

[SebastianGode]

Thanks for the clarifications about the pages router @leerob ! :)

I just want to know whether the dev team is planning to add / fix that functionality in the app router or not. If not then I would just migrate back to the pages router. If there's a fix incoming during the next half year however I would just wait.

Getting a clarification on the future of this topic would be great!

[leerob]

Yes, we plan to support this for the App Router as well in the future. We don't have a defined timeline yet, so Pages Router might be a better choice for you right now.

[XanderDeLaet]

Reverting to using paging router worked for me. I feel like there should be an option to run routing in App Router client side though.

[pswami]

Has there been any progress on this issue yet? I’m currently facing the same problem and wondering if there's a workaround or an update available.

[ccmvn]

Has there been any progress on this issue yet? I’m currently facing the same problem and wondering if there's a workaround or an update available.

The only workaround is to use the pages router for the corresponding routes, which in my opinion is a joke

[ronny1020]

There is another workaround to use the SearchParams if you don't care what the URL looks like, which in my opinion, is also not ideal.

[wenqi73]

Finally I know what's the difference bettween the 'app' and 'pages'...

[ferrohd]

@leerob @balazsorban44

The ongoing issue with statically exporting dynamic routes using the App Router in Next.js is a major issue that you have failed to fix for 10 months. Despite promises to address this critical problem, it has now been closed and downgraded to a discussion without any notice, explanation, or resolution.

This is completely unacceptable. Many of us rely on Next.js for its static site generation capabilities, including dynamic routes, and this has severely impacted our projects. The lack of resolution and communication on such a foundational issue is beyond frustrating.

Let me remind you, @leerob, of your comment on the original issue:

"We plan to fix this. I'm sorry we haven't gotten to it yet. But it will get fixed."

• What is the current status of this issue?
• Why was the issue closed and converted to a discussion without fixing it @balazsorban44?
• When can we expect a concrete fix?

The Next.js team needs to understand that there is no point in jumping on the AI hype ​​train et al if the foundational aspects of your framework aren't even there. We expect transparency, accountability and given that @vercel is a $3.25 bln dollar compay, a rapid resolution to this regression.

It’s time for the team to take responsibility and address this promptly.

Thank you.

[leerob]

Hi all, just wanted to let you know that the issue was moved to discussion, but it not because of de-prioritizing! We have just done some cleanup on the repo, as per our triaging documentation, which states that feature requests are not supposed to be opened as issues. We welcome further discussions on this topic, and will keep tracking it.

Please see this comment above – it is not a downgraded or closed. Apologies if that wasn't made clear enough on the issue before getting posted back to the discussion 🙏

Many of us rely on Next.js for its static site generation capabilities, including dynamic routes

We agree! We still plan to support this for the App Router. For right now, we recommend using the Pages Router for this. The Pages router is still fully supported with new features being added.

[isaachinman]

@leerob Is it correct in saying that an entire major release has come and gone, with this regression remaining unfixed?

If the timeline for a fix wasn't "in the next major release", it's genuinely hard to believe that you are prioritising this issue at all, and this discussion amounts to lip service.

[zdenham]

Lack of support for client side dynamic routes limits hosting optionality for sites using app router, which is why many are frustrated by this issue.

It doesn't seem like its in Vercel's best interest to offer great support for SSG with Next.js, because then devs can just host on S3 or whatever CDN, instead of being locked into Vercel or other serverless / edge providers.

Hoping maintainers jump on this and prove me wrong, but does highlight the conflict of interest that often arises with an open core business model. In the meantime, our options are:

• Re-downgrading to pages router
• Using query params for everything
• Some fallback re-write hack and custom url parsing

[leerob]

It doesn't seem like its in Vercel's best interest to offer great support for SSG with Next.js, because then devs can just host on S3 or whatever CDN, instead of being locked into Vercel or other serverless / edge providers.

This is not accurate, as this is a feature of the Pages Router we have supported for many years and plan to continue to support.

As mentioned in my comment above, the Pages Router is not a downgrade. While we're of course excited about some of the benefits Server Components can bring, the Pages Router is still the most popular way of using Next.js today (most applications are on the Pages Router) and we are continuing to invest here.

I would not recommend "some fallback re-write hack" and instead recommend using the Pages Router until we land support here for the App Router. Thank you.

[zdenham]

I see, I appreciate the response (and the work maintaining the project). I was under the impression pages router was on the way out because create next cli defaults to app router for new projects. For forward compatibility we've been defaulting to app router for our projects to save the future trouble of porting back and forth. FWIW, I understand that upgrading next.js router while maintaining full feature parity is a difficult task, so appreciate the support in the meantime with the pages router.

We were hosting our site non-statically with Vercel using app router, but an enterprise client requires hosting on AWS / prefers static hosting. We make use of nested layouts etc... which is a bit of a chore to port to pages (moving layout.tsx to wrapper components etc...). Others may be in a similar situation where they invested in app router and want to move to SSG, which is why this is a popular feature ask!

[zdenham]

Also @leerob, after testing it out, pages router behavior is not ideal for dynamic client side routes w/ static export out of the box. With this issue's example repo, when you navigate to blog-pages/one via the UI, it works due to client side routing, but then when you refresh the page you get a 404 error.

This makes sense because there is no html file at the location, but I suppose the ideal behavior would be the 404 page somehow resolving the proper page even on a direct visit, more like SPA behavior. This might have to come from server configuration, we are likely going to use an edge function to manually re-write routes to the proper destination.

[friedjoff]

@zdenham have a look at next-nginx-routes, that's our approach for server side routing.

[zdenham]

Looks good! We were looking to do effectively the same thing with a generated cloudfront function. I'm not sure how this behavior could be built directly into next.js "out of the box" with widespread support for static hosting providers like GH pages, S3 etc... without some 404.html client side hackery. This looks like a great solve at the server layer.

[ronny1020]

Could an explanation be provided regarding the differences between using output: export with the app router and the page router? It appears that the main features of the app router, such as RSCs and server actions, are not supported in SSG mode. Are there any new features supported in the app router that are not available in the page router or any improvement? If they are essentially the same, should the page router with output: export be recommended in the documentation, since the page router provides more features?

[zdenham]

I did not want to move back to pages router, so I ended up building a workaround where we generate fallback static pages then redirect to the fallback for dynamic routes via a cloudfront edge function. Ended up turning the solve into a small utility lib which you can check out here:

https://github.com/zdenham/next-static-utils

[fcole90]

Hej, coming from #54393, I have the same issue after following the guide https://nextjs.org/docs/pages/building-your-application/upgrading/from-create-react-app#step-7-create-the-entrypoint-page to convert a CRA app into a Next one.

I get many errors like Error: Page "/[[...slug]]/page" is missing param "/[object%20Object]" in "generateStaticParams()", which is required with "output: export" config., but all routing is actually working (not using Next routing directly, still using the lib we had for CRA). So, perhaps this is an issue only as long as you want to use Next's own routing, but if you have a SPA with already its own routing library, then this warning is not a problem. Or is it? 🤔

[GabenGar]

You have to use Next routing anyway because its multipage logic relies on it. Maybe it works now because you are effectively building a single page bundle, but it will stop doing so after you actually have multiple pages.

[ronny1020]

This way, you will get a SPA instead of an SSG app. I'm not saying an SSG app is better but there are differences. Besides, I think most people who ran into this issue were already using the app router. There is no reason to use both the app router and the react-router. If we have to migrate to another router, the page router would be the better choice.

[fcole90]

Yes, it's an SPA, and at the moment there's no plan to change that 😊 My understanding is that, as following the guide, one has a catch-all [[...slug]] "static" param, that being a catch-all, amounts to have a static / page, where everything else is loaded dynamically, that is exactly what an SPA is, right? 😊 And pages are just dynamic, as they were in CRA, so, my thinking is that, as long as one is fine with this setup (SPA with a single catch-all entry point) and understands its implications, it actually does it's job pretty well 😊 👍

The questions I can see are the following:

• do we need better docs to explain this SPA scenario besides the CRA guide (and perhaps improve that too)?
• can we add an option for the error to be silenced in some way? E.g. having an option isSPA: true, that can be checked here

  next.js/packages/next/src/server/base-server.ts

  Line 1953 in d888461

  if (this.nextConfig.output === 'export') {

  not to show the error
• another option to get rid of the error, could be to set a static fallback for our dynamic pages

  next.js/packages/next/src/server/base-server.ts

  Line 1956 in d888461

  if (fallbackMode !== 'static') {

  , but I'm not sure how to achieve that

[ronny1020]

This issue is about using useParams with the app router and output:export instead of the next js can't use static param. Using the SPA in the next js is your choice. However, if you would like to suggest adding SPA related feature. I think you should open another issue.

[fcole90]

This issue is about using useParams with the app router instead of the next js can't use static param. Using the SPA in the next js is your choice. However, if you would like to suggest adding SPA related feature. I think you should open another issue.

My bad, I will look into that then 🚀

[freddieerg]

As people have said, with the release of v15 now with this still not being addressed, it's pretty clear this isn't going to be resolved.

[isaachinman]

Vercel is a for-profit hosting company, and has no incentive to make this work more easily. There are plenty of competing options to switch to these days.

[iameli-streams]

The year is 2067. All world governments have fallen. Vercel-branded killer drones patrol the skies, searching for members of the static rendering resistance. At last, the final safehouse is located.

As the rebels are dragged into the prison transport by shock troops, one cries out "It wasn't supposed to be like this! You promised we'd be able to do static rendering with the App Router!"

The eyes on the commander's helmet light up as he replies: "Yes, we plan to support this for the App Router as well in the future. We don't have a defined timeline yet, so Pages Router might be a better choice for you right now." And he slams the door.

[hichemfantar]

The crazy thing is that the creator of this discussion is a vercel employee which makes it even weirder

[styfle]

Its not that crazy. I created it to track the missing feature.

I believe @feedthejim and @sebmarkbage are going to revisit this feature now that Next.js 15 shipped.

[hichemfantar]

@styfle crazy is the wrong word i guess because what i meant is i thought the issue would get resolved quickly since a vercel team member expressed interest in it but that's great to hear! fingers crossed for next 15.x or 16 to finally put this matter to bed.

[raulvictorrosa]

I guess this one here is really similar or equal. #55393

[da20shadow]

@styfle We’ve been waiting a long time for this. Please consider prioritizing it. Thank you for all your efforts!

[chrox]

Workaround:

This is what I did to workaround this in Readest project, an open-source cross-platform ebook reader.

Readest has a Web version and a Tauri version(which requires an export build), both of which are SPA in Next.js. I need to pass book id to the reader page in order to load the specific book data. It's fine to pass the id in query parameters in Tauri app since the users won't see it. But it's unacceptable on the Web version. Because the full url is shown in the address bar. I need the page url to be like:

https://web.readest.com/reader/{id}

I conditionally set the output: export in next.config.mjs only for the Tauri build:

output: process.env['NEXT_PUBLIC_APP_PLATFORM'] === 'web' ? undefined : 'export',

And add two pages:

1. one for the web variant：https://github.com/chrox/readest/blob/main/apps/readest-app/src/app/reader/%5Bids%5D/page.tsx
2. and the other for the Tauri variant：https://github.com/chrox/readest/blob/main/apps/readest-app/src/app/reader/page.tsx

And at runtime route to the page for that platform accordingly with a nav util: https://github.com/chrox/readest/blob/main/apps/readest-app/src/utils/nav.ts

The full change is in this commit: readest/readest@242fbf6

Updated (2024-12-25):

And the App Router and the Pages Router can coexist in one project. I just moved the dynamic route page and the API route into the pages directory and now they work fine with output: export. The update change is in this commit: readest/readest@17336d7