Devtools are re-rerendering constantly on every cache update even when closed

[pristas-peter]

Describe the bug

We are encountering performance issues with the app when using devtools with many queries (around 1000). We are using normalised cache keys, when for example fetch of list items updates data in each single fetch query via setQueryData.

However in v4, by using useSyncExternalStore things got really slow (app freezes for a short time when doing updates).

Is it possible to update devtools by batches, or is it even necessary to "observe" every query when the devtools are closed?

Your minimal, reproducible example

Steps to reproduce

Expected behavior

How often does this bug happen?

No response

Screenshots or Videos

No response

Platform

react-query version

v4 3.2.1

TypeScript version

4.7.4

Additional context

No response

[TkDodo]

Please provide a codesandbox reproduction!
By using useSyncExternalStore, we actually fixed a perf issue in the devtools:

• speedup devtools #2742 (comment)

[pristas-peter]

Hi, check it out here:
https://codesandbox.io/s/suspicious-jasper-xh7k88?file=/src/App.js

Try to scroll beyond 500 items or so, the app will become un-responsible.
If you comment out react query devtools component, all is smooth.

This was not happening in react-query 3.

Thanks for checking it out.

[TkDodo]

i can confirm that this is not how it should be :)

Given that it gets worse with the number of queries, my best guess is that all uSES subscriptions are being triggered to re-render even though they should not. We've switched to fine-grained subscriptions because they are supposed to be more performant. Before that, every update would re-render the whole devtools, which is why we had the workaround of not subscribing at all when the devtools are closed.

I see a couple of ways forward:

1. re-add the workaround that we removed in speedup devtools #2742. Basically, render null when the devtools are closed. That would be a quick win, and probably not wrong because why would we subscribe to anything if we are closed. However, app would still lag with open devtools.
2. investigate what re-renders so often and why, and stop those re-renders.
3. if the renders are not coming from uSES subscriptions themselves but from top-down renders, we could try memoizing each query row. But I don't think that's the case.

I'm afraid I won't have much time to look into this right now. Would you like to contribute any of those steps @pristas-peter ?

[pristas-peter]

Yes, I will try to take a look at it next week

[dhirajarun]

i can confirm that this is not how it should be :)

Given that it gets worse with the number of queries, my best guess is that all uSES subscriptions are being triggered to re-render even though they should not. We've switched to fine-grained subscriptions because they are supposed to be more performant. Before that, every update would re-render the whole devtools, which is why we had the workaround of not subscribing at all when the devtools are closed.

I see a couple of ways forward:

1. re-add the workaround that we removed in speedup devtools #2742. Basically, render null when the devtools are closed. That would be a quick win, and probably not wrong because why would we subscribe to anything if we are closed. However, app would still lag with open devtools.
2. investigate what re-renders so often and why, and stop those re-renders.
3. if the renders are not coming from uSES subscriptions themselves but from top-down renders, we could try memoizing each query row. But I don't think that's the case.

I'm afraid I won't have much time to look into this right now. Would you like to contribute any of those steps @pristas-peter ?

Hey @TkDodo, Can I work on this?

[TkDodo]

I am not working on it and I don't know if @pristas-peter is doing anything, so yeah, go ahead 🚀

[dhirajarun]

cool

[pristas-peter]

Sorry guys, I was little busy this week as well. @dhrjarun if you find out something, let us know 💯

[dhirajarun]

sure @pristas-peter