Expose setData from useQuery

[damianstasik]

While working on some stuff I needed to do a query data update after a mutation, so I followed an example from the documentation, but I felt like it could be simplified.

Take a look at the example from the docs:

const queryClient = useQueryClient()

const mutation = useMutation({
  mutationFn: editTodo,
  onSuccess: data => {
    queryClient.setQueryData(['todo', { id: 5 }], data)
  }
})

mutation.mutate({
  id: 5,
  name: 'Do the laundry',
})

// The query below will be updated with the response from the
// successful mutation
const { status, data, error } = useQuery({
  queryKey: ['todo', { id: 5 }],
  queryFn: fetchTodoById,
})

And here is my proposition:

// The query below will be updated with the response from the
// successful mutation
const { status, data, error, setData } = useQuery({
  queryKey: ['todo', { id: 5 }],
  queryFn: fetchTodoById,
})

const mutation = useMutation({
  mutationFn: editTodo,
  onSuccess: data => {
    setData(data)
  }
})

mutation.mutate({
  id: 5,
  name: 'Do the laundry',
})

As you can see an instance of Query Client is no longer needed as setData is directly accessible from useQuery. You also do not need to pass any key as setData would be bound to a query. Another bonus is proper typing out of the box, as queryClient.setQueryData does not know anything about query type by default.

What do you think?

[TkDodo]

yeah, we've discussed this before somewhere. proper typings is the biggest approach for this solution. However, one thing I'm unsure is the actual use-case: You don't really have a useQuery and a useMutation in the same component, or even directly in the component, in a real app. The preferred approach is to create custom hooks. So then you need to take the setData function that your custom hook returns and pass it to your custom mutation hook:

const useTodo = (id) => useQuery(...)
const useUpdateTodo = (setData) => useMutation({ mutationFn, onSuccess: setData })

function MyComponent() {
  const { data, setData } = useQuery(...)
  const { mutate } = useUpdateTodo(setData)
}

not sure if that would be easy to type, or if that would be better than calling queryClient.setQueryData. Keys need to be "managed" somehow for invalidation.

This gets worse if the mutation lives in a different component than the query, which is often the case for more complex uis where they are split up in different component. One List component to display the data that does the query, and one Actions component that renders some buttons and has the mutations.

I'm not opposed to adding this though, just want to understand the rationale apart from a todo-list example :) trpc also has a strictly typed setData function and I like that a lot.

[Lesik]

After using React Query in our project for about two years, in my humble opinion the lack of typing on getQueryData/setQueryData is the main drawback of React Query, therefore this discussion piqued my interest.

I agree with @TkDodo that exposing setData from useQuery would be awkward to use if query and mutation live in different components, which is almost always the case. And since useQuery is a hook, you cannot call it from inside the mutation, so e.g. the following is impossible:

// queries.ts

const useTodo = (id: number) => useQuery({
  queryKey: ["todo", id],
  queryFn: () => { ... },
});

// mutations.ts

const useUpdateTodo = (id: number) => useMutation({
  mutationFn: () => { ... },
  onSuccess: (data) => {
    const { setData } = useTodo(id); // won't work
    setData(data);
  },
});

One could make the setData function a parameter to the useUpdateTodo function, as shown in the code snippet from @TkDodo above, but that decouples the mutation from the query (one could pass an arbitrary setData, for example from useComment() instead of useTodo()) which would defeat the purpose.

---

Alternatively, since useUpdateTodo() is a hook, one could call useTodo() to retrieve setData inside there:

const useUpdateTodo = (id: number) => {
  const { setData } = useTodo(id);

  return useMutation({
    mutationFn: () => { ... },
    onSuccess: (data) => setData(data),
  });
};

However, one problem I can see with this approach is that the call to useTodo() (and thus useQuery()) immediately sets off the fetching of data (result in a network request), which is not desirable since one only wanted to set the data. Perhaps another hook such as useQueryInfo() could be provided that returns information about the query such as setData, getData, queryKey etc. but would not set off the fetching like useQuery() would. @TkDodo thoughts?

