Provide a way to pass custom data to the 404 page when notFound: true, or return specific page

[kristijorgji]

Describe the feature you'd like to request

When using getStaticProps, it is currently possible to return either props and a page, or notFound: true

Example

export async function getStaticProps(
    context: GetStaticPropsContext<{ id: string }>
): Promise<GetStaticPropsResult<{ data: any }>> {
    const res = await apiTokenRequest(`/data/${context.params?.id}`);
    return res.status === 404
        ? { notFound: true }
        : {
              props: {
                  ...(await serverSideTranslations(context.locale || DEFAULT_LOCALE, tNamespaces)),
                  data: await res.json(),
              },
              revalidate: 60,
          };
}

Currently it is not supported passing props down when returning

{ notFound: true }

or specifying a page you want to return like

{ notFound: true, page: 'users/not-found.tsx' , props: {id: requestedUserId } }

Passing props down here is very useful for showing different 404 content for different pages.
Example:
requested user profile not found
requested post does not exist anymore
requested product does not exist
and so on

For all possible different not found types, we would like to show beautiful nice unique 404 pages for a great customer experience, and not just a generic "404 - page not found".

Describe the solution you'd like

Solution 1:

Change the possible response of GetStaticPropsResult from

export type GetStaticPropsResult<P> =
  | { props: P; revalidate?: number | boolean }
  | { redirect: Redirect; revalidate?: number | boolean }
  | { notFound: true }

to (only last row changed, allow passing props to notFound)

export type GetStaticPropsResult<P> =
  | { props: P; revalidate?: number | boolean }
  | { redirect: Redirect; revalidate?: number | boolean }
  | { notFound: true; props: P; }

Then in 404.ts we can use the prop

if (props.type === 'user') {
return

Requested user is not found

}
// and so on for different types

Solution 2

If our fetch logic notices that a particular item does not exist, api returns 404, allow to return a custom "view" page (without using the redirect and increase the overhead).

example:

pages/posts/[id].tsx

// component 
// other stuff

export const getStaticPaths: GetStaticPaths = async () => {
    return {
        paths: [],
        fallback: true, // render only when requested as we have milliions of posts and build would take forever
    };
};

export async function getStaticProps(
    context: GetStaticPropsContext<{ id: string }>
): Promise<GetStaticPropsResult<{ data: any }>> {
    const res = await apiTokenRequest(`/data/${context.params?.id}`);
 

// HERE SUGGESTED new possible response, to return a "view", page   
if (res.status === 404) {
   return {
          notFound: true, // this just to set status code of response to 404
          page: 'pages/posts/404',
          props: {
            id: context.params?.id
          }
    }
}

return 
        {
              props: {
                  ...(await serverSideTranslations(context.locale || DEFAULT_LOCALE, tNamespaces)),
                  data: await res.json(),
              },
              revalidate: 60,
          };
}

Describe alternatives you've considered

I have considered some hacky solution to check in the 404.tsx page the current url, then use the client router to determine the current page, then show a cusomised message.

I would prefer to have implemented in next the suggested solution 2, with full power and flexibility of returning a specific page for a given 404 error, based on the data type (post, user, song, product, etc)

[Noitidart]

Thanks for posting this. I also very much need to return custom props to 404 pages.

One alternative for getServerSideProps is when returning { notFound: true } we can set some data in a cookie, and the page can read from the cookie.

[kristijorgji]

That is super hacky and ugly solution, but at least is one alternative until next team allows for something such normal a normal solution.

We are not babies needed to be babysit and remove the functionality of returning props for 404 pages 500 pages etc.
This is not simplifying the framework, is just making people fork next or use hacky solutions.
It is way better to leave more powerful options and functionalities than to remove them and trying to force user to do things in a single way, which apparently misses many functionalities.

[Noitidart]

True, its really ugly solution :( And it doesnt work for static props :(

[david-alpert-nl]

I want to give a heavy 👍 to this request and expand upon it to support more nuanced responses than simply { notFound: true }

export type GetStaticPropsResult<P> =
  | { props: P; revalidate?: number | boolean }
  | { redirect: Redirect; revalidate?: number | boolean }
  | { notFound: true; props: P; }
  | { err: Error }

or

export type GetStaticPropsResult<P> =
  | { props: P; revalidate?: number | boolean; err: Error }
  | { redirect: Redirect; revalidate?: number | boolean }

404 Not Found is the simplest case of an error we want to handle.

we also need a pattern for handling:

• 400
• 401
• 403
• 500
• 503
  etc

allowing a "successful" response from getServerSideProps that includes an expected Error would allow us to "successfully" return error context without having to raise an unhandled exception.

[david-alpert-nl]

The more I look at this code the more I feel constrained by { notFound: true } as it seems only useful in very basic use cases.

It would be far more useful for methods like getServerSideProps to raise or return an explicit NotFoundError and route based on that.

What I am looking for is the ability to raise or return different types of errors to more explicitly express our error landscape, and to be able to pass more context from the site of those errors to our error page so that:

• our error page(s) can return a more expressive set of HTTP response codes; and
• our error page(s) can receive more props as context to better customize our rendering of error pages