Next.js 13 appDir not-found page should have access to params / searchParams

[transitive-bullshit]

Describe the feature you'd like to request

The special not-found.js page should have access to any params, searchParams, and/or specific context from the notFound() invocation from next/navigation.

This is important in order to give users more specific info on what was not found.

Describe the solution you'd like

Either:

1. Add params and searchParams to the not-found.js file's props
2. Add an optional any prop passed from notFound() in next/navigation that the not-found.js file's default export can use to provide additional user information

Note: the same feature request will go for the special error.js file as well.

Describe alternatives you've considered

I could do this by not using not-found.js file, but I still want to return the 404 status code.

[Kinbaum]

This should have access to params. My use case is when using internationalization. Our 404 pages have language-specific content that should be rendered. The only way around this right now is by making this a client component, then dealing with loading state, and CORS.

[Kinbaum]

@timneutkens I wanted to revive this conversation as it isn't getting any attention. Is this feature something that will be supported?

[ciruz]

Please check the Roadmap and the migration guide to app directory.

It says:

Custom 404 Pages - "Work in Progress"

and

pages/404.js has been temporarily replaced with notFound() for specific route segments. We are also working on a new 404.js file to handle global errors.

So I bet, this a feature which will come with the custom 404 pages, since the current 404 solution is only a temporary thing and still not finished.

[steveluscher]

App router moved to stable in Next 13.4, so I think it's appropriate to revisit this feature request now.

[lakaniemi]

This feature would be really needed in order to display context in the not found page based on route. Here's a use case we're dealing with:

Sales page, route /item/[id], the item is already sold so we want to display 404 error page that contains links to other similar items. In order to read the id from path, I would like to do the following:

type Props = {
  params: {
    id?: string;
  }
}

const NotFoundPage = async ({params}: Props) => {
  const { id } = params;
  const itemDetails = await fetch(`apiURL/items/${id}`)
  // ...
}

That is however not possible as not-found.ts does not currently take any props. In order to work around this, we are currently doing the following:

// not-found.ts
const NotFoundPage = async () => {
  return <ItemNotFound />
}

// ItemNotFound.tsx
"use client"; 

const ItemNotFound = () => {
  const path = usePathname();
  const itemId = useMemo(
    () => path?.match(/(?<itemId>\d+)\/$/)?.groups?.itemId,
    [path]
  );
  const [item, setItem] = useState<Item>();
  useEffect(() => {
    fetch(`apiURL/items/${itemId}`)
      .then((response) => response.json())
      .then((data) => {
        setItem(data)
      });
  }, [itemId]);
}

This is unoptimal due to multiple reasons:

• It's client-side
• We have to extract the item ID from path, instead of getting it as prop
• Just look at it, much more complicated

Any indication that at least route params would be supported in the future?

[steveluscher]

Excellent, powerful use case.

[devjmetivier]

I'd also add a couple of use cases I can think of to provide context and/or make deeper customizations to the page:

• Internationalized route params
  • "The requested resource is not available in your language/region"
• Subdomain route params for Platforms
  • "The requested resource is not available in your language/region"
  • "The requested resource does not belong to this tenant"

Something I'm playing around with in development right now is getting the route params (or in your case, an id) is by using the x-invoke-path header:

import { headers } from 'next/headers';

export default async function NotFound() {
  const headersList = headers();
  const xInvokePath = headersList.get('x-invoke-path');

  // `xInvokePath` contains the ID I'm looking for to do deeper customization

  // ... do something with `xInvokePath`

  return (
    // ...
  );
}

Again, not tested in a deployment so not sure if that header is there when deployed, but it might help until they decide to address this.

[LouisJackson]

@devjmetivier the limit of this is also that you would not be able to statically render that page.

[devjmetivier]

@LouisJackson Of course. Benefits & drawbacks to all means of implementation.

[osdiab]

One workaround could be to use middleware to add headers to the request, that you can access from the server component. We did this with the active locale in my codebase, like so:

export const localeHeaderKey = "x-my-company-locale";

// ...
export function middleware(request: NextRequest) {
  // do other stuff...
  const headersWithLocale = new Headers(request.headers);
  headersWithLocale.set(localeHeaderKey, locale);
  const updatedResponse = NextResponse.next({ headers: headersWithLocale });
  // do other stuff...
  return updatedResponse;
}

Doing this, we could access the locale from the not-found page:

import { localeHeaderKey } from "~/utils/i18n/locale";

export function getLocaleFromHeaderOnServer() {
  // https://github.com/vercel/next.js/discussions/43179
  // we get this from a header so that we can get the locale from anywhere
  // serverside
  return headers().get(localeHeaderKey);
}

So calling that from not-found gives us the locale as expected.

This could be extended to include other stuff—search params could easily be pulled from nextUrl and thrown into a header, then parsed with URLSearchParams(); though I don't think route params would be straightforward as that would require parsing the pathname yourself (I don't think NextJS provides the parsed params in middleware nor does it provide any helper to figure out the route and params from a pathname either).

[jakubjo]

Returning the response in a middleware unfortunately seems to break server actions.
You can overcome this by checking if the current request is an action:

const isAction = !!request.headers.get('next-action');

[yannjor]

Not ideal, since using next/headers breaks static site generation:

headers is a Dynamic API whose returned values cannot be known ahead of time. Using it in will opt a route into dynamic rendering.

https://nextjs.org/docs/app/api-reference/functions/headers

[Dosbodoke]

Any updated on this? I have a case where I have the route /profiles/[username] and in the case where this username don't exists I want to show an not-found.tsx page with the messge Sorry, we couldn't find the user @username.

Currently I have to render a <UserNotFound username={username} /> component instead of using the notFound() function.

[Dosbodoke]

I don't think it will be a difficult task to do, and it's super important. Waiting for replies so we can start working on this.

[digitaltopo]

I have similar requirements to what other people have been stating. It would be great to be able to bring contextual messages into the not found page by deriving them from params and props.

What's great and simple about current notFound() usage is that it preserves the url while essentially displaying another route, which provides feedback for the user to understand exactly WHAT was not found.

Looking forward to seeing updates here, thanks!

[lukaswiesehan]

Also looking for updates on this. With i18n handled via middleware, as currently recommended, I have everything located in app/[lang].

But without having access to params in app/[lang]/not-found.tsx, I can't have the 404 page translated out of the box.

My current workaround is to add a client component to not-found.tsx which uses usePathname() to check for the right language to use.

[osdiab]

as mentioned here, i was able to achieve it with a language header set in middleware - not the prettiest, but it does the job! Get the proper locale from the header, and initialize your i18n strings via whatever approach your using with that locale. #43179 (comment)

[MiroslavPetrik]

I also have i18n use case for this.
For now I have switched the not-found page into a client component.

[Pedromigacz]

I found an alternative solution for the ones who don't want to use the middleware solution.
I created a catchAll page with the 404 page content, where I have access to the params on the server:

// [lang]/[...notFound]/page.tsx

export default async function NotFound({
  params: { lang },
}: {
  params: { lang: Locale };
}) {
  // do some fetching logic using your params here
    const {
      page: { not_found },
    } = await getDictionary(lang);

  return (
      <main>
          <h1>{not_found.title}</h1>
      </main>
  );
}

This example is specific for the internalization of the not-found.tsx page, but it should work for any similar issues.

Edit:
Do not use this solution as it renders 404 pages with an OK status code. As explained below by @ciruz

[JanMolcik]

Works like a charm! This was exactly my use case.

[rijk]

Cool idea. There's one downside to this approach though; it doesn't return a 404 status code.

[ciruz]

Hey @Pedromigacz,

your solution allow search engines like Google to index non existing pages within your domain. This happens because this solution accept any URL without returning a 404 error for pages that do not exist. Allowing such behavior could potentially harm the site's SEO as it might lead to indexing of numerous empty or error pages. Anybody can now hurt your sites SEO, by linking whatever they like to your page (Spam Backlinks).

[Pedromigacz]

Thanks for letting me know. I've moved to another solution where the status code is now 404. Indeed our SEO was hurt as our website was not shown anywhere on google since we did not have time to fix this earlier.

[JonasDoesThings]

Pretty underwhelming that this is not supported in stable app-router. :(

[ciruz]

If you use next-intl and need the locale value from the dynamic segment [locale] inside your not-found.js for let's say localized database queries, you can make use of useLocale() to get the locale value.

// /src/app/[locale]/not-found.tsx
import { useLocale, useTranslations } from 'next-intl'
import Link from 'next/link'

import Header from '@/components/layout/Header'
import Footer from '@/components/layout/Footer'

export default function NotFound() {

  const locale = useLocale() //en, de, ...

  const t = useTranslations('NotFound')

  return (
    <div>
      <Header locale={locale} />

      <h1 className="text-lg">{t('title')}</h1>
      <Link href="/">{t('cta-return-home')}</Link>

      <Footer locale={locale} />
    </div>
  )
}

[salavursa]

Btw, useLocale() and useTranslations() are not intended to be used in Server Components, you have to use getLocale() and getTranslations() instead (All not-found pages must be SSR at top level). For some reason "next-intl" doesn't throw an error while using their hooks in server components. It caused me some time to fix unnamed issue when I tried to add generateStaticParams() function to switch from dynamic to static rendering for my .../app/[lolcale]/page.tsx page, useTranslations()just stopped working in every SSR component

[BleddP]

This is a pretty basic functionality that should be supported from the get-go.
However, I have found a workaround by using the global property in the server component.

So in page.tsx:

import { notFound } from 'next/navigation'

const Page = async ({ params, searchParams }) => {
  const res = await renderPage({
    params: params?.slug,
    searchParams: Object.keys(searchParams).length === 0 ? null : searchParams,
  })

  if (res.status === 404) {
    global.initial = initial
    notFound()
  }

And then in not-found.tsx:

const NotFound = () => {
  const initial = global.initial
   ...Use your data here

So far seems to work with different paths, routes etc.
Not sure if there are any major drawbacks, but there seems to be some heated debate about using the node global property:
https://stackoverflow.com/questions/10987444/how-to-use-global-variable-in-node-js

[gottfired]

Thanks. Only answer that works without unwanted side effects.

[slatqh]

I ended up passing client component where I can read searchParams and display it in NonFound.

export default function NotFound() {
  return (
    <div>
      <div className='flex flex-col rounded-lg shadow-lg p-4 m-4 justify-start items-center mb-20'>
        <p className='text-xl mt-10 text-default-500'>
          <span className='font-semibold'>404</span> | This page could not be found.
        </p>
        <NotFoundClient /> 
      </div>
    </div>
  )
}

'use client'
const NotFoundClient () => {
    const params = useSearchParams()
    const foo = params.get('foo')
    return (
    <div>{foo}</div>
    )
}

[typeofweb]

One solution that I've found to be working for params is to pass data from layout to not-found by abusing React's cache. For example:

// context.ts
import { cache } from "react";

/**
 * This is a workaround until Next.js adds support for true Server Context
 * It works by using React `cache` to store the value for the lifetime of one rendering.
 * Meaning it's available to all server components down the tree after it's set.
 * Do not use this unless necessary.
 *
 * @warning This is a temporary workaround.
 */
export function createServerContext<T>(defaultValue: T): [() => T, (v: T) => void] {
	const getRef = cache(() => ({ current: defaultValue }));

	const getValue = (): T => getRef().current;

	const setValue = (value: T) => {
		getRef().current = value;
	};

	return [getValue, setValue];
}
export const [getNotFoundContext, setNotFoundContext] = createServerContext<string | null>(null)

// layout.tsx
export default async function Layout({ params }: { params: Promise<{ param: string }> }) {
	const { param } = await params;
	setNotFoundContext(param);

	return (
		<div>{param}</div>
	);
}

// not-found.tsx
export default function NotFoundPage() {
	const param = getNotFoundContext();
	return (
		<div>{param}</div>
	);
}

[devjmetivier]

Clever!