But can you show the code you have now? It would allow me to see real world use cases of it 🙂
Initially I wasn’t planning on adding this feature, I wanted to see it used first to ensure what is really needed in terms of API

Yeah, there isn't useQueries() in pinia colada (at least yet). So far, I feel like using useQuery() within a component achieves the same behavior because you can do v-for on the component and that has the behavior you want

In my opinion, this overcomplicates a simple task, or doesn't solve it at all. Of course, if I understand the solution correctly.

The solution via v-for solves a small area of use cases. To me, it is like "I get the data and want to render it somehow". But what if I am not going to render it anywhere directly, but store or process some way. We can imagine a simple pinia store using this hook and saving the results somewhere. In this case I don't see how v-for is applicable

But what if I am not going to render it anywhere directly, but store or process some way.

Do you have an example?

We can imagine a simple pinia store using this hook and saving the results somewhere. In this case I don't see how v-for is applicable

This sounds like a one time manipulation, in that case it's better to directly use the query cache and call its methods like queryCache.getEntries(). Note useQuery() is a composable and cannot be used in a method (that creates memory leaks). If you call it wihin a setup store, your queries live forever (because stores are global), which can be intended but better be sure as they cannot get garbage collected.

Sorry for the late response. I forgot about the conversation.

My understanding of the v-for solution

I'll begin with my understanding of what the v-for solution is.

If I understood correctly, the idea is to render N instances of the same component, passing the props they can use in the useQuery composable inside. This could be some renderless component like UseQuery (named just for convenience, it could be anything more project-related and "renderful") with properties equal to useQuery options. This component may provide a slot with the useQuery composable outputs.

We can also define exposes on this component, or even emitted events to react to specific library events (like @loaded="doSomething").

Here is the example:

<template>
  <UseQuery v-for="option in options" :key="option.key" v-bind="option" v-slot="{data}">
    {JSON.stringify(data)}
  </UseQuery>
</template>

This approach has the following problem — the component rendering the template above will not be able to know if the data is already accessible until the template is rendered. For example, when calling useQuery, I could already get data fulfilled with some value and use it instantly. I could use it for SSR purposes, for example.

Well, this approach solves some spectrum of use cases, but still doesn't solve all of them.

Hypothetical case

Now, let's consider a hypothetical case that could be a real-world problem.

I have the following list of requirements:

1. A table with 2 columns: a URL and its loading status. A URL is just some file URL, and the loading status is responsible for determining if the file was loaded.
2. A row in the table is responsible for displaying the table summary: how many files were loaded, failed to load, etc.
3. A button that allows adding a new row with a URL specified by user.

To me, the intuitive solution is the following:

1. Define a ref fileUrls that contains all URLs we are working with. Clicking the button allows adding new values to this ref.
2. Call useQueries (not useQuery) with all file URLs specified and load them.
3. Define a computed that iterates over useQueries returned values and collects results.

The abstract code is something like that:

const queryOptions = defineQueryOptions((url: string) => ({
  key: ['load-file', url],
  query: () => fetch(url).then(r => r.blob())
}));

const fileUrls = ref<string[]>([]);
const { queries } = useQueries({
  queries() {
    return filesUrls.value.map(url => queryOptions(url));
  },
});
const stats = computed(() => {
  return queries.value.reduce(() => { ... }); 
});

const handleAddClick = () => {
  fileUrls.value.push('...');
};

Since there is no such composable as useQueries, I would have to use useQuery and manually determine if I already loaded some URL before. As you may understand, this complicates a single task significantly and also breaks one of the fundamental features provided by the library — caching results using keys, since I will have to pass a dynamic list of URLs as a key.

Conclusion

As libraries developer myself, I understand that implementing something new in the library should be reasonable as it takes time and effort, and to me, the problem I described seems reasonable enough. If you agree but are looking for a contribution, I could dive into the library code and provide a fitting solution.Sorry for the late response. I forgot about the conversation.

Your understanding is correct. In most cases a regular renderfull component would do.

Regarding your hypothetical case, I would still use a regular component for the rows that contain the data and just use keys.value.map(key => queryCache.get(key)) to collect other useful information needed for the summary