types for setQueryData

[ducin]

Within the

https://github.com/tannerlinsley/react-query/blob/26b39546cc1f37a3fff1e43515b65e640f532ad6/src/core/queryClient.ts#L125-L129

signature, this line doesn't seems to falsely claim the cached value might be undefined:

https://github.com/tannerlinsley/react-query/blob/26b39546cc1f37a3fff1e43515b65e640f532ad6/src/core/queryClient.ts#L127

Let's say I have an API endpoint which always returns an object, like a config or translations pack, whatever. It's always an object (never undefined). Question: why does the signature enforce widening to T | undefined?

Similar concept is used in react useState, where - in case no initial value is passed, the type is widened with undefined. Though, there's a reason for doing so (value is undefined initially, because no initial was passed).

Maybe I'm missing something, but in case of setQueryData that's not the case.

[TkDodo]

Question: why does the signature enforce widening to T | undefined?

simple scenario: A query can be in error state and you can still call setQueryData on that query. In those cases, you will be handed undefined, that's why the types reflect that.

The real problem is that you cannot return undefined. In v4, we've adapted the functionality and the typings are now:

 updater: Updater<TData | undefined, TData | undefined>, 

so if you get undefined, you can just return undefined to bail out of state updates:

• v4 docs
• breaking change in v4

[ducin]

Many thanks for the response.

I had one more doubt, but I found the answer myself:

https://github.com/tannerlinsley/react-query/blob/26b39546cc1f37a3fff1e43515b65e640f532ad6/src/core/query.ts#L250

I can run setQueryData on pretty much any query, whatever its status is (success, error, loading, idle, etc). If it turns out I was in error state and I set data, arbitrarily the new status is success, which indeed makes sense.

[TkDodo]

Yes, it puts the query in success state, and if it doesn't exist at all, it will be created. That's another case for undefined input: the query can be non-existent.
and in v4, you can just return undefined to bail out and the query will not be created.

[ducin]

BTW I see what you meant here:

The real problem is that you cannot return undefined

In current v3, if I have:

      queryClient.setQueryData<Employee[]>(['employees', 'list'], (employees) => {
        return employees!.filter(e => e.id !== id)
      })

is there anything better than not null assertion (employees!)? Let's suppose it's a post-successful-remove-item-from-the-list-mutation, after an item is removed from the list, we don't do a list hard reload: update query by filtering out the removed id.

• it's kinda wrong anyway, because the employees might not be here (as you explained above)
• but the types force me to return T 😢

The least bad solution I can think of is to assume that if the mutation is successful, then the query had to be in success state which allows me to claim that employees are non-undefined, hence !. But yes, it's convoluted as hell - yet TS won't compile otherwise 😢 .

[TkDodo]

I just do:

const employees = queryClient.getQueryData<Employee[]>(['employees', 'list'])
if (employees) {
  queryClient.setQueryData<Employee[]>(['employees', 'list'], employees.filter(e => e.id !== id))
}

a bit manual but the best way in v3 imo. will be better in v4 :)

[ducin]

ah, right, it's a better one indeed!