Feature Request: Expose queryKey and ability to manage setQueryData from UseQueryResult and UseInfiniteQueryResult

[magicqiang]

Problem

Currently the only way to update the query cache is through queryClient

queryClient.setQueryData(queryKey, newData)

but it is often inconvenient to reconstruct queryKey from the place where we want to update the cache.

A contrived example can be as following

// usePosts.ts
const getUseQueryKey = ({category, tags}) => ['posts', cateogry, tags];
const usePosts = ({category, tags}) => useQuery(getUseQueryKey({category, tags}), () => fetch()...)


// App.tsx
const postsRes = usePosts({category: 'foo', tags: ['bar']})

function removePost(id) {
// here I need to reconstruct the query key using `getUseQueryKey`, 
// and it getting worse if this function is used in deeper child,
// because we need pass down the queryKey to the child.
  queryClient.setQueryData(getUseQueryKey({category: 'foo', tags: ['bar']}) , prevData.filter(d => d.id !== id))
}

Proposal

It would be great if UseQueryResult and UseInfiniteQueryResult can expose the queryKey and setQueryData method. so that instead of above, I can directly do

// App.tsx
const postsRes = usePosts({category: 'foo', tags: ['bar']})

function removePost(id) {
  postsRes.setQueryData(prevData.filter(d => d.id !== id))
// or 
  queryClient.setQueryData(postsRes.queryKey, prevData.filter(d => d.id !== id)
}

Let me know if it makes sense, thx!

[TkDodo]

This has been asked a lot before, but I'm still hesitant because while a typed setData function sounds nice in theory, in practice, you will often not call setQueryData in the same function where you have the useQuery.

The only place where it makes sense to call setQueryData is in mutations, either for optimistic updates, or after you get a response back. If you follow the recommendation to create custom hooks, you'll wind up with:

const { data } = usePosts() // custom query hook
const { mutate } = useUpdatePost() // custom mutation hook

Even if the mutation lives in the same component as the query, which it often will not, you will have to pass setData from usePosts to useUpdatePost to be able to invoke it there. At this point, you can just as well call queryClient.setQueryData, can you not?

[magicqiang]

in practice, you will often not call setQueryData in the same function where you have the useQuery.

I think we do sometimes, and sometimes we need a lot of properties from UseQueryResult, and we just pass the UseQueryResult to some child component for isLoading, refetch, data.

I think exposing queryKey and setData is similar to the pattern where const unsub = subscribe('foo', handler). Where you can directly unsubscribe by interacting what returned from subscribe like unsub().

without providing this, it would be similar to pubsub.unsubscribe('foo', handler) I need to to provider handler to where this unsubscribe will happen.

In general, I think it makes sense that the returned entity can manipulate its data in more convenient way, wdyt. And any drawbacks for providing it anyway? I couldn't think of any

[TkDodo]

And any drawbacks for providing it anyway? I couldn't think of any

I ran a poll on twitter. The drawbacks are an increased api surface, and encouraging writes to the cache directly, which we don't really want to do. As proven by some comments, this would further give the impression that it's okay to use react-query for anything else than async state, like:

const { data, setData } = useQuery({ queryKey: ['some-state'], initialData: 0, staleTime: Infinity })

<button onClick={() => setData(prev => prev + 1)}>{data}, inc</button>

look, I don't need an extra state manager, react-query can now do fully typed setState as well. Not a good idea, for various reasons...

[magicqiang]

I slightly disagree that not exposing it in order to prevent people to abuse it. Update the cache data is essential to snappy UI experience especially when dealing with async. The purpose of this is already implemented via queryClient.setQueryData, but it's just a bit inconvenient to use in some conditions.

I'm afraid I need to do some workaround for my usage,

function usePosts({category, tags}:{category: string, tags: string[]}) {
  const key = generateKey(category, tags)
  const queryClient = useQueryClient()
  const setData = (data: Post[]) => queryClient.setQueryData(key, data);

 const res = useQuery(...)
 return {
   ...res,
  setData
 }
}

it works great for me so far.