Nuxt error() does not stop execution of previous component

[jovanmaric]

Version

v2.3.4

Reproduction link

https://github.com/jovanmaric/nuxt-axios-error

Steps to reproduce

The reproduction link contains a generated app with the latest Nuxt and the following setup:

• Custom error layout page
• axios module
• nuxt-i18n module
• axios plugin which throws an error if 404 or 500 or higher error is returned.
• Express with /api proxy

To reproduce you should run yarn dev and open the console on chrome.

What is expected ?

That the error component is injected instead of the original component, removing all the semantics of the original component.

What is actually happening?

Uncaught (in promise) TypeError: Cannot read property '_t' of null while no code of the original component should be ran.

Additional comments?

The above error does not only apply to the created() method. Leading me to think that the re-render is retriggered on server side, while this shouldn't be when the error component injects itself instead of the original component.

_{This bug report is available on Nuxt community (#c8377)}

[hecktarzuli]

This would be pretty sweet, but pretty hard to actually pull off especially in all the places you can call error() .. like asyncData, fetch, created (via this.$nuxt.error) etc..

[jovanmaric]

However, calling error even within the places you summed up, would probably promote proper error handling flow. As currently everything below the error can cause unneeded side effects. I've updated my example with a console.log after the error() call in the axios middleware to show that it's still running.

Maybe i'm biased by other languages (as javascript isn't my primary), but having a middleware be able to call error for instance, while components still are able to make state changes or worse, feels like a smell to me.

[hecktarzuli]

If you were just showing a 'uh oh something sploded' message and sending a raw response to the browser, then I think that may be easier, but since Nuxt lets you show a pretty error message where other stuff really is rendered and code just doesn't early-out I think this is challenging. I'm just guessing.. In the end, I want the same thing you do, as I too have to code against edge cases. (Api returned 404, then return null to vuex, then in comps handle if computed prop is null within asyncData/fetch/router guards etc.. Having error messages being a 'full stop' would make thinks much easier.

[stale]

Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of nuxt-edge
2. Comment the steps to reproduce it

Issues that are labeled as 🕐Pending will not be automatically marked as stale.

[stale]

Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of nuxt-edge
2. Comment the steps to reproduce it

Issues that are labeled as 🕐Pending will not be automatically marked as stale.

[rchl]

I'm curious how the reproduction looked like for this because I've made some fix that might be relevant - #20719

Unfortunately the original repo is no longer present.

[jovanmaric]

@rchl Yeah after years of no response I deleted it, sorry. From what I can remember:

• I created a http service for axios which exposes the get/post etc methods.
• The http service is injected into nuxt as $http (plugin).
• An interceptor in the http service calls the error method on 404 and 500.
• Nuxt properly swaps the layout to the error page, but still calls the created() method from the original for some reason.

Hope this helps in any way. Also keep in mind that this was quite an early version of nuxt 2. Your proposed implementation does looks like a way to fix the issue however.

[rchl]

And where was $http used from? Async data? created hook? Middleware?