defineQuery in composables with parameters

[niklaswolf]

Is it necessary to use defineQuery in the following case, or is it sufficiant to use useQuery?
How would I use defineQuery in such a case, because the setup function doesn't allow for parameters.

// outside
const todoId = ref('my-id')
const {data} = useTodo(todoId)

// composable to group all functionality for a single todo
const useTodo = (id: Ref<string>) => {
    const query = useQuery({
        key: () => ['todo', id.value],
        query: () => {
            return fetch(`/api/todos/${id}`)
        }
    })

    // other function regarding a todo, e.g. a mutation
    const otherFunction = () => {...}

    return {...query, otherFunction}
}

The useTodo composable would be reused in multiple places.

[posva]

In this case of scenario, the todoId would be inside of the defineQuery():

// composable to group all functionality for a single todo
const useTodo = defineQuery(() => {
  const id = ref('my-id')
  const query = useQuery({
    key: () => ['todo', id.value],
    query: () => {
      return fetch(`/api/todos/${id}`)
    },
  })

  // other function regarding a todo, e.g. a mutation
  const otherFunction = () => {}

  return { ...query, otherFunction, id }
})

This makes id a global ref though. Where is this id coming from? Usually I would put this kind of information in the route, allowing me to use it within defineQuery too

[posva]

no, this one is different, it's closer to a composable

[niklaswolf]

@posva you're right, most of the time this should be fine to take it from the route.
But there are some cases, for example if you need to enrich the current data with some data from another entity, which has of course most of the time a own REST-Endpoint. The id of the referenced resource would come from the "initial" API-response. So it wouldn't be a route change. But because there is also a detail view in the application for the referenced entity, it would be nice to be able to reuse the composable for the other entity somehow, as it can provide some additional functionality belonging to this entity.

[posva]

You should probably implement a composable that matches your specific use case. It's getting hard to follow without code for me

[niklaswolf]

I created a stripped down, not functional example but it shows what the use case is
https://stackblitz.com/edit/nuxt-starter-cnkfpx?file=app.vue

Would this be the right approach to do something like this (regarding pinia colada usage)?
I'd find it most intuitive if you could pass the authorId as a parameter to the useAuthor composable, but I'm also fine to structure it a different way if that's the best practice. Basically I'm wondering what the best practice for such a situation would be regarding pinia colada :)

[posva]

This piece of code is problematic:

const route = useRoute();
const { data: author, id } = useAuthor();
id.value = route.params.id;

The id is disconnected from the actual source of truth, which is the route. So I suspect there is something that can be improved in our project and isn't visible in a smaller repro.

It's possible you have multiple queries that overlap in terms of request and data but have a different source of truth. In that case, I would still write multiple queries that can be written without a parameter. If you want, we can schedule a call to help you out in your project

[posva]

This can be achieved now with defineQueryOptions: https://pinia-colada.esm.dev/guide/queries.html#Organizing-Queries 🎉
In your specific case, you can use the query within a composable

You can do dynamic queries with keys too: https://pinia-colada.esm.dev/guide/query-keys.html#Typing-query-keys