erquhart
erquhart•14mo ago

Paginated query not caching

I have a paginated query with very simplistic args, and it doesn't cache, even in back to back requests. The one change I see in the args is that the id in paginationOpts is incrementing each time I call the query, and I'm guessing that difference in args is why the query won't cache. Steps I'm taking: - navigating to a view in a react native app - the paginated query is called on load (first page only) - navigate back to previous view - the view with the query unmounts - navigate forward to the view with the query - query response is not cached, and paginationOpts.id is incremented by 1 compared to the last call
7 Replies
erquhart
erquhartOP•14mo ago
Another day, another support case from erquhart 😅 Yeah seeing this in general actually - it seems like caching is tied to mount/unmount in the react client.
Michal Srb
Michal Srb•14mo ago
This question is about client-side caching. Right now useQuery and friends are only subscribed while the component using them stays mounted. Your choices are: 1. Move the useQuery et. al up the React component tree, so that it doens't get unmounted (often the simplest) 2. Wrap useQuery et. al in a hook that caches the results, either based on function reference and arguments, or based on a provided key Version with a provided key: https://discord.com/channels/1019350475847499849/1185167649496367184/1186491636407087146 You can adapt that to not require a key - if you need help let me know I can take a stab at it.
erquhart
erquhartOP•14mo ago
Ah okay, glad this is well understood. Thanks for the reference, I can use one of these options. Thought about this a bit, and it feels like the stable behavior is what folks will expect as the default. Convex already has a context wrapping my app, so my assumptive model was: - context loads - a query somewhere runs for the first time - that query is registered in the context - the query subscription becomes effectively inactive if no active hooks are using it - registered query picks back up when needed Just feedback, might be more complicated than I'm recognizing.
Michal Srb
Michal Srb•14mo ago
Yeah, it's a bit more complicated. There are many behaviors you might or might not want to choose from: - Cache and never evict - Cache and evict - Cache on ref vs client vs localStorage - Show stale results from cache (hard to maintain consistency on the page) We might in the future allow you to specify all these via options to useQuery et al, but for now you're in control if you use a wrapper hook that does the thing you desire.
erquhart
erquhartOP•14mo ago
If you provided default behavior like this in the future, would you be able to have a default cache strategy that works for most (probably the one in use currently)? There will always be specific things that some folks need, and to your point, very doable in user land for sure. Just thinking about the next step or so forward.
Michal Srb
Michal Srb•14mo ago
Which caching behavior do you think should be the default? Which eviction behavior? The current behavior basically maps to useState.
erquhart
erquhartOP•14mo ago
I think of Convex caching as being driven server side and being reactive, so effectively self evicting. What am I missing? As far as ref/client/localstorage, if useState is currently being used, a ref is a pretty close match

Did you find this page helpful?