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]

The main reason I wanted to create custom query composables is to reduce the need for manually declaring keys. I’m following the pattern outlined in the Effective React Query Keys, which recommends:

• Keeping query keys close to their respective queries
• Usually exporting only custom composables

Here’s an example:

const todoKeys = {
  all: ['todos'],
  list: ['todos', 'list'],
  detail: (id) => [...todoKeys.all, id],
}

export const useTodosQuery = defineQuery({
  key: todoKeys.list,
  query: fetchTodos,
})

export const useTodoQuery = (id: Ref<string>) => {
  return useQuery({
    key: () => todoKeys.detail(id.value),
    query: () => fetchTodo(id.value),
  })
}

export const useCreateTodoMutation = () => {
  const queryCache = useQueryCache()

  return useMutation({
    mutate: createTodo,
    onSettled: () => {
      queryCache.invalidateQueries({ key: todoKeys.list })
    },
  })
}

This approach works well, but I’m encountering the following warning: "The same query key with different query functions"

I’m unsure about the recommended way to avoid this warning, if there’s an alternative approach that works well with Pina Colada, I’d love to hear your thoughts.

Thanks in advance for your time!

[posva]

Exporting and reusing objects works too. Things depends on where your id comes from in

export const useTodoQuery = (id: Ref<string>) => {
  return useQuery({
    key: () => todoKeys.detail(id.value),
    query: () => fetchTodo(id.value),
  })
}

If it's from a component, then you can put that into the component but in practice, this id should come from global state, ideally from the route, in that case you write:

defineQuery(() => {
  const route = useRoute()
  return useQuery({
	key: () => todoKeys.detail(route.params.id),
    query: () => fetchTodo(route.params.id),
  })
})

The warning itself doesn't always matter, it's a good practice because queries with the same key should be defined only once and reused to ensure the same options are passed.

I'm interested in a more complete example that requires a parameter rather than a global state. It's something that has popped up a few times already and I want to know if it's something that should be handled or if it's an anti-pattern

[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?