does global-error.tsx support metadata/generateMetadata? #82284
-
Summarythe docs state that the new does Additional informationNo response ExampleNo response |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 7 replies
-
|
Hi @stefanprobst, Great question! As of now, global-error.tsx does not officially support metadata or generateMetadata like global-not-found.tsx does. The current Next.js documentation confirms that you can define metadata in global-not-found.tsx for the 404 page, but for global-error.tsx (which handles error boundaries), metadata support is not yet documented or fully implemented. If you need to customize metadata for error pages, a common workaround is to handle metadata inside your error UI component manually or at a higher layout level. This is an area that might improve in future Next.js releases, so keeping an eye on official changelogs and discussions is a good idea. Hope this helps clarify! Let me know if you want tips on alternative approaches. |
Beta Was this translation helpful? Give feedback.
-
|
This error component is a client component. It even receives a reset callback function. Client components don't support the metadata API. |
Beta Was this translation helpful? Give feedback.
-
|
what is the recommended way to set a document title then, with |
Beta Was this translation helpful? Give feedback.
-
|
That should work, but I wonder how does it play along with the root layout's metadata definition, would you end up with two title tags? That ought to be escape-hatch, but I can imagine there's some edge cases that could make it a bit rough. What kind of process is triggering your global-error? If I may ask. |
Beta Was this translation helpful? Give feedback.
-
is
i'm asking mostly for my own understanding of the framework conventions. |
Beta Was this translation helpful? Give feedback.
-
The other way around, both in implementation and as observable behavior, the global-error wraps the root layout. It is just not as straightforward to follow from the code though, I think anyway, unless you have navigated this before. There's a That content contains the root layout, and this content is further wrapped with other boundaries, one of those is something like |
Beta Was this translation helpful? Give feedback.
-
|
hmm the docs on "Global error UI must define its own |
Beta Was this translation helpful? Give feedback.
-
That's what I am saying, the content has your root layout - and then this is wrapped by the GlobalErrors, custom or default, if there's an error, the content is replaced by what's defined in the latter. Edit: Oh I realize I phrased the start of my answer incorrectly 🤦 - Fixed. I think I read it as |
Beta Was this translation helpful? Give feedback.
-
|
If we feel like things have been answered, maybe we can answer/close this discussion, for now? |
Beta Was this translation helpful? Give feedback.
The other way around, both in implementation and as observable behavior, the global-error wraps the root layout. It is just not as straightforward to follow from the code though, I think anyway, unless you have navigated this before.
There's a
DefaultGlobalError, in that file both a type and a component are exported. You can see they are used atapp-renderandapp-router, but like, the proof I'd say is in thelet content = (bit inapp-router.That content contains the root layout, and this content is further wrapped with other boundaries, one of those is something like
globalErrorerror components, and another is theDefaultGlo…