devtools in v3.13.0 causing a lot of updates slowing down page execution

[robherley]

Describe the bug
After upgrading from v2 (react-query-devtools@v2.5.1) to v3 (react-query/devtools@v3.13.0) devtools seem to cause an extreme amount of updates that slows code execution. This happens with the devtools when they are both in the opened and closed state.

To Reproduce
Steps to reproduce the behavior:

1. Render page with 50+ hooks in v2, start profile, update components, review profile.
2. Render page with 50+ hooks in v3, start profile, update components, review profile.

Expected behavior
Less component updates.

Screenshots
If applicable, add screenshots to help explain your problem.

Here are two tests I ran where I completed the same exact actions with the same number of queries and same data being fetched. One version was using react-query@v2.23.0 with react-query-devtools@v2.5.1 and the other is react-query@v3.13.0. The newer devtools have more updates, so much that it causes code execution on the page to halt.

v2:

v3:

Desktop (please complete the following information):

• OS: macOS
• Browser: Chrome
• Version: 89

Additional context

• Disabling the devtools fixes slow page execution
• "Worst" behavior is seen when multiple components with hooks are being unmounted/remounted

[TkDodo]

do you have a codesandbox that shows this behaviour?

maybe we just need to unmount the devtools when they are closed as described here: #1948

can you try that?

[robherley]

Sure, here's a comparison between the two versions:

v2: https://codesandbox.io/s/react-query2019-v2-n8s6n?file=/src/App.js
v3: https://codesandbox.io/s/react-query2019-v3-fv6pz?file=/src/App.js

If you mash the button, you can tell v3 locks the page. Unmounting devtools when closed would help the problem, but I don't believe it's the underlying cause. If you compare the behavior, v2 is not affected by this "lag".

[jhsu]

just a quick look, it seems like setUnsortedQueries gets called a bunch after any change and results in each calling the set state from useSafeState which schedules a bunch of updates after render (scheduleMicrotask) which results in a bunch of render -> state change -> render loops

[TkDodo]

one difference I'm seeing between the two examples is that in v2, the 100 queries still show up as stale when we hide them, while they are actually inactive. It seems that the devtools in v2 don't really receive the update - which explains why they are "fast" ;)

in v3, the subscribe code linked above is triggered:

• 100 times when we hide the query
• 100 times when the queries mount + another 100 times when they go from fetching to stale again

the updates that v3 receives are definitely correct. let's see if a simple memoization of the DevotolsPanel will solve the issue, because 99 of those 100 update don't really change anything in the view :)

[TkDodo]

This seems to be a death-by-1000 cuts situation. Every single re-render is already fast (takes under 1ms), but because there are so many updates from so many observers, there is a noticeable lag.

[TkDodo]

I made a PR that speeds-up the devtools while they are closed, so that at least perf is not affected in the closed state: #2045

[robherley]

Thanks for the PR, that'll help dev workflow for now and unblock migration to v3. But is there anything that can be done about the underlying issue? ie: you mentioned memoization, can that be utilized before sending the entire cache to setUnsortedQueries

[TkDodo]

can that be utilized before sending the entire cache to setUnsortedQueries

yes, that would be the goal. What I would like to do is:

• port the devtools to TypeScript. It is a .tsx file but there is a // @ts-nocheck annotation at the top, so it's really just the ported js version. I personally can't do much without types 😆 .
• don't put the whole unsortedQueries into the state. instead, when a subscription is triggered, compute what we need for the devtoolsPanel, something like a QueryView object. Then, we can do a deep or shallow equal check on that "view" and only call the local setState if something really changed. it should make sure that only updates are really triggered if something visible in the devtools changes.

What do you think?

[robherley]

Sounds great! I'm not super familiar with the inner workings of react-query, but I'll can help out if you need

[TkDodo]

thanks! let's try to get the open PR merged first to ease the pain, and then go from there :)

[tannerlinsley]

🎉 This issue has been resolved in version 3.13.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