Skip to content
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

Open
jods4 opened this issue Jun 11, 2020 · 6 comments
Open

Suspense error handling #1347

jods4 opened this issue Jun 11, 2020 · 6 comments
Labels

Comments

@jods4
Copy link
Contributor

jods4 commented Jun 11, 2020

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, a ref and a v-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 and onRecede 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:

  1. 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 on Suspense, which is only called when the loading fails, not on all errors.

  2. 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.

@yyx990803
Copy link
Member

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.

@bbugh
Copy link

bbugh commented Oct 10, 2020

Having a slot for #timeout and/or integrating it with #error would be nice too. For example, in the case where an async query times out, we don't want to fall back to "loading..." again, we want it to show to the user that the operation took too long and died.

@jods4
Copy link
Contributor Author

jods4 commented Oct 30, 2020

@yyx990803 can you give a signal regarding Suspense?
Now that Vue 3 is out, do you have an idea what's gonna happen with it? Are you working on making this stable, an outlook on the timeframe for that?

Not pressuring you, I'd just like some info to take decision on our future developments here.
Suspense is a nice feature to simplify some cases, but the experimental status and lack of good error handling is holding us back.

@jods4
Copy link
Contributor Author

jods4 commented Jan 10, 2021

@yyx990803 Friendly ping here.
I agree that error handling is one thing that must be polished before Suspense can leave its Experimental status.

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?
It was a much touted feature of 3.0, I would love to see it released in a 3.1 or something.

st-wong added a commit to proximax-foundry/xpx-storage-explorer that referenced this issue Jan 14, 2021
@dannysmc95
Copy link

Hello @yyx990803, is there an update here?

I can see that the timeout attribute added does not work for some reason (tried with :timeout="5000" and timeout="5000" and that error element would be awesome.

@SirMishaa
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants