You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently hit a difficult part regarding how to handle query cache in our application.
Hence i have couple questions and a proposed approach where I need some comments about.
Previously we only had a single property in our query key to support the offline mode because this property is not something that changes overtime. But this approach quickly became a problem because now we lost the ability to trigger automatic fetching when query key changes since the query key didn't have the dynamic properties.
We use dynamic query keys now, query keys that include certain states that can change based on user actions. This triggers the query to fetch the data again.
We also support "offline mode". Where a user can go offline and still do some limited actions such as searching in a list.
Q: Now the question that i have is when having a query key that includes dynamic states that can change, am I safe to assume that this could create infinite number of cache entries? (I am using persistance)
I assumed that answer to this question is yes, and continued implementing a custom approach for caching when query key is dynamic.
What i did was:
I am storing the result of a single query in the storage.
When i switch the device to offline, I am using a different query key that does not include any dynamic properties.
I seed the query from storage (Query with the static key in the second step)
User searches the list and results are written to this query cache.
Query cache is re-seeded after user closes and reopens the application to keep the original state of the query. (this is to cover some edge cases)
When is becomes online, query key switches to the dynamic one enabling dynamic query fetching after query key properties change.
This introduces an additional layer on top of the existing cache management of react query but based on these steps, is this something thats feasible to do to solve the problem at hand? Are there any other possible approaches in terms of the case described?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey there!
I recently hit a difficult part regarding how to handle query cache in our application.
Hence i have couple questions and a proposed approach where I need some comments about.
Previously we only had a single property in our query key to support the offline mode because this property is not something that changes overtime. But this approach quickly became a problem because now we lost the ability to trigger automatic fetching when query key changes since the query key didn't have the dynamic properties.
We use dynamic query keys now, query keys that include certain states that can change based on user actions. This triggers the query to fetch the data again.
We also support "offline mode". Where a user can go offline and still do some limited actions such as searching in a list.
Q: Now the question that i have is when having a query key that includes dynamic states that can change, am I safe to assume that this could create infinite number of cache entries? (I am using persistance)
I assumed that answer to this question is yes, and continued implementing a custom approach for caching when query key is dynamic.
What i did was:
This introduces an additional layer on top of the existing cache management of react query but based on these steps, is this something thats feasible to do to solve the problem at hand? Are there any other possible approaches in terms of the case described?
Beta Was this translation helpful? Give feedback.
All reactions