T
TanStack4w ago
flat-fuchsia

How to handle old (now) invalid persisted data?

I am using the tanstack query's persist plugin to persist queries on filesystem. What's a proper approach for handling old data (coming from an API) missing fields that are now available in the API? Should I just consider all new fields as optional and check for their existence before rendering? Should I just invalidate the persisted cache? (I'd rather avoid this, as I cannot seem to cache bust only 1 query, I have to bust the whole cache when 1 singular query is wrong)
9 Replies
flat-fuchsia
flat-fuchsiaOP4w ago
Ideally, I want to keep maxAge: Infinity, while keeping some sort of option to invalidate entries that are not valid anymore Also, I am using the experimental createPersister API
rising-crimson
rising-crimson4w ago
I'd use the cache_buster if you want infinity maxAge yes it busts everything but 🤷‍♂️
flat-fuchsia
flat-fuchsiaOP4w ago
Just wondering, could there be a per query cache_buster in the future? As, with this experimental API, I know that queries are persisted individually. Would be nice to also be able to bust individually.
rising-crimson
rising-crimson4w ago
wait a sec are you using the PersistQueryClientProvider or createPersister ?
flat-fuchsia
flat-fuchsiaOP4w ago
experimental_createQueryPersister
rising-crimson
rising-crimson4w ago
hmm there's no way to bust specific queries atm
flat-fuchsia
flat-fuchsiaOP4w ago
I literally yesterday moved from PersistQueryClientProvider to the experimental one, in the past I had some issues with it (the experimental one), but i think they were caused by me setting retry: false as a default option, I changed it to retry: 1, so queries do not fail if no cache is present and instead they remain pending
rising-crimson
rising-crimson4w ago
you could implement your own storageand have getItem return undefined for cases where you know you want to cache bust but you'd also need to call removeItem maually then
flat-fuchsia
flat-fuchsiaOP4w ago
yeah, ig I'd set some sort of key in the query meta and compare the cached one with the current one somehow to remove the query I think I will go with this approach:
Should I just consider all new fields as optional and check for their existence before rendering?
this way I can use old data to render something while offline, and I'll just query.data.field ? <>...</> : null the elements that depend on the new field

Did you find this page helpful?