How to prevent useSuspenseQuery throw error if data was fetched successfully

[QzCurious]

I thought it would be common to ignore error if data already show on UI.
For example: I'm on a tweet. react-query do an refetch on background (say I re-focused the window). The Ui should show latest data even the refetch failed.

I want to useSuspenseQuery to fetch data and make an UI that:

• show loading state while loading (can be done by Suspense)
• show latest data if data exists (it's how useSuspenseQuery works)
• throw error to ErrorBoundary only if data not exists

I found issue #5920 imply that useSuspenseQuery would not have throwOnError option. So throwOnError can't help me.

[TkDodo]

yeah there's no way to do this with suspense currently. We can't allow the throwOnError option because if you set it to false, data can potentially be undefined, and one of the things we want with suspense to have data defined if the component renders.

what we could do is:

• still allow passing throwOnError and note that you shouldn't set it to false because types would be wrong then
• default throwOnError to throwOnError: (query) => query.state.date !== undefined for useSuspenseQuery instead of defaulting it to true. That would prefer stale data over throwing, much like we don't show loading screen (suspense fallback) for background refetches. It would be in-line with typings, and users could still manually throw if they want all errors to be handled by error boundaries by doing:

const { error, data } = useSuspenseQuery(...)
if (error) {
  throw error
}

I would like option2, because that's how we're using error boundaries in general, and it's also what I recommend in my blog, but maybe I'm missing something. @Ephem what do you think ?

[Ephem]

Ultimately I guess it comes down to the specific error and the app/data, so I think as default we should do:

• The least surprising thing
• Make the non-default straightforward

Problem is, both throwing and keeping the data could be considered surprising. 😅

User refocusing: "Why is my data being blown away randomly?"
Developer logging errors in an error boundary: "Why isn't my BE/FE error rates matching up?"

In the end, UX trumps DX and users don't know exactly when we are refetching data, so any time data is suddenly gone is a bad experience, so I also lean towards option 2.

Update: Users can get surprised when data updates too of course, but errors are still more severe.

[TkDodo]

User refocusing: "Why is my data being blown away randomly?"

yeah, I agree this is the worst experience.

Developer logging errors in an error boundary: "Why isn't my BE/FE error rates matching up?"

devs could use error logging in the onError callback of the QueryCache, which is always called, so I think it's at least possible to work around this.

Also, given that you can always re-throw any error, I think we should do option 2 for v5 and document that properly.

[TkDodo]

PR here: #5979