render optimization with proxies

[TkDodo]

Since v3, we now have notifyOnChangeProps so that we can optimize our renders by only "subscribing" to certain changes, e.g.:

function User() {
const { data } = useQuery('user', fetchUser, {
notifyOnChangeProps: ['data'],
})
return <div>Username: {data.username}</div>
}

This component will only re-render if the data changes, and because of the structural sharing feature, this will only happen if we really get new data from the server.

This is nice and comes in very handy if your render is expensive, because every background refetch will lead to 2 re-renders per default (switching to isFetching: true and then again to isFetching: false).

It is however a quite manual approach to specifying what you want to subscribe to, and you have to keep it in-sync with what you are really using - it would be really cool if this could be tracked automatically!

Proxies offer such a way, for example, react-tracked works that way.

I have no experience with proxies, but I imagine keeping track of what was accessed via a get interceptor, which would then just fill our notifyOnChangeProps might be reasonable to implement. If we don't want to force proxies on users, it could be a separate hook, and the above example could become:

function User() {
const { data } = useTrackedQuery('user', fetchUser)
return <div>Username: {data.username}</div>
}

it would only re-render if data changes because that's what we access, and if we further access status or error, we would also subscribe to these changes. I think this would be a nice optimization because most components don't need the latest updatedAt timestamp or isFetching property, which is what's mostly causing re-renders during background refetches.

What do you think?

[tannerlinsley]

This would be awesome. I wonder if @dai-shi would be willing to help us out.

[dai-shi]

In my opinion, if this requirement is just about shallow properties like data only, it is fairly easy to implement with bare Proxy.

If you want to support nested properties like data.foo, things are very complicated. React-Tracked since v1.6 supports creating a tracked selector for react-redux and zustand. It would be super easy if RQ expose useSelector-like interface. I would personally suggest this path, especially if the default RQ behavior is kept the same without proxies.

[TkDodo]

I think shallow would be enough. It’s not so much about deep data, but about the other properties returned by useQuery: if you don’t need isFetching, why re-render when you do a background refetch...

if you only want data.foo, you can use a selector-like option:

const { data } = useQuery(
'key',
queryFn,
{
select: data => data.foo
}
)

I don’t really see the need to automize this, especially if it’s not easy :)

[dai-shi]

you can use a selector-like option

Oh, do you already have select option? Does it prevent re-render if selector function returns a referentially same object?

Ah, it only works for data part. Would have been easy if it worked for the return value of useQuery.

[TkDodo]

Does it prevent re-render if selector function returns a referentially same object?

yes it does, but yeah, as you’ve said, only for the data part - everything else will always be the same structure.

[TkDodo]

I made a first draft here: #1578