Persisted data removal on error

[salembaira]

Hello guys and thank you for this awesome library.

I'm really not sure if this is a bug or not. Let me explain :

• when using useQuery, data is available after error state, assuming it was successful before
• when using persistClient, the query data is removed after an error occurs

I find these two behaviors inconsistent with one another. What if my API is having issues and I want the user to still get the old data even after reloading the app ? I could then, use the error state to warn the user that we are experiencing issues.

[karol-janik]

@TkDodo already created a great blog post, in which he present the idea to show the data first, maybe that will help, PTAL: https://tkdodo.eu/blog/status-checks-in-react-query

[TkDodo]

• data is never deleted due to a background fetch, even if it fails, as you might want to prefer showing stale data.
• the query will still be in error state though, and only queries that are in success state will be persisted. This can be customized by passing shouldDehydrateQuery to dehydrateOptions. The default is:
  https://github.com/tannerlinsley/react-query/blob/5848fab8a560efcf66ef0062c207c3004bccad83/src/core/hydration.ts#L72-L74

but you can change that to e.g. !!query.state.data to include all queries that have data, even erroneous ones.

thinking about it, this might even be the "better" default implementation, we could change that for v4 🤔

[TkDodo]

• that error will just be an object and not instanceof Error
• errors can be sub-classed (extended), like axios does with their AxiosError. All those things would get lost.

[salembaira]

So we are gonna let the whole state get lost just because we can’t stringify the error instance ? What if we add something like isPersistedError to signal that this is a simple error object.

Anyway, I won’t complain too much as my current patch for react-query does the job but it would be really nice if this could be something that the library handles by default or at least is configurable.

[TkDodo]

This is just the default behaviour. You can customize this for your needs by:

• setting shouldDehydrateQueries in dehydrateOptions to your needs
• you can also set a custom serialize function to serialize errors the way you want. You can also use something like superjson if you want

most people likely just show the error if the query is in error state, something like:

if (query.isError) {
  return 'Error:' + error.message
}

if you ignore background errors and show stale data instead and want to persist that, you can do so, but the default behaviour won't change for the reasons I've mentioned. It's literally 2 lines of code to setup on the global persistence plugin :)

[salembaira]

You are right. A custom serialize function + shouldDehydrateQueries seems more than enough. Do you think this is worth mentioning in the docs ? I suspect a lot of offline-first apps need this.

[TkDodo]

Sure, docs can always be improved. Feel free to add a PR to the beta branch