Open sandrosc opened 1 year ago
I'd admit the error boundary support is not ideal.
If you are using dataAtom
(the first one from atomsWithQuery), it works like Jotai atoms and not like TanStack Query.
If you are using statusAtom
(the second one), it works more like bare TanStack Query, but no error boundary support. (because it depends only on @tanstack/query-core
not @tanstack/react-query
.)
So, in either case, it's suboptimal.
Thank you for the fast answer! So the best solution for now might be doing a window.reload()
to cause a refetch of the entire page?
I wouldn't say reloading is best. How about adding a dummy atom as a dependency?
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?
seems to work by changing the user state to a different view where the query doesn't fail.
By dummy atom, I mean something like the user state ☝️ .
do you think this library will work with the error boundary reset in the long run?
If it's about how Jotai handles error boundary, the functionality should be stable.
If it's about something very specific to this library, not sure. But, I think the current dataAtom
is fairly a general Jotai atom.
That said, I agree there's some uncertainty, so using statusAtom
would be a safer bet.
If it's about something very specific to this library,
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 dataAtom
and statusAtom
could cover most cases, but they are still suboptimal.
We need maintainers with good understanding with tanstack/query-core and Jotai to revisit the API. (jotai-urql
recently got a new maintainer and has a new API, dropping atomsWithQuery
.)
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?