Understanding 404 Handling in Next.js

Next.js operates as a Single Page Application (SPA), meaning once a page segment is downloaded to the browser, subsequent navigations use soft navigation—avoiding full page reloads. The React fiber tree ensures that nodes remain in memory unless a node at the same level needs to be replaced by a different type.

Default vs. Custom 404 Pages

Next.js provides a default 404 page, and you can also define a custom one. These fall into different error boundaries in the React Server Components (RSC) architecture.

1. Default 404 Page

   • The default not-found.tsx in the node tree is handled by HTTPAccessFallbackErrorBoundary.
     
   • This built-in boundary displays a basic 404 page, which consists of a title and a <div>.
   • The NotAllowedRootHTTPFallbackError at the root level.
     

2. Custom 404 Page

   • If you define a custom 404 page,
     
   • Even if your not-found.tsx file exists in the frontend folder, Next.js ensures it is used correctly in the rendering tree.
     

How Next.js Handles 404 Errors

1. Directly Typing an Undefined URL

When a user manually enters an invalid URL in the browser, Next.js serves the default 404 page because it does not need to render the entire application tree. The root-level boundary (NotAllowedRootHTTPFallbackError) is triggered first and displayed immediately.

2. Navigating to an Undefined Route via <Link>

If a user clicks on a link that points to a non-existent segment, Next.js still uses the default 404 page. Since the segment is not registered in the routing system, the tree is unloaded and reloaded, with the root being rendered first before the error is shown.

3. Calling notFound() in a Server Component

If a server component explicitly calls notFound(), it does not trigger a full reload. Instead, Next.js throws an error that gets caught by the nearest HTTPAccessFallbackErrorBoundary, ensuring that the custom 404 page is displayed.

How to add i18n to not-found or error page?

Notound

Under the given conditions, unless you invoke notfound() in your route, the 404 page designated at the same routing level won't be utilized. However, it is futile as even when invoked, you cannot transmit the locale to the page segment since it gets invoked by nextjs.

When a user visits your segment signifying that there's an active serving page available for them, why should we initiate a notfound command resulting in a 404 error?

Therefore I'll discuss an alternative approach to integrating i18n into our 404 pages to make them having i18n.

Let's leverage catch-all dynamic routing for this purpose.
[lang]-> [...not found], now whenever users attempt to view unavailable pages within 'lang' folder they get redirected to ...not found directory instead and we can then fetch 'lang' parameters from props.

How does it work? The catch-all route acts as a fallback, only being invoked if there's no specified route under the lang folder.

[lang]       
user			  order					[...notfound]	
page.tsx       page.tsx					page.tsx

when user visits the user page or order page, the page.tsx under those folder will be used to sever to user. otherwise the page under [...notound] folder will sever.

Error

In error.tsx, we've constrained it to function as a client component; However we can also use the usePathname to retrieve the current locale and implement the i18n

const pathname = usePathname() // here to get the locale with your path.

Summary

• Soft navigation prevents unnecessary re-renders, except when a different node type replaces an existing one.
• Default 404 pages are served instantly when a route does not exist.
• Custom 404 pages are rendered only when errors occur within the app, ensuring a better user experience.
• Calling notFound() triggers an error boundary rather than a full reload, improving performance.

By understanding these behaviors, you can structure your Next.js app effectively while handling missing pages in a way that aligns with its streaming and rendering model.