Next.js Discord

Discord Forum

Not Found Convention for Route Segments

Answered
Africanized honey bee posted this in #help-forum
Open in Discord
Africanized honey beeOP
Reading the docs, it says: The not-found file is used to render UI when the notFound function is thrown within a route segment. But beneath that is says in a note the root app/not-found.js file also handles any unmatched URLs for your whole application. In the docs code example it refers to the filename as app/blog/not-found.tsx.

Does this mean that an unmatched url that's inside of a route segment will not get the appropriate not-found component, since it wasn't explicitly triggered by calling notFound()? Or should it be getting this and there is a bug or maybe I just have an issue on my end? If this isn't supported, it seems a little confusing why this behavior wouldn't be included.

Context from my use case, I have this file structure:
app/page.tsx
app/not-found.tsx
app/[id]/...various pages related to this product...
app/[id]/layout.tsx
app/[id]/not-found.tsx

If the user somehow navigates to a non-existent page for the given id, I still want the segment's layout to be rendered since it includes information about the product in question - and the not-found just has a basic ui that this page doesn't exist for this product.

Right now, this setup always sends me to exclusively to the generic root not-found ui. Appreciate any response!
Answered by joulev
Ah you meant this. In that case use
app/[id]/[...anyName]/page.tsx
View full answer

7 Replies

@Africanized honey bee Reading the docs, it says: `The not-found file is used to render UI when the notFound function is thrown within a route segment.` But beneath that is says in a note `the root app/not-found.js file also handles any unmatched URLs for your whole application`. In the docs code example it refers to the filename as `app/blog/not-found.tsx`. Does this mean that an unmatched url that's inside of a route segment will not get the appropriate not-found component, since it wasn't explicitly triggered by calling `notFound()`? Or should it be getting this and there is a bug or maybe I just have an issue on my end? If this isn't supported, it seems a little confusing why this behavior wouldn't be included. Context from my use case, I have this file structure: `app/page.tsx` `app/not-found.tsx` `app/[id]/...various pages related to this product...` `app/[id]/layout.tsx` `app/[id]/not-found.tsx` If the user somehow navigates to a non-existent page for the given id, I still want the segment's layout to be rendered since it includes information about the product in question - and the not-found just has a basic ui that this page doesn't exist for this product. Right now, this setup always sends me to exclusively to the generic root not-found ui. Appreciate any response!
joulev
If the user somehow navigates to a non-existent page for the given id, I still want the segment's layout to be rendered since it includes information about the product in question - and the not-found just has a basic ui that this page doesn't exist for this product.
you need to use notFound i think
use notFound inside the app/[id]/page.tsx
@joulev > If the user somehow navigates to a non-existent page for the given id, I still want the segment's layout to be rendered since it includes information about the product in question - and the not-found just has a basic ui that this page doesn't exist for this product. you need to use `notFound` i think
Africanized honey beeOP
Gothca, well while I understand it I think that's a little counter intuitive --

If there exists pages:
app/[id]/page-a/page.tsx
app/[id]/page-b/page.tsx
app/[id]/page-c/page.tsx

and the user tries to navigate to
app/[id]/page-z/page.tsx

I feel like that should definitely make its way to the app/[id]/not-found instead of the global app/not-found.

In the meantime though - your approach would work fine, I probably would do it from the layout instead of a page, but same thing. It just feels a little hackish / like a workaround for a behavior that ought to be expected.
Answer
joulev
[...anyName] or [[...anyName]] depends on your use case
Look up catch-all dynamic segments for more information
@joulev [...anyName] or [[...anyName]] depends on your use case
Africanized honey beeOP
Oh wait a minute thats a great idea - didn't even occur to me, thanks!