Select + setQueryData interaction

[aaron-manning]

I'm testing out react-query for a project and am confused about the interaction between optimistic updates and select.

From my testing, if I have a main query, like so

  const customer = useQuery(key, () => customerFetch(id))

And then do an optimistic update, eg from a successful mutation

customer.data.nameFirst = 'some new value'
appClient.setQueryData(key, customer.data) // note that this also doesn't work if a new object is returned.

And have another query, like the following, in another part of the application. It does not get triggered for re-render by setQueryData

   // using the same key as the first query. ['customer', 4] in this case.
  const customer = useQuery(key, () => customerFetch(id), {
    notifyOnChangeProps: 'tracked', // i tried various combinations. some work but completely ignore the select.
    select: (x) => x.nameFirst,
  })

I am only able to get the ability for 'select' to reduce re-renders when a refetch() is called. select is completely ignoring manually triggered updates called by setQueryData().

Is this by design or am i missing something?

Thanks

[TkDodo]

setQueryData triggers the same "update-chain" as a fetch would. From what I am seeing: you're mutating customer.data.firstName - not sure where customer is coming from. But if you call setQueryData with the same reference, it does nothing. Just like setState from react itself would do nothing.

From your comment, I would guess that you have tried immutable updates already, but it is still the most likely case of error. Note that if you only create a shallow new object, but then mutate firstName on data, it will still not work. Please try:

appClient.setQueryData({
  ...customer,
  data: {
    ...customer.data,
    nameFirst: 'some new value'
  }
})

Immutability is required when working in react. If that is too cumbersome, have look at libraries like immer

[aaron-manning]

It seems that when using select, the library must be doing something other than simply caching the most recent value (set during the last render) and equality comparing it against the new value to decide if a re-render should take place.

React-query must either traverse all the way up the object, checking for referential integrity at each step in order to determine a change, or it's not caching the last value at time of render and instead simply looking at the current value in the cache and comparing it to the new data.

Perhaps this decision has something to do with the 'structural sharing' design?

It's a shame to be forced down the immutable path if wanting to use select + optimistic updates, considering the rest of the framework appears to work fine with mutable objects.

[TkDodo]

I'm pretty sure it has nothing todo with select per se. If you do:

const data = queryClient.getQueryData('my-key')
data.foo.bar = true
queryClient.setQueryData('my-key', data)

it will also not work. This is in-line with how react works:

const [state, setState] = React.useState()

<button onClick={() => {
  state.foo.bar = true
  setState(state)
}})/>

this will also not trigger a re-render, because react internally uses Object.is for comparison, and you do pass in the same object reference.

[aaron-manning]

const data = queryClient.getQueryData('my-key')
data.foo.bar = true
queryClient.setQueryData('my-key', data)

This works if you don't use select. Subscribers to the query are re-rendered. Or at least it does when passing queryResult.data into setQueryData.

https://react-query.tanstack.com/guides/optimistic-updates

The docs don't reveal anything about requiring immutable data. It's not obvious that the function is a wrapper around useState (in which case it needs a new reference to trigger a render) or a custom implementation that will trigger a render regardless (and perhaps set some field in the returned query object that makes it clear that the data didn't actually update).

This is the source of my confusion, as it does seem to work similar to this, unless you add a select. At which point the only way to get a render is to do an immutable update.

Thanks for taking the time to discuss this.

[TkDodo]

it's not a wrapper around useState, it's just conceptually similar. You are right that setQueryData does indeed always inform subscribers when called, but I think this might change in v4. It might also change because we use tracked queries per default in v4.

Anyways, sorry if it's not clear from the docs. Please feel free to open a PR to improve the docs. Most state managers in react need immutable updates to work correctly, which is why immer is so popular I guess :)