add `useQueryState()`

[posva]

Allows retrieving the query state by key

• Should allow passing multiple keys to to match multiple queries and return the aggregated state of these queries
• How should they combine data, error, and status? Should each have an individual array, an object, a map?
• If the state doesn't exist, create it?
• It should handle a reactive version of the matched keys

Same questions for useMutationState()

[ElisePatrikainen]

To temporary reply to the questions (which of course can completely be improved, this is rather a first step), in the PR I have just opened (in draft):

• for the moment, I am returning the data as an array of objects with a similar structure to the query entries
• if the entry doesn't exist, I create it to have reactivity working on it (there is probably a workaround though)

Also, I am wondering if the composable should be called useQueryState (singular) or useQueriesState (plural), since it can handle the aggregation of several queries? Or an alternative could be provide two composables (useQueryState and useQueriesState).

[posva]

I think returning the aggregation is fine. But I think that useMutationsState() is more important than useQueryState(). In fact, I'm not sure about the usefulness of useQueriesState() without all of the options as it could start in an incoherent state (no initial data). So I think we should probably just add the mutation's one first and leave this for later

[ElisePatrikainen]

I am thinking about a use case for useQueryState: allowing accessing the cache of a query without reactivating it. That could be useful in the case of optimistic updates (to access and mutate the cache without potentially triggering a new call). What do you think about that?