Mention defineQuery in @tanstack/vue-query migration doc

[87xie]

In @tanstack/vue-query, reusable queries were often implemented using useQuery, like this:

const useTodosQuery = () => {
  return useQuery({
    queryKey: ['todos'],
    queryFn: () => fetch('/api/todos').then((res) => res.json()),
  })
}

In @pinia/colada, creating a regular composable via useQuery with an inline query and using it across different components may trigger the following warning:

The same query key ['todos'] was used with different query functions. This might lead to unexpected behavior.
See https://pinia-colada.esm.dev/guide/queries.html#Reusable-Queries for more information.

To avoid this issue, the migration guide could mention defineQuery as the recommended approach for defining reusable queries, like the example in Reusable Queries:

const useTodos = defineQuery({
  key: ['todos'],
  query: () => fetch('/api/todos').then((res) => res.json()),
})

Would it make sense to include this in the migration doc?

---

Additionally, I have a question regarding reusable queries that need to accept parameters from the components layer.
What is the recommended approach for this?

Currently, I am using something like this:

const useTodoQuery = (id: Ref<string>) => {
  return useQuery({
    key: () => ['todos', id.value],
    query: () => fetch(...)
  })
}

[posva]

Thanks for the suggestion, I added a note.

Regarding passing parameters: if they don't come from a global piece of state like the route or the store, you should use useQuery() within the component.

When using defineQuery(() => {}) the fn is executed only once, like setup stores in pinia

[87xie]

I have created a minimal reproducible example based on the scenario I frequently encounter.

The example is a user list paginated API integrated with a table interface. When a user clicks on the "Detail," "Edit," or "Order History" actions in a table row, a dialog displays the corresponding content.

I have created three subcomponents: UserDetail, UserEditing, and UserOrderHistory. The corresponding component is dynamically displayed based on the user's action type, with the userId from the table row passed as a prop. In subcomponent's setup, props.userId is passed to a custom query composable.

Extra information:

• My current project is built as a SPA using Nuxt.
• It references the custom $fetch recipe, creating a custom $fetch instance with a Nuxt plugin and getting the instance via useNuxtApp().

[posva]

Thanks! In this modal scenario, I would put the activeUserAction in either the history state, the route, or a store. That way the data would be global (which matches the UI). That said, I see how it could also be in an expanded section allowing multiple ones to be visible at the same time. I think there could be a version of defineQuery() that dynamically creates entries for parameters. Or maybe, make the warning more precise. I will try around a few things, thanks for the help with this.

[87xie]

Thanks for your suggestion!

In the scenarios I'm encountering, I usually need some state to be available within a specific component subtree, for example, I only need activeUserAction on the /users route and want to destroy (or reset) the state when switching pages. In this case, would you recommend creating multiple small stores on a per-feature basis and resetting the store when the top-level component unmounts?

[posva]

In that case, using a regular composable with useQuery() inside (and not defineQuery() because those are executed only once), should work (despite the warnings). There are cases where it could break, the first example in the Reusable queries is one of them. In Pinia Colada, each key defines a cache entry and is reused. This includes options like the query fn. This is made this way because I initially thought it makes no sense to define the same query (same key) multiple times with different options, so why not reuse them, save memory and avoid mistakes. This is why I added a warning but I think I need to make the warning more lax to fire less often or just remove it and add a section to docs.

[posva]

I created #192 to track this