Examples / Guidance on how to fetch data a little less smartly

[KsaRedFx]

Hello! This is a bit crazy maybe but I'd love some insight.

I'd like a way to use a call to useQuery that does not re-fetch data if it is inactive under the hood or is some new instance of useQuery (I think my problem is that it's inactive?) I'd really like to be able to call a useQueryFactory(myParams).refresh() as needed and have it return the cached data if it's available without relying on reactivity.

I know that defineQuery exists and it is a great solution for most cases, but in my case I'm running into issues using it as well. In my scenario I'm using the same useQuery with different parameters multiple times in the same page... When I do this, the data loses its observers. With no observers, or because it's technically a new instance of useQuery the data is being refetched when .refresh() is called. That would normally be fine because of the existence of defineQuery but in my case defineQuery would cause the other sections relying on the same instance of useQuery to also update to the newly provided parameters.

I feel like I'm probably misunderstanding something at a base level as it seems counter intuitive to me that different instances of useQuery with the same parameters result in a fresh fetch every time

Should I just be trying to access the cache directly? via useQueryCache or am I expected to build some kind of wrapper around everything that attempts to cache pinia-colada itself or am I just stupid and should move on to some other library that does what I want instead / write one myself

[posva]

I think you are looking for this: https://pinia-colada.esm.dev/cookbook/prefetching.html#Thanks-to-defineQueryOptions

[KsaRedFx]

The docs say that this is for when you do not have dynamic keys, I do. Different pages have different dynamic keys included in their parameters; So would that not be an incorrect use case here? If it can't take dynamic keys, You would still need to manually manage a cache of them yourself still, no?

I'm also not looking to prefetch, I actually want the opposite. I want to essentially postfetch.

This also seems like a lot of manual boilerplate for something that should be relatively simple but just unimplemented in the library (similar to removing cache items...)

[posva]

This is without relying on reactivity as you said
You can pass the defined options to useQuery alongside a getter that returns the parameters of the defined options, and that’s reactive

[posva]

A post fetch or pre fetch is essentially the same code
One line is boilerplate? 😅
Removing cache items is also implemented

with the same parameters result in a fresh fetch every time

that shouldn’t happen. Can you repro?

[KsaRedFx]

I'll try to build a repro to show you what I was experiencing! I did get defineQueryOptions to work for most of what I wanted; I even managed to pass a defineQueryOptions to useInfiniteScroll with a little tweaking and made it work nicely. Something I was doing previously with the raw useQuery was triggering it to fetch multiple times even with a high stale time so I'll build something to show that.

I wasn't finding any simple and reliable ways to clear the cache though? Is there any documentation on that?
Invalidate Cache doesn't seem to be what I want; that just marks it as invalid and triggers an update (which fires off another request). I ideally want to return it to nothingness, i.e. with no stale data available as in my application I expect to navigate away from the data as it will be "Gone Forever" as far as the cache cares until those parameters / that scenario returns.

I do like that you can invalidate hierarchically, that is very nice.

Invalidate Cache seems to already be most of the way there, so it seems counter intuitive to have to write your own map to .remove() especially when reading other discussions, remove seems to break reactivity down the line. Maybe if you don't want to provide a new function, it can be a parameter that is included? Like .invalidateQueries({ key: ..., reset: true, enable: false }); so that you could quickly mark an entire tree of queries as disabled / enabled / reset?

There might be some value in useQuery returning a new function .reset() that returns to whatever initial data would have been, and resets state so that things like isPending and isLoading get updated, and also offer .invalidate() under the hood to immediately mark it as stale... While that wouldn't be a perfect answer for parameterized queries, it would be a very nice-to-have for anyone that has most of their queries set to enabled: false or not refetching onMounted