Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

notFound() behaviour #938

Closed
kevinmitch14 opened this issue Mar 13, 2024 · 4 comments
Closed

notFound() behaviour #938

kevinmitch14 opened this issue Mar 13, 2024 · 4 comments
Labels
bug Something isn't working unconfirmed Needs triage.

Comments

@kevinmitch14
Copy link

kevinmitch14 commented Mar 13, 2024 •
edited
Loading

Description

  • When I navigate to a page that does not exist, the regular 404 page is shown.
  • When I manually invoke notFound(), I get the error message NotFoundError: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.
  • I've read through the repo's issues and docs and see that it's recommended to add custom not-found.tsx inside [locale].

For reference my setup looks like this:

app
├── [locale]
│   └── [tenant]
│       └── layout.tsx (<html lang={params.locale}>)

When I put not-found.tsx inside [locale], along with a layout.tsx, nothing happens.

I actually need to place the not-found.tsx inside [tenant] in order for it to trigger correctly. Is this the expected behavior? It would be great to understand what exactly is going on here!

app
├── [locale]
│   └── [tenant]
│       └── layout.tsx
│       └── not-found.tsx

It feels a bit unnatural, I just want to use Next.js default behaviour, i18n is not a product requirement for 404 pages.

To give a little more context which is also in the repo. We are using rewrites to handle a multi tenant application, each tenant lives on a subdomain. So we are doing something like below.

request.nextUrl.pathname = `/${subdomain}${path}`;
return NextResponse.rewrite(request.nextUrl);

When hooking this up with createIntlMiddleware(), it seems to also cause some issues. Logging the path from the incoming middleware request looks like this, it just keeps growing in an infinite loop of sorts. When I use localePrefix: "never", I don't get this issue however.

{ subdomain: 'dev', path: '/' }
{ subdomain: 'dev', path: '/en/dev' }
{ subdomain: 'dev', path: '/en/dev/en/dev' }
{ subdomain: 'dev', path: '/en/dev/en/dev/en/dev' }
{ subdomain: 'dev', path: '/en/dev/en/dev/en/dev/en/dev' }

Mandatory reproduction URL

https://github.com/kevinmitch14/next-intl-bug-repro-app-router.git

Reproduction description

Steps to reproduce:

  1. Open reproduction
  2. Navigate to dev.locahost:3000 to view "home" page
  3. Navigate to dev.localhost:3000/random to trigger a notFound()
  4. See blank screen
  1. In createIntlMiddleware(), remove localePrefix: "never" and observe behaviour.

Expected behaviour

No need for a custom not-found.tsx.
@kevinmitch14 kevinmitch14 added bug Something isn't working unconfirmed Needs triage. labels Mar 13, 2024
@kevinmitch14
Copy link
Author

In the Middelware - Additonal Rewrites docs, it uses the following snippet.

const [, locale, ...segments] = request.nextUrl.pathname.split('/');

However, the locale is not available on initial visit for example when visiting - http://dev.localhost:3000. The result is:

{ locale: '', segments: [] }

@kevinmitch14
Copy link
Author

Hey @amannn, any ideas on this?

@amannn amannn mentioned this issue Mar 25, 2024
Closed
6 tasks
@amannn
Copy link
Owner

amannn commented Mar 25, 2024 •
edited
Loading

Hey @kevinmitch14,

as far as I can tell, there are primarily two issues in your example app:

  1. The body tag is missing
  2. The locale prefix was inconsistently handled

I've fixed your example here: https://github.com/amannn/kevinmitch14-next-intl-bug-repro-app-router. Please see the most recent commits for reference. I initially got the example working with localePrefix: 'always' and then refactored to localePrefix: 'never'.

Note that if you add additional rewrites on top of the middleware to remove the tenant, the navigation APIs will not be applicable—so you'll have to implement those yourself. Generally, this is closely related: #653. If integrating with the next-intl middleware is a hassle here due to more custom requirements, you could consider implementing both the middleware and the navigation APIs by yourself. However, you can still use all hooks like useTranslations in components, the situation is rather that next-intl can't assist you much with routing concerns.

I'll close this issue as the fixed example seems to work as expected and because this is rather a usage question.

Hope this helps!

@amannn amannn closed this as completed Mar 25, 2024
@kevinmitch14
Copy link
Author

Hey @amannn thanks for your response, greatly appreciated. I will look into this today and report any findings!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working unconfirmed Needs triage.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@amannn @kevinmitch14