-
Notifications
You must be signed in to change notification settings - Fork 14
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
How to reset atom to loading state after reseting an error boundary #32
Comments
I'd admit the error boundary support is not ideal. If you are using So, in either case, it's suboptimal. |
Thank you for the fast answer! So the best solution for now might be doing a |
I wouldn't say reloading is best. |
You mean like an dummy atom around the query atom that catches the error if it occurs? |
Another question, do you think this library will work with the error boundary reset in the long run? |
By dummy atom, I mean something like the user state ☝️ .
If it's about how Jotai handles error boundary, the functionality should be stable. That said, I agree there's some uncertainty, so using |
Yes I think it would be nice to integrate jotai and tanstack-query so that the case at the beginning of the issue can be handled easily. Handling user state separately defeats the purpose of the error boundary, which is supposed to be generic in my case. |
I thought We need maintainers with good understanding with tanstack/query-core and Jotai to revisit the API. ( Any volunteers? |
So far I've tried using the
QueryErrorResetBoundary
(like described here) and callingqueryClient.invalidateQueries(...)
manually when reseting the error boundary, but the outcome is as follows:The error handling example you provide seems to work by changing the user state to a different view where the query doesn't fail. When navigating to the item that causes the error, it immediately fails again. How could we reset the query, so instead of failing the atom tries again and reenters the loading state?
The text was updated successfully, but these errors were encountered: