Support dynamic routes (with dynamic params) in static export mode #55393
Replies: 14 comments 16 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.
-
See issue 54393 |
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.
-
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.
-
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.
-
🤚 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.
-
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.
-
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.
-
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.
-
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.
-
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