Offline first Persist being removed

[Wolfleader101]

Hi,

I am trying to wrap my head around an offline first approach using persistQueryClient.

The current issue is that if the app isn't "offline" but the API requests are failing (which is valid of behind proxy, or some other network issue) it then removes it from the local storage. This seems inline with the docs.

My issue is, that I don't want it to remove it from the storage. If there is an error to the request, and there is valid cached data, then it should continue returning the cached data in persistant storage, and not show as an error.

In the case of having an error, and no cached data, then it would enter the error state.

A similar discussion was had in #3623 - although this isn't the same use-case as I don't want to serialize errors.

What would be the best solution around this?

[TkDodo]

If there is an error to the request, and there is valid cached data, then it should continue returning the cached data in persistant storage, and now show as an error.

we don’t do this because errors aren’t serializable. You can overwrite the shouldDehydrateQueries to also write when you have data and an error, but keep in mind that this will have some implications:

when a query is in error state, our types say that error is always defined, so if you do:

const { isError, error } = useQuery(...)
if (isError) {
  return error.message
}

typescript will allow it. Now if you have data, and then get an error, you have this in the cache:

data: MyData,
error: MyError,
status: 'error'

once you insist on writing this to the storage, MyError becomes null because errors aren’t serializable (unless you use something like superjson). Now if you restore this from storage, it becomes:

data: MyData,
error: null,
status: 'error'

which would make the above code fail at runtime because we cannot read message of null. But I have literally written the same explanation in the other discussion you linked (#3623 (reply in thread)), so I’m not sure what more you’d need ?

[Wolfleader101]

Sorry, a stupid typo there and now show as an error. should be "and not show as an error." - Which completely changes the answer, apologies.

The issue is that I dont want the error to be shown, and I dont want the error to clear the valid data from the cache.

The current issue is the following

1. App goes offline
2. User loads their profile page - it makes request to API which fails, but dada exists in storage
3. Show the users data from storage
4. Tanstack Query clears the data from storage due to error (You DONT want this)
5. User changes pages and comes back to profile, no data is shown`

A solution is to use the shouldDehydrateQuery and ONLY check if data is not null, essentially forcing cached data back into the cache.

const queryClient = new QueryClient({
  defaultOptions: {
    dehydrate: {
      shouldDehydrateQuery: (query) => query.state.data != null,
    },
    queries: {
      networkMode: "offlineFirst",
      gcTime: Infinity,
      staleTime: 1000 * 30, // could be 0, but saves us spamming requests when "offline"
      retry: 2,
    },
  },
});

The downside to this is that it still exists in an error status

For rendering, If you check for data before an error its not necessarily an issue, as an error state will never be shown, but the data is still flagged as erroneous.

It just feels like there has to be a better approach than this 🤔

[TkDodo]

if a query got an error, it’s in errors state and we have the error. the persistence is a 1:1 copy of the cache, we can’t just say that it’s not in error state if it is in error state in the memory cache.

the best thing you can do is to ignore background errors completely, given that you apparently don’t want them:

const profileQuery = useQuery({
  queryKey,
  queryFn: async ({ client, queryKey }) => {
    const current = client.getQueryData(queryKey)
    try {
      return fetch(...)
    } catch (e) {
      if (current) {
        return current
      }
      throw e
    }
  }
}

That way, when an error occurs, you’ll still return “stale” but cached data. This will completely swallow the error for both the in-memory cache and therefore also for the persisted entry.

---

The other alternative is to use something like superjson for the serialization when doing persistence, as it can also persist Error classes.

[Wolfleader101]

Hmmm 🤔

I guess the error state being known is beneficial to know - , i,.e in some of my hooks I check if the profile query has failed (but has valid data) - this would help validate that they are offline, BUT data does exist (i.e yes an error has occurred, but there's data so continue serving it)

I guess ill just leave it how I have it for now though as it achieves the desired outcome