---

I've also been experimenting with ideas to define queries just as a UseQueryOptions object instead of hooks, so that you can easily access their fields even if you aren't inside a hook or component:

const todoQuery = (id: number): UseQueryOptions<Todo, Error, Todo, string[]> => ({
  queryKey: ["todo", id],
  queryFn: () => { ... },
});

That way, one can both easily call the useQuery() hook with that todoQuery, as well as use it inside a mutation:

// MyComponent.tsx

const { data, isLoading } = useQuery(todoQuery(props.todoId));

// mutations.ts

function setDataSafely<
  TQueryFnData = unknown,
  TError = unknown,
  TData = TQueryFnData,
  TQueryKey extends QueryKey = QueryKey
>(
  options: UseQueryOptions<TQueryFnData, TError, TData, TQueryKey>,
  data: TData
) {
  return queryClient.setQueryData<TData>(options.queryKey!, data);
}

const updateTodo = (id: number): UseMutationOptions<UpdateTodoResponse, Error, number, unknown> => ({
  mutationFn: () => { ... },
  onSuccess: (data) => {
    setQueryDataSafely(todoQuery(id), data); // will work
    setQueryDataSafely(todoQuery(id), { foo: "bar" }); // will not work
  },
});

While this approach is nice because you can extract things like queryKey, it has strong shortcomings, such as having to use the queryClient through import (as opposed to useQueryClient() hook) and the general inability to call hooks, such as useToast() to display a success message after the mutation completed.

[TkDodo]

calling useQuery just to retrieve setData is, as you said, suboptimal because it creates an Observer, and that might trigger a refetch. Even if it doesn't, you still have an Observer and that is some overhead.

A function useQueryInfo wouldn't be helpful because how would it know the types? useQuery knows the types because you pass the queryFn in. So useQueryInfo would also need the queryFn to determine it's ReturnType, which also doesn't sound great.

---

I like the todoQuery approach - I'm also using that in the react-router example, as the whole query object can be used for prefetching as well. We've even tried to get a PR to accept all options into setQueryData so that the approach you mentioned just works with getQueryData / setQueryData, but it didn't work out:

• Feature/extended filters get query data #4190

if you're looking for a type-safe solution, trpc or zodios are the way to go imo. They know everything because of the upfront route definition and can then create completely typesafe hooks + helper functions.

[Lesik]

You're right that useQueryInfo wouldn't work. I also agree that the approach of writing queries as a POJO seems the most versatile. Other libraries also seem to be heading in that direction, such as in React Router 6 declaring routes as objects as opposed to JSX in version 5. RTK Query also defines queries in an object.

However, I think losing the ability to call hooks in e.g. onSuccess in a POJO query declaration is quite a detriment to the integration with React, since hooks are very commonly used for query side effects. Other use cases could be retrieving an API key from a context or global store using a hook inside the queryFn. Perhaps there is some trick that could run the onSuccess function as if it was inside a component, so that hooks can be called inside it? Apart from that, the outcome of #4190 seems to suggest that making setQueryData work with the full query definition object is rather non-trivial, so we're almost back to zero.

As for trpc and zodios, in my opinion one of the biggest strengths of React Query is its versatility - the fact that queryFn can return any Promise<T> makes it stand out among similar libraries such as RTK Query (HTTP-focused) or Apollo (GraphQL-focused). If to use React Query typesafely one would be limited to a NodeJS backend, that would be a loss.

Therefore I'm very interested in continuing to iterate on this one or other approaches to increase type safety in React Query. Perhaps to achieve that, more conceptual changes to React Query will be required, for example for the v5 release, that increase type safety while maintaining the dynamic non-centralized nature of the useQuery hook which makes React Query so elegant, simple and versatile. I'm open for an extended discussion to determine the best way to accomplish that should anybody else be interested in that. (At this point I'm probably derailing this ticket a bit, should start a new discussion.)

[Rafay78]

I am trying to use setData now is it removed from tanstack ?