Devtools V4: Where is Highlight Updates?

[k3flo]

If I understood correctly, this is the correct repository for devtools v4, right?

I just noticed that react devtool were updated. I'm missing the "Highlight Updates" function.
How can I activate it?

Version: 4.0.2 (8/15/2019)

[johannesmutter]

Same issue here. Highlight Updates has gone.
I was wondering if one has to use Profiler now, to track updates?

[gaearon]

https://www.reddit.com/r/reactjs/comments/cqx554/introducing_the_new_react_devtools/ex1r9nb/

The honest answer is we didn't quite have the time to implement it, and didn't consider it important enough to block all the other features from releasing.

However, there's deeper reasons why we're not sure we'd be adding it back. It contributes to the wrong idea that re-renders by themselves are bad (they're not if they're cheap). So people spend time optimizing useless things and missing actual performance issues.

The new DevTools includes a Profiler that should help you find actual performance problems in your code. I understand the desire for a super lightweight way to find extra renders — and maybe we'll add that — but we'll need to think more about how it should work first.

Edited to add inline comment

[bvaughn]

Some related previous discussion bvaughn/react-devtools-experimental#244

[apostolos]

Highlight Updates was very useful not that much for fixing performance problems (the new Profiler is much better at that), but to discover surprising renders. It has saved us countless of times especially when working with Context where one change may cause re-renders in other parts of the app. When working on the Profiler you tend to focus on only a part of the tree, so regressions are easy to miss.

I understand @gaearon 's concerns about giving the wrong idea, so how about:

1. Choose outline color based on render duration

Cheap renders should be green, expensive renders should be yellow or red. Or just use the exact same colors used by the Profiler.

2. Vary outline fade speed

Outline fade animation should be relative to render duration. Fast renders should fade immediately, slow renders should fade more slowly.

3. Differentiate repainted areas

I sometimes used Highlight Updates with Chrome's Paint Flashing. This made renders that led to repaint to be highlighted differently than renders that had no DOM effect. I think DevTools should have a similar function built-in.

• An expensive render with no repaints should be the primary target for performance optimizations.
• Renders that repaint are obviously doing some work that needs to be done.
• Fast renders that result to no repaint are OK to ignore.

Maybe even have a setting that only flashes the first of the above (with some configurable threshold).

[bvaughn]

Identifying a "cheap" or "fast" render is not as straight forward as it seems, because of factors like:

• Development builds are much slower than production builds.
• Developer laptops are generally much faster than end user laptops.

The nice thing about the Profiler is that it reports speed as relative, letting you focus on the slowest part of an application in any given session. (You get to decide when the slowest part is fast enough.) This can only be done in retrospect though.

It also gives you a static snapshot of the commits, and which props/state changed, letting you see not only how often a particular component rendered (was it more than you expected?) but also specifically why it re-rendered, and what else re-rendered with it.

I think there's a good chance we might look at adding some kind of update flashing mechanism back to DevTools as part of Profiler. Maybe it flashes (like it used to) only when profiling is active? Maybe it flashes every component that re-rendered when you select a new commit in the profiler after profiling has stopped? (I kind of like that idea, since it lets you "replay" if you missed something.) We need to experiment with it a bit and see what works best.

[adenflorian]

I used this feature a lot to make sure that only the components that should be rendering were being rendered. I have an app that renders the same component, many times, with different id's, and I like to make sure that only the one that needs to rerender is rendering, rather than all of them. I don't see a way to check this with the new profiler.

[gaearon]

I don't see a way to check this with the new profiler

What have you tried? The profiler should clearly show whether one child is re-rendering or many.

[jaapster]

I was using 'Highlight updates' frequently. It was the feature of dev-tools that I used the most. Just to see what was updated, not how often. Sure, you can use the profiler to do this but that is considerably more cumbersome than having a quick visual indication.

For me, "Highlight updates" was the "killer feature" ...

[gaearon]

We hear you :-) I don't think further comments just saying "I used this" are going to significantly help in this thread, for what it's worth. We know there are people using this feature, and are thinking what would be the right way to bring it back. Thanks for feedback!

[kmpkt]

This option was an essential component for my daily working process to indicate rerender issue instantly. So i would be really glad, if you can bring this awesome feature back soon.