-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suspense error handling #1347
Comments
This is definitely something that's needed. In general we think the Suspense API as a whole needs more usage testing and another round of focused design, including error handling and interaction with transition etc. But at this stage we are focusing on getting other parts of 3.0 stable first. Suspense will likely remain an "experimental" API for now. |
Having a slot for |
@yyx990803 can you give a signal regarding Suspense? Not pressuring you, I'd just like some info to take decision on our future developments here. |
@yyx990803 Friendly ping here. But since I opened this issue in June 2020, there has been no public activity on this topic. Do you have any ETA or plan to communicate about Suspense? |
…n components until issue is fix on vuejs/core#1347
Hello @yyx990803, is there an update here? I can see that the |
Now that version 3.0 has been out for a while, what about Suspense? For my part, although I find the component very interesting, it bothers me (especially for work) that it is still marked as experimental. I think it would be interesting to release it as a stable version. The improvement for the handling error is really interesting, I think it's a very good idea. Can we expect a stable release for Suspense? @yyx990803 |
What problem does this feature solve?
Suspense can be used to asynchronously load data and easily display fallback content until everything is properly loaded.
One important aspect of data loading is error handling and currently it is suggested that we use the error captured hook for that.
I think using this hook for this purpose is not ideal.
TL;DR: the hook will intercept all errors, even those happening much later and unrelated to the async loading.
Not being able to differentiate the source of the error leads to situations that are hard to handle:
Imagine that you use Suspense and just want to display a "Server Not Available" message in place of the component if loading fails. You implement this with
onErrorCaptured
, aref
and av-if/else
.Also consider that you have some global error handling higher-up (maybe at the app level). Once the component is loaded, other errors may occur and they will go through the
onErrorCaptured
hook that you had set up. How do you know if you should let the error bubble up or handle it?Probably the better way to handle this right now is to have a flag indicating if the component has loaded or not, which involves one more variable, one more if in the error hook, and handling both
onResolve
andonRecede
on the Suspense component.What does the proposed API look like?
I propose additions to the
Suspense
API that will make handling errors properly much easier:In this scenario we're only interested in Suspense async rejections, not all errors for the lifetime of the component. I suggest an additional
onError
event onSuspense
, which is only called when the loading fails, not on all errors.Displaying alternate content on error is a common thing. I suggest that
Suspense
does this automatically if an#error
slot was provided.Both 1. and 2. would happen should the developper provide both options.
If neither happend, i.e. the event goes unhandled and there is no error template, the error should bubble through app-wide
handleError
, as today.The text was updated successfully, but these errors were encountered: