Yes. I have an user case that makes sense have two or more dinamic routes in the same folder.
When we use dynamic routes we cant use different slug names for the same dynamic path as it throws the error 'You cannot use different slug names for the same dynamic path.'.
Example:
This works:

This dont (throws the error on yarn dev):

The point is that the valuezone is our bussiness name to a group of neighborhoods and we have some neighborhoods under our valuezone and some out of it. So, we have 2 types of url.
1) The neighborhood is under a mapped valuezone
/comprar/[realtyType]/[state]/[city]/[valuezone]/[neighborhood]
2) The neighborhood wont have a mapped valuezone
/comprar/[realtyType]/[state]/[city]/[neighborhood]
To archieve the behavior I need to add both [valuezone] and [neighborhood] under [city], but this throws the error I describe above.
It would be awesome if we could use thing like the second image, as we redirect especifying the path and the variables we want, that dont leaves doubts of what path we want to render.
In my especific case if I just change the order of [neighborhood] and [valuezone] the problem is solved, but this only works because I have only one conditional path, in other user cases I cant see an solution with friendly URL.
The issue in the second example is that you have 2 dynamic routes in the same level, [valuezone] and [neighborhood] can't be in the same level, because a dynamic route will always handle all routes that aren't handled by a static page, so if you have 2, it creates a conflict.
If what you want is to handle the following paths:
/comprar/[realtyType]/[state]/[city]/[valuezone]/[neighborhood]/comprar/[realtyType]/[state]/[city]/[neighborhood]You only need to have [valuezone] and remove [neighborhood], then to handle the paths:
/comprar/[realtyType]/[state]/[city]/[valuezone]/[neighborhood] - Handled by [valuezone]/[neighborhood]/index.js/comprar/[realtyType]/[state]/[city]/[valuezone] - In this case instead of having [neighborhood] we have [valuezone], so you can consider [valuezone]/index.js to be the [neighborhood] page.I'm closing the issue for now, feel free to continue the conversation.
@lfades And how would you go about this structure. Because I have the feeling I need different routes at the same level. Or I'm missing the point of some specs in Next.js
/[lang]/[overview] --> Which will give me an overview of the products with different routes in different languages. Would result in the following 3 routes (or even multiple in the future as we expand).
/nl/leasing-auto
/fr/leasing-voiture
/en/leasing-car
/[lang]/[about] --> will give me different slugs of the about page. I tried multiple things, but these are easy to happen in bigger application, no?
/nl/over-ons
/fr/a-propos-de-nous
/en/about-us
How would you deal with this situation?
I feel pretty limited by the api at the moment if there is no way to handle this. Also nice to note, it is about a static generated site. So don't know if that would change the way you would handle it.
@lfades
how about
/creditcard/[token] POST
/creditcard/[cardId] DELETE
using same level but different method?
@carylaw You can use a single API route and check for the method with a conditional:
export default (req, res) => {
if (req.method === 'POST') {
// Process a POST request
} else {
// Handle any other HTTP method
}
}
@BramDecuypere I currently don't have an answer for your use case, but the team knows about it and we'll be investing into i18n soon :+1:
@lfades is there any progress on that?
Also I got the error from the title even when my structure looks like this:
[productPage].js
[category]
[categoryName].js
It's not very convenient. I know it's the same case as from the author.
I would understand that, if [productPage] would match something like /xxx/yyy, but it's not. This url matches only [category]/[categoryName].js file.
This is a pretty rough limitation.
We're trying to use a restful style page structure as shown below, but this fails.
โโโ projects
โโโ [id]
โย ย โโโ edit.tsx
โโโ [id].tsx
โโโ [projectId]
โย ย โโโ tasks
โย ย โโโ [id]
โย ย โย ย โโโ edit.tsx
โย ย โโโ [id].tsx
โย ย โโโ index.tsx
โย ย โโโ new.tsx
โโโ index.tsx
โโโ new.tsx
Supporting this definitely requires more complexity inside the Next router and a compile step check to ensure duplicate pages don't exist (ex. projects/[id]/edit and projects/[projectId]/edit). But I do think it's worth the effort.
@BramDecuypere I currently don't have an answer for your use case, but the team knows about it and we'll be investing into i18n soon +1
Any news on this? Running into the same issue where route strings need to be localized.
@BramDecuypere I currently don't have an answer for your use case, but the team knows about it and we'll be investing into i18n soon +1
Any news on this? Running into the same issue where route strings need to be localized.
We currently decided not to localize our URL's although not perfect, it's not worth for us spending more time on these issues. What we do now though (for blogs at least), is have them come from our CMS and store the alternate links of the blogs inside the page as well. So we know there is always a link we can refer too.
Maybe that might help, we could also do that for the other pages, now that I think of it, but like I said, not worth my time right now. I believe Next is working on a build in solution, so I would hate to spend time working around the issue and then have them release a standardized feature out of the box...
Best of luck anyways!
Another question.
Imagine you're building a blog. You have blog that displays all the blog posts, and that would be domain.com/blog.
Now, each post has a category, so you could click domain.com/blog/business and it would fetch the posts only with business.
They both use the same template, and the single post view, would be always domain.com/blog/category/slug no matter where it is, whether on blog or blog/category. They both, use same template.
How would you go about that?
Most helpful comment
This is a pretty rough limitation.
We're trying to use a restful style page structure as shown below, but this fails.
Supporting this definitely requires more complexity inside the Next router and a compile step check to ensure duplicate pages don't exist (ex.
projects/[id]/editandprojects/[projectId]/edit). But I do think it's worth the effort.