Replies: 0 comments 9 replies
-
I wish you left us with a quick example of how this is done. The read was kind of confusing to me |
Beta Was this translation helpful? Give feedback.
-
Do we have any plan for this ? |
Beta Was this translation helpful? Give feedback.
-
any change?it's an important feature we can't |
Beta Was this translation helpful? Give feedback.
-
When you have fully unknown generic routes (for example coming from cms) you should use [...slug].vue for "catch-all-routes" as mentioned in the documentation: https://v3.nuxtjs.org/docs/directory-structure/pages Obviously in that case it is up to [...slug].vue to handle errors and direct user to the error page. In Nuxt 2 there exist a validate hook for pages, when returning false the user got redirected to error page. Also there was an error() function to navigate the user to error page. In Nuxt 3 i currently cannot find any equivalent. I think there is currently no possibility to handle errors with "catch-all-routes" case. Which really is a problem, at least for me. This should also be discussed here. |
Beta Was this translation helpful? Give feedback.
-
Still waiting for this as while using in every pages
we have to do manually check for errors which should be in a way that we can handle as global level |
Beta Was this translation helpful? Give feedback.
-
Nuxt 3 as a full-stack framework, has several sources of unpreventable unhandled user runtime errors that can happen in different contexts:
We need a unified framework for error handling in order to:
For isomorphic error rendering currently, we have nuxt design templates that handle any nitro errors but the problem is that they are not isomorphic, creating a custom version is not easy and are not reactive the upside is they are pretty much lightweight as is static HTML.
To avoid the same mistake of nuxt 2 to make exactly two (html+SFC) versions of the default error design, we can simply wrap the existing HTML error to a Vue SFC and use it for isomorphic (+SPA) rendering logic. This can happen during the design packaging process.
To allow replacing default error with a user-provided component that can be reactive, isomorphic and allow using bundled assets like images and styles, we can expose an API from
#app
that allows rendering an error app, with the main component replaced with Error component (instead of<NuxtPage>
). This solution can be universally to handle all different contexts. For the server-side, we need a nitro try/catch similar to the mechanism currently is used for HTML error rendering and for SPA unhandled errors, replacing dom. Replacing for SPA adds perf penalty but allows reusing almost the same logic that is used when capturing server/global errors and considering it should probably not happen in normal situations, an unhandled fatal SPA error is already a bad UX that needs to be gracefully handled by developers.For context, Nuxt 2 error handling:
fetch
hook errors cannot be handled and need to be handled per component with$fetchState
Related issues:
Beta Was this translation helpful? Give feedback.
All reactions