Support dynamic routes (with dynamic params) in static export mode #55393
Replies: 27 comments 65 replies
-
|
Our project is private (don't care about SEO) and already has a back-end server, so there's no point in having server-side rendering and in turn, no need to use a node server. But we handle a lot of dynamic data so I'm highly interested in this |
Beta Was this translation helpful? Give feedback.
-
|
Exactly! If you've got a backend setup and aren't fussed about SEO, then the whole SSR shebang might not be for you. What you're highlighting is exactly why this feature is so key in many applications. Dynamic data shouldn't be a hassle, even in static deployments. Hope this gets the consideration it deserves. Really holding next back as “the react framework”. |
Beta Was this translation helpful? Give feedback.
-
|
@VakarisZ I don't know if you still need this, or if you solved this a different way, we had a golang server serving the static files, and I was able to do a workaround, see this |
Beta Was this translation helpful? Give feedback.
-
|
See issue 54393 |
Beta Was this translation helpful? Give feedback.
-
|
They changed the issue into a discussion #64660 🫤. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is already planned because App Router is supposed to have the same capabilities as the Pages Router (or at least propose alternate patterns), just not the biggest priority |
Beta Was this translation helpful? Give feedback.
-
|
I wish I knew this before going in on app routers, guess I have a big re-refactor ahead of me |
Beta Was this translation helpful? Give feedback.
-
|
A planned feature but in the app router docs it describes this as being possible now? https://nextjs.org/docs/app/building-your-application/deploying/static-exports Definitely frustrating especially when you've used this in pages in the past and tried app router expecting similar functionality. |
Beta Was this translation helpful? Give feedback.
-
|
It states:
So no, it's not supported yet and the docs say it's not supported either. |
Beta Was this translation helpful? Give feedback.
-
|
THis one is very important to me as I use nextjs with Capacitor to generate iOS and Android apps. In those cases I export dynamic route pages that need to do remote requests (such as /user/[id]). My current work arounds would be to either use query params (/user?id=blah) or go back to the pages routing. edit: actually query params won't work as the builder still wants to turn it into a static html, so I can only go back to pages I guess... |
Beta Was this translation helpful? Give feedback.
-
|
if dynamic page has child route, query params make sad |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for addressing this problem. I see another significant issue in that – memory overload. There should be the possibility to handle dynamic routes with client-side fetching. Without that option, on large platforms, users would have to download 'gigabytes', with the number growing every day, instead of megabytes from the App Store. Additionally, each new entry force users to update the app to prevent encountering 404 errors. |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone! Cross-posting myself from #54393 (comment) so I can get notified about any kind of development in this regard:
Any news of any kind about this? |
Beta Was this translation helpful? Give feedback.
-
|
hi everyone, guys i am looking for solution for two days , i started thinking to change framework , i have tried everything `"use client"; function Lang({ params }: { params: any} ) { const {sleep, handleSubmitAttribute,object, objectxsById, deleteAttribute, setCurrentLang, attributexs, setAttributes, attributes, user } = useAuth({ middleware: "Guest" }); } // Callback function to receive data from the child }; const onSubmit = async (e: any) => { ); } else { } } const saveX=()=>{ return ( ); export default Lang; that is the error `
|
Beta Was this translation helpful? Give feedback.
-
|
Any update on this? |
Beta Was this translation helpful? Give feedback.
-
|
no |
Beta Was this translation helpful? Give feedback.
-
|
🤚 I also am in the boat of needing this -- I need to do I don't work at Vercel, but sadly, I don't see any way this is technically feasible. The output of static builds are individual files. Without knowing the value of individual paths in the data beforehand, Next won't know what paths to create. You could create a system in the framework that generates a You'd have to plug into AWS Route 53 and Cloudfront and wherever else is modifying that request, and have them all account for this logic, and then do that on every hosting provider separately. 😞 I just don't see a way for this to happen. The alternative is to compromise, and turn your dynamic links into URL parameters (which is what I'll have to do). Then, when I export my content, the client side javascript will still be able to pick those values up and use them the way I need. It stinks, but I really don't see any other way. |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
Almost every other routing implementation around supports hash routing, which is typically how you get around this constraint. |
Beta Was this translation helpful? Give feedback.
-
|
This is exactly what I need. In my situation, I'll never use node as backend for anything outside of generating a particular subset(the next app) of a much larger codebase. Our backend is designed for high performance and is entirely written in Rust and entirely consumed via API, mostly via our primary Angular Client, but we have some e-commerce elements we choose to use React/Next for. I'd like to be able to build static pages of existing known content at some specific interval in our deployment process and have our application still seamlessly handle scenarios where those static pages do not exist, etc. There will potentially be tens thousands of those pre-rendered static pages, and hundreds of new additions every day. Deployment directly to CDN is part of our strategy for things like this. Ultimately it seems impossible to use next(app router) to achieve these results, but perhaps our intended use case doesn't fit into vercel's business case. |
Beta Was this translation helpful? Give feedback.
-
|
would it be supported at least? |
Beta Was this translation helpful? Give feedback.
-
|
You need to use 'pages' to have dynamic routes while using static gen + app router. Sort of silly this error cant be overidden |
Beta Was this translation helpful? Give feedback.
-
|
This is a crucial feature. I don't understand why it hasn't been built yet. Especially since it seems pretty straight forward to build. |
Beta Was this translation helpful? Give feedback.
-
|
Wise words, I still have a bad feeling that it is somehow intentional |
Beta Was this translation helpful? Give feedback.
-
|
Yup I have the same feeling... |
Beta Was this translation helpful? Give feedback.
-
|
have some update on this? |
Beta Was this translation helpful? Give feedback.
-
You need to use 'pages' to have dynamic routes while using static gen + app router. |
Beta Was this translation helpful? Give feedback.
-
|
It is quite embarrassing that such a widely adopted framework doesn't support for dynamic routes on client side. For now we are working with parameters in the query string, which is very far from ideal. |
Beta Was this translation helpful? Give feedback.
-
|
There is Open NextJS. Maybe we can borrow from React Router V7 (RSC) or TanStack Router to implement sample template/boilerplate, if get popular it might get as close as Standard. One thing I feel in React Industry is the standard either is shooting themselves in their leg (Next.js) else is always still "new but not fully feature" |
Beta Was this translation helpful? Give feedback.
-
|
This is clearly enshittification. I'm not sure if it's intentional or just selected-for (e.g. deprioritization of this bug in backlog grooming,) but either way, the result is the same. → Vercel is experiencing a conflict-of-interest. On one hand, it maintains an open source package that is now the de facto way of producing React apps; → On the other, it profits from a hosting business; → For some reason, there is a mysterious and undocumented limitation when using NextJS in the only way that does not require hosting. Vercel, please don't be this way! I fought and advocated for your solutions, and now my own credibility is damaged, as we scramble to move from an S3-backed scenario to one that can do dynamic parameters (a feature which, by the way, has been supported in react-router since the Obama administration). There's still time to fix this, though, and this very-downthread comment on a GH discussion is your warning; I'm old enough to have seen firsthand how reputational consequences can salt the earth for a startup. I'm sorry this warning isn't larger, because I agree that the, ah, 'Business Experience' (BX?) of receiving an important warning in this way is not great. Yet I am powerless to do more. You're not powerless, though! |
Beta Was this translation helpful? Give feedback.
-
|
I switched to the Pages router. But this is dumb, and almost certainly an intentional business decision. It's unsurprising, however. Fortunately, most of our work in Next/React is decoupled in a manner that was very easy to move to Pages Router, but is less ergonomic than App Router. And, for the last 5 years, 100% of the backend work I do is in Rust and 95% on the frontend is in Angular, so we don't have a lot of dependencies on Next. I don't think I would consider Next again for a future project, howeve,r given this and other issues I've run into building out this particular tool. React is great though. |
Beta Was this translation helpful? Give feedback.
-
|
@chriskyndrid curious to hear how you got dynamic routes working with pages router? We tried setting fallback: true with |
Beta Was this translation helpful? Give feedback.
-
|
@zdenham I believe, if memory serves, that fallback: true has an internal requirement related to SSR which is incompatible with SSG (output: export). Although the only thing we use "SSR" for is the generation of the SSG pages, you need to be deployed on a node server for fallback to work. As I mentioned in my other post, the solution I rolled can't do anything about endpoints that don't exist at the time of SSG. This is because you need a server to deal with essentially what would otherwise be a 401 (hence fallback: true), to generate a server fetched "static" variant of the page. In my case that's not an option because 1: I don't plan or desire to use node for anything in production. 2: we deploy to a CDN and obviously have limited control over a 401 scenario. I've thought about potentially creating a custom 401 page that would, provided suitable information in the URL exists, manually deal with those scenarios(but I would be unable to instruct the CDN server to return something other than 401, but could perform a client side redirect to a param based page). In any case, all of the "fallback" code I implemented to allow our app to work was done manually. I constructed the components to accept static arguments from build time for the initial page loads and to (useEffect()) issue a call manually to freshen the data. This addresses the SEO situation(with an inherent lag), initial load times, but still ensures we maintain current information. I then have some tricks in place to deal with the legitimate removals of statically generated pages that have since been removed, along with determining client-side if we can route to a dynamic(static) route, or if we need to route to the component with a query param(e.g. issuing a HEAD request via axios after intercepting the navigation request). I couldn't think of another way to accomplish this when CDN was the target and the data was changing frequently. |
Beta Was this translation helpful? Give feedback.
-
|
I see, cache invalidations when data is removed sounds tricky as well. The way we are looking to address it is with a custom cloudfront edge function to properly re-route to the static file when they don't exist. |
Beta Was this translation helpful? Give feedback.
-
|
In my case I'm not super worried about that. As in those scenarios there will be a static page already backing the missing resource. In our scenario, the user will be greeted with a nice "This resource is no longer available", with some options on how to proceed. Once the regen happens it'll result in a 404, which is roughly every 24 hours. I should also mentioned I've written some logic to purge dropped resources as part of the deployment process... |
Beta Was this translation helpful? Give feedback.
-
|
I'd love for a solution to this. judging by how recent the comments are there has been no progress... |
Beta Was this translation helpful? Give feedback.
-
|
Why cant you just use the pages router along side app? |
Beta Was this translation helpful? Give feedback.
-
Why would someone want to use something outdated that is getting deprecated soon? |
Beta Was this translation helpful? Give feedback.
-
A solution is better than none. Are you really missing out on that much? Maybe im ignorant but its just a router at the end of the day... |
Beta Was this translation helpful? Give feedback.
-
|
That's not a solution, that's only a workaround. A real solution is needed. |
Beta Was this translation helpful? Give feedback.
-
|
We have a separate API, and need to support static builds to meet code guidelines of our clients. Currently exploring custom re-routes at an edge function level to achieve the desired behavior. |
Beta Was this translation helpful? Give feedback.
-
|
Better yet, I'd like to be able to statically generate some pages, but offer a fallback with client side querying. |
Beta Was this translation helpful? Give feedback.
-
|
Part of our requirement is deployment to CDN for the Next stuff we use. Ultimately I opted to facilitate frequent static generation against our API, and handled linking where a static link doesn't exist by supporting a query argument in addition to a dynamic route. After the page is mounted on the client-side and the client refreshes that data against the API, if a static route doesn't exist the client will route via query param to the entity the user is attempting to access(e.g. things that are new with no static content). This won't obviously solve instances where an endpoint simply doesn't exist, but the application is aware and so all resources that are shared, etc, land with the query param until the next generation run. Of course, I had to go back to pages router to accomplish this. |
Beta Was this translation helpful? Give feedback.
-
|
Seems like a good approach, but I did **just port us over to app router before deciding to go static 😆. Maximum pain |
Beta Was this translation helpful? Give feedback.
-
|
I've run into this problem on a few projects, so built a workaround library to help deploy static sites to S3 / Cloudfront with dynamic param + app router support. Can check it out here: next-static-utils |
Beta Was this translation helpful? Give feedback.
-
that is great, one thing why i want the static deploy is to use it as a web app with Capacitor.JS and do the fetch from the server which is the same NEXTJS app just with a ENV VARIABLE to check if we're on server or not. Thank you for your approach, i will definitely try it out and hope it works. else i will just have to go to another framework sadly |
Beta Was this translation helpful? Give feedback.
-
|
Already tryed it out. i get errors. i posted on your repository's issues |
Beta Was this translation helpful? Give feedback.
-
|
Just came across this problem. Makes me wonder why I choose Nextjs when this is a crucial feature. Need to refactor everything from app router to pages... |
Beta Was this translation helpful? Give feedback.
-
I just heard remix is dead because of React Router 7 |
Beta Was this translation helpful? Give feedback.
-
|
For everyone interested in the actual announcement instead of "I just heard": https://remix.run/blog/merging-remix-and-react-router Added context: The announcement explains in depth what's going to happen - Remix is merging / rebranding into React Router 7 for now and saying it's dead is inaccurate, it will be here, just under a different name. And that still makes it a viable alternative, which appeared as a side topic here. |
Beta Was this translation helpful? Give feedback.
-
If you are going to comment to help, do it by commenting about the subject, we dont need a link to the News, I already saw a resume at the react conf 2024, I wanted to know what's @alexanderhorner ´s static approach with remix and if it was worth the change. |
Beta Was this translation helpful? Give feedback.
-
|
I use React Router for a large project at work and Remix for a smaller personal project. Remix has a SPA mode, which you can enable with one line in the config. It’s similar to using React Router directly but includes Remix features like file-based routing and automatic code splitting. There’s also a static site generation package, but I haven’t tried it yet. My experience with Remix has been much smoother than with Next.js. While you can do more with Next.js, and it’s great that they’re pushing the boundaries, it comes with a lot of additional complexity and weird restrictions (many of which are due to their integration with Vercel). With RSC coming to React Router v7 (aka Remix v3), I would need a very good reason to deal with the additional weirdness Next.js brings. |
Beta Was this translation helpful? Give feedback.
-
|
Very good inspiration, and it seems that if we want to move from remix to React Router 7, wont require a lot of work |
Beta Was this translation helpful? Give feedback.
-
|
To summarize the above posts, here's a workaround that works until it's fixed in Next.js (if it's ever fixed someday....). From @chriskyndrid comment a working workaround is to use the pages router for dynamic routes when using Here's my file structure that works // /app/main-layout.tsx
import './globals.css';
import Header from '@/app/_components/header';
export function MainLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
return (
<>
<div className='fixed w-full'>
<Header />
</div>
<div className='w-full h-full pt-10'>
{children}
</div>
</>
);
}// /app/layout.tsx
import type { Metadata } from 'next';
import './globals.css';
import { MainLayout } from './main-layout';
export const metadata: Metadata = {
title: 'My App',
description: 'My App Description',
};
export default function RootLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
return (
<html lang="en">
<body className={'h-screen w-screen'}>
<MainLayout>
{children}
</MainLayout>
</body>
</html>
);
}// /app.page.tsx
export default function Home() {
const id = 'abcd'
return (
<main className="h-full flex flex-col">
<p>This is my app</p>
<Link href={`/my-dynamic-route/${id}`}>To to abcd</Link>
</main>
);
}// /pages/my-dynamic-route/[id].tsx
import { useRouter } from 'next/router';
import { MainLayout } from '@/app/main-layout';
export default function Page() {
const router = useRouter();
return (
<MainLayout>
<div>
My dynamic route page {JSON.stringify(router.query)}
</div>
</MainLayout>
);
}It's not perfect, but it work without the need to flipping everything back to page router ✌️. |
Beta Was this translation helpful? Give feedback.
-
The original comment I'm replying to says that their workaround works, which is the one I'm trying. Am I missing something? |
Beta Was this translation helpful? Give feedback.
-
This is not true. You can accept a param by creating a index.tsx file in the same directory and handling the param manually. This will not provide a server side solution, but it does work client side: index.tsx function ChannelPage({defaultChannel, staticChannelData}: ChannelPageProps) {
const router = useRouter();
const {id} = router.query;
if (!defaultChannel) {
return <div>Default channel not found</div>;
}
return (
<PortalLayout>
<Channel
channelId={id as string}
startPos={0}
sortKey="someSortKey"
sortOrder="ASC"
staticChannelData={staticChannelData}
/>
</PortalLayout>
);
}[id].tsx function ChannelPage({id, channel, staticChannelData}: ChannelPageProps) {
return (
<PortalLayout>
<Channel
channelId={id}
startPos={0}
sortKey="someSortKey"
sortOrder="ASC"
staticChannelData={staticChannelData}
/>
</PortalLayout>
);
}If you are happy with a client side solution, this will work. You'll end up with static pages being generated at /path/Xyz/ and a param based solution at /path?id=value Chris |
Beta Was this translation helpful? Give feedback.
-
|
@nightknighto I'm using pages router with I'm thinking of using query parameters ( (I'm also using |
Beta Was this translation helpful? Give feedback.
-
This is because the E.g. if hosting on netlify - you could add this to netlify.toml: I've written a little helper tool which generates those rewrites: https://www.npmjs.com/package/next-redirect-generator, it may or may not be useful for you. |
Beta Was this translation helpful? Give feedback.
-
Awesome idea! I'll look into it. |
Beta Was this translation helpful? Give feedback.
-
|
I have written a proposal to support this feature internally. I hope to share more updates in the coming months 🙏. To share a bit more, the missing part right now is that we need to introduce a concept of "serverless" navigation, i.e., we need to be able to detect that the page you're navigating to might not need a server roundtrip. That'd be useful when you're just using query params as client-side filters, for example. Once we have this, there's just a little bit of plumbing we need to do at compilation time for the static exports mode to then automatically make dynamic params routes always serverless and then we'd be good to go. |
Beta Was this translation helpful? Give feedback.
-
|
It's going to be added to the 15 version, right? Please hurry up I need to grind everything I've been working on with electron... |
Beta Was this translation helpful? Give feedback.
-
Who told you this will be added on version 15? |
Beta Was this translation helpful? Give feedback.
-
|
@feedthejim I'd love to see this work even if you are not exporting a static build. I'd still like to keep using Next.js route handlers on the server side, but on the client side, use a CSR routing and data fetching strategy for certain pages, so they behave like a SPA. It would be great if this was possible to declare "force static" on a page with dynamic params, and have that use this "serverless navigation" mode as described. |
Beta Was this translation helpful? Give feedback.
-
|
any news or this? |
Beta Was this translation helpful? Give feedback.
-
|
No news for now, NextJS 15 release and this wasn't fixed yet. 🫤 |
Beta Was this translation helpful? Give feedback.
-
|
You should put your perspective on vercel's point of view don't just see it from yours. For them static site features doesn't bring much money for than server/backend features. People who use nextjs for static sites mostly just cheapskate with very low or no budget. Vercel spent a lot of money for nextjs. Of course they want to make it more hard for people to use nextjs outside vercel. it doesnt mean they will abandoned this feature, its just not their focus. |
Beta Was this translation helpful? Give feedback.
-
That's they're problem though. There are alternatives so people will just switch to remix or similar. Chat GPT did exactly that yesterday. |
Beta Was this translation helpful? Give feedback.
-
|
Yes maybe they also got frustrated migrating from page router to app router |
Beta Was this translation helpful? Give feedback.
-
Yeah, even if it's not profitable, some of the people will want that feature and move to another framework eventually, like remix. I am waiting for React Router 7 to start working with, and for now Svelte solve all my problems so thats why they are losing devs that might eventually use nextjs for SSR |
Beta Was this translation helpful? Give feedback.
-
I'm really wondering what this is all about. ChatGPT, for example, has now switched from NextJS to Remix |
Beta Was this translation helpful? Give feedback.
-
|
NextJS 15 release and this wasn't fixed yet. 🫤 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
Beta Was this translation helpful? Give feedback.
-
|
Hash does not "fix" this. |
Beta Was this translation helpful? Give feedback.
-
|
Hash router is literally an old hack which was used pre-history API. You clearly didn't have enough problems parsing URLs if relying on the part, which doesn't get parsed by the browser at all, for routing is a-okay. |
Beta Was this translation helpful? Give feedback.
-
|
Full URL routing, not based on hash is totally possible with static file as long as you have properly the initial file for initial application loading (for example by redirecting 404 to index.html in your static web server). |
Beta Was this translation helpful? Give feedback.
-
|
You are describing a bog standard SPA setup, down to legacy semantics-breaking hacks, which has nothing to do with the subject of the thread that is |
Beta Was this translation helpful? Give feedback.
-
|
Okay, so I have been able to achieve this functionality where we had a Golang backend server serving the static files, the app was generated using SSG, so only routes that existed during build time worked and other threw 404 from the go server. The neat trick that I did was define a basic not-found.js page at the root level ( You can render a custom 404 page if the route actually doesn't exist, after reading the response The only doubt I have is, I don't know how it would behave for a purely static web app, without any server, someone can give this a try and see if it works. |
Beta Was this translation helpful? Give feedback.
-
|
I hope to see this feature soon released. Now is not possible to produce an SPA with dynamic path and keep the good DX of the App router |
Beta Was this translation helpful? Give feedback.
-
|
Hi, and sorry to ping your guys @acdlite, @eps1lon, the thing is that we just need an answer from the Next.js team to see if this will ever be developed, we are stuck with this. 🫤 |
Beta Was this translation helpful? Give feedback.
and others
-
Goals
Feature Request: Support Dynamic Routes with Dynamic Params in Static Export Mode
Current Behavior
Right now, when we use the
{ output: 'export' }option to statically pre-generate the app to run without a Node server, we hit a roadblock: dynamic routes like/post/[id]just can't be created. Yes, we can pre-generate specific pages such as/posts/1,/posts/2,/posts/3, and so on, but if we encounter values not known at build time, we are met with a 404 error. This is quite the hiccup for scenarios demanding static deployment coupled with dynamic data capabilities.Desired Behavior
We're looking to get dynamic routes with variable parameters up and running in static export mode. The vision is to have routes like
/post/[id]operate without a hitch, avoiding the dreaded 404 error when the ID parameter changes, and allowing individual posts to be fetched client-side. This change would significantly broaden the scope and usefulness of static exports.Non-Goals
What This Feature Request Does Not Aim to Address
Background
Benefits
Flexibility: This feature would open doors for developers to exploit dynamic routes while still enjoying the perks of static export functionalities.
Honoring the Next.js Slogan: Let's make the Next.js slogan "The React Framework" ring true by covering a common SPA use case currently left out in the cold.
Potential Drawbacks
Complexity: While this looks promising, introducing dynamic parameters in static export mode might complicate route management a bit.
Alternatives Considered
Sticking with Static Paths: This option, albeit simpler, severely limits the dynamic functionalities, which are pretty much essential in modern web applications.
Switching to a Different Router: Though this sidesteps some Next.js framework limitations, it comes at the cost of losing many of its benefits and makes the transition between a static site and an SSR application a labor-intensive task.
Additional Context
Embracing dynamic parameters in static export mode would effectively bridge the existing gap between dynamic functionalities and static deployments, offering a flexible and robust solution for developers navigating strict deployment environments.
Proposal
Proposed Solution
Client-Side Rendering (CSR) Enhancements: Let's amp up CSR to facilitate dynamic data fetching based on the dynamic parameters present in the URL — all possible through
useParams()or parameters relayed to the layout and page components. This isn't uncharted territory; it aligns well with the existing functionalities seen withuseSearchParams()in client components.Route Fallback Support: Introducing a fallback support system for dynamic routes in static export mode could be a game-changer. This means instead of getting a 404 error, users would land on a predefined fallback page, allowing for the client-side fetching of dynamic parameter data.
Beta Was this translation helpful? Give feedback.
All reactions