[DevTools] Make Element Inspection Feel Snappy

[sebmarkbage]

There's two problems. The biggest one is that it turns out that Chrome is throttling looping timers that we're using both while polling and for batching bridge traffic. This means that bridge traffic a lot of the time just slows down to 1 second at a time. No wonder it feels sluggish. The only solution is to not use timers for this.

Even when it doesn't like in Firefox the batching into 100ms still feels too sluggish.

The fix I use is to batch using a microtask instead so we can still batch multiple commands sent in a single event but we never artificially slow down an interaction.

I don't think we've reevaluated this for a long time since this was in the initial commit of DevTools to this repo. If it causes other issues we can follow up on those.

We really shouldn't use timers for debouncing and such. In fact, React itself recommends against it because we have a better technique with scheduling in Concurrent Mode. The correct way to implement this in the bridge is using a form of back-pressure where we don't keep sending messages until we get a message back and only send the last one that matters. E.g. when moving the cursor over a the elements tab we shouldn't let the backend one-by-one move the DOM node to each one we have ever passed. We should just move to the last one we're currently hovering over. But this can't be done at the bridge layer since it doesn't know if it's a last-one-wins or imperative operation where each one needs to be sent. It needs to be done higher. I'm not currently seeing any perf problems with this new approach but I'm curious on React Native or some thing. RN might need the back-pressure approach. That can be a follow up if we ever find a test case.

Finally, the other problem is that we use a Suspense boundary around the Element Inspection. Suspense boundaries are for things that are expected to take a long time to load. This shows a loading state immediately. To avoid flashing when it ends up being fast, React throttles the reveal to 200ms. This means that we take a minimum of 200ms to show the props. The way to show fast async data in React is using a Transition (either using startTransition or useDeferredValue). This lets the old value remaining in place while we're loading the next one.

We already implement this using inspectedElementID which is the async one. It would be more idiomatic to implement this with useDeferredValue rather than the reducer we have now but same principle. We were just using the wrong ID in a few places so when it synchronously updated they suspended. So I just made them use the inspectedElementID instead.

Then I can simply remove the Suspense boundary. Now the selection updates in the tree view synchronously and the sidebar lags a frame or two but it feels instant. It doesn't flash to white between which is key.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 1, 2024 1:59am

[sebmarkbage]

This is an unfortunate hack. I couldn't figure out how to mock this without rewriting all the tests. In particular all the sync one needs to move to async ones.

That's because React itself also uses queueMicrotask and the tests don't expect that those are mocked as a timer, but they expect that the bridge is mocked as a timer.

[sebmarkbage]

Now that we don't have the outer Suspense boundary the inner ones that are used around the "View Source" related buttons show up more prominently because the <Skeleton> loading state is a bit too aggressive. It should be much more faded.

It also takes 200ms for the same reason. It could be useful for something like source mapping to use a <Suspense> but really everything should be fast enough to not use Suspense boundaries. We could also remove those boundaries too and just let the Transition stall for the time it takes to compute those. They're actually fast.

[hoxyq]

I've tested this with React Native, works great. Thanks!

[eps1lon]

Sweet

[sophiebits]

this is awesome