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.

[therealparmesh]

+1 on bringing back some version of this feature that enables a quick high-level view of re-renders - even for re-renders that are a result of when we update context.

[gaearon]

+1 on bringing back

So i would be really glad, if you can bring this awesome feature back soon.

As requested above:

I don't think further comments just saying "I used this" are going to significantly help

To rephrase this more explicitly:

We hear you! But if more "+1" comments are posted, we might have to lock this thread.

There are many people subscribed to this repository. We don't want to spam them with the same comments every few hours. Additionally, we personally use GitHub notifications. If this thread gets bumped every day with a "+1", we'll eventually have to unsubscribe from it to reduce the noise. Which is likely the opposite of your intention.

Before commenting, please make sure that you're adding something that wasn't said before. If you see a similar comment to what you wanted to write, just add a 👍 reaction to it instead.

Thanks for understanding.
We appreciate your feedback but 👍s are enough to help prioritize tasks.

[Carduelis]

that you're adding something that wasn't said before.

I'd like to ask, is there a way to install the previous version of the extension? Actually, the update broke the flow, that I used to. Unfortunately, Chrome extension marketplace does not allow you to install the previous version like 'npm'. Do you have a link with compiled extension? Thank you.
(I tried to install standalone version, but this link from v3 repo is broken, link to Crome extension leads to the newest version)

The new DevTools includes a Profiler that should help you find actual performance problems in your code.

And here is an answer, why the new extension broke my flow. Profiler encourages you to press buttons to start, then to end profiling, but it is not instant. With updates highlighter, you see everything without extra moves. It also shows you in a very intuitive way the actual updates, and what actually has been triggered.

[dwelle]

This reminds me of Chrome DevTools's own performance monitor which also used to be live-updating and then someday was migrated to press-to-record . That move probably made sense because of complexity and impact on performance, but the point is that it adds enormous friction (as @Carduelis points out, it's way easier not to press start/stop buttons). It throws a wrench into the OODA loop, and no doubt will affect how often users use this feature, and in turn affect the quality of the app itself.

Don't take this the wrong way --- the new perf monitor is cool and has its uses when you need to dig deep, but it can't simply replace the quick & dirty visualizations like the old update highlighting.

[bvaughn]

I'd like to ask, is there a way to install the previous version of the extension?

@Carduelis Installation instructions for the previous version of DevTools are covered in the release blog post: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how-do-i-get-the-old-version-back

[oztune]

I ran in circles a bit trying to get v3 installed in Chrome from the instructions above, and just couldn't get the standalone profiler to highlight changes. So I made detailed step-by-step instructions if you just want to get it working and get back to optimizing your components:

Installing React Dev Tools V3 (step-by-step instructions):
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

If I may rant a bit, while on a technical level it may seem like "in-depth profiling tools" > "a silly highlighting feature", we are all just humans and we glean a lot of information quickly from simple visual cues, so in some ways the highlighting feature is a pretty big deal exactly for the reason that it's so easy to use. For me it's the reason I open React Dev Tools 90% of the time.

[bvaughn]

If I may rant a bit, while on a technical level it may seem like "in-depth profiling tools" > "a silly highlighting feature", we are all just humans and we glean a lot of information quickly from simple visual cues, so in some ways the highlighting feature is a pretty big deal exactly for the reason that it's so easy to use.

I don't think Dan or I have debated that it's "easier to use", just that it might encourage people to invest time in "fixing" things that aren't "broken" (aka over optimizing things that aren't slow). We've seen this pattern before with things like widespread avoidance of inline functions because of feared "performance" costs. Energy invested in fixing non-problems is energy that isn't spent fixing other potentially more important things.

As we said above, I think there's a good chance we might add some kind of update flashing mechanism back to DevTools as part of Profiler.

Realistically it's not the highest priority thing on my plate though so I'm going to ask for patience rather than repeating this conversation. We hear and acknowledge that this feature is important. We will try to weigh convenience against the other considerations mentioned above and come up with something more than what we currently have.

[brandonkal]

To the point about over-optimizing I can attest that the visual render highlighting can encourage that. Therefore, I'd like to add something to the discussion here.

For those who miss the feature, you may find https://github.com/welldone-software/why-did-you-render more informative.

This may be something to consider when this feature is implemented. By default, WhyDidYouRender does a deep value comparison and only reports when things didn't actually change between re-renders. It would be great to have this same filtering on the visual render highlights. This would direct more thoughtful optimizations (plus it is a distinction not afforded by the profiler).

In theory it should be possible to rerender the entire app without performance concern so adding SCU everywhere to avoid seeing the render highlighting is a counterproductive path.

I still found the rerender highlight useful for demonstrations on how React works.

[bvaughn]

By default, WhyDidYouRender does a deep value comparison and only reports when things didn't actually change between re-renders.

This sounds super slow for apps that actually have performance problems. Any kind of deep comparison is certainly not something we'd want to always do. At the point when you're turning it on (to opt into slower perf) then why not just start the Profiler?

This would direct more thoughtful optimizations (plus it is a distinction not afforded by the profiler).

The Profiler does provide a version of this:

If you see a component that re-rendered, but didn't have any changed props/state/hooks, that's what you're describing I think.

[brandonkal]

@bvaughn Well you generally only turn on the deep comparison on a single component at a time. So I agree it's not something you'd turn on for all components by default. Perhaps something where You right click that green bar and select "highlight render updates".
That is pretty slick and super useful, but it is something you have to dig for.

[evbo]

@bvaughn I love the "Why did this render?" feature (in the interim while Highlight Updates gets re-thought), but after reading all available documentation and skimming your youtube tutorial, I'm still not certain how to interpret it for a few cases:

Not intuitive what the underscore means:

Why did this render?

• props changed: (__)

I only use the hooks api, but still not certain of the meaning:

Why did this render?

• Hooks changed

Any chance of there being a sentence or two explanation for these cases and maybe others I have yet to encounter besides the obvious case where it lists actual props/state that changed?

[bvaughn]

Not intuitive what the underscore means:

Looks like something in your app is passing in a prop named __ and that prop is changing between commits 😄

I only use the hooks api, but still not certain of the meaning

Please see #16477

[PMustard]

Hi

I was using Highlight Updates a lot. I'm developing a frequently refreshing app and that future was essential for me for my day to day work.

I get the solution that @bvaughn presented. It's super useful but I can't apply it to my scenario couse of the refresh rate. I need a quick indication rather than profiling tool, which looks awesome BTW.

Are you still going to implement this back?? If not how can I downgrade my React Dev Tools, cause I simply can't develop without it.

[kmpkt]

Are you still going to implement this back?? If not how can I downgrade my React Dev Tools, cause I simply can't develop without it.

Already answered by @oztune.

How do I get the old version back?
https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how-do-i-get-the-old-version-back

[TinaHeiligers]

I want the old version back please. There's so much functionality that was lost in the new one and it's impossibly unhelpful

[einarq]

I want the old version back please. There's so much functionality that was lost in the new one and it's impossibly unhelpful

Here's how to get the old version back, worked for me:
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

[PMustard]

HI @einarq actually I would love to have missing functionality in the new Version. I see a lot of nice new things but some of the old ones ware crucial and I do not get it the way it was removed. To check rerenders now I put a console log in render function to spot if I'm reducing a number of rerenders or not. It's not ideal but it works. The previous version was making this ridiculously easy and helpfull cause it also shows me other unneeded rerenders that I could spot. Now, this is just painful.

Please put those missing functionalities back to the new version.

In my word new Version means that you have: redesign and improvements of the older one and new futures added in. Not removed and added new functionality that is different than the previous one.

Also why I cant now change state values ??

And props Booleans are not checkboxes anymore ?? That was so cool. And Again gone.

Now state cant be change and props I have to type that false/true in instead just click and see how a component is reacting to this.

Super annoying.

[einarq]

Hi @PMustard,

I don't work on this, I was just suggesting one potential approach to bring back the old version of the dev-tools if you don't like the new one. It worked for me.

I'm sure that the team working on the dev-tools (mainly Brian Vaughn I guess?) would take your concerns into consideration if you create some separate issues for them.

And don't forget to show some appreciation as well. We are getting these tools for free :)
Constructive feedback only.

Regards,

Einar

[gaearon]

If you urgently need this feature, you can use an old version as a workaround: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how-do-i-get-the-old-version-back. I also encourage you to try using the Profiler. Even though it’s a bit more effort to run, it tells you which re-renders are important and which are not. Just counting render numbers is often a distraction from actual performance issues.

We understand that having a light way to spot unexpected rerenders is valuable. We’ve explained in #16437 (comment) that this is on our radar and that more comments saying “I need this” aren’t helpful. Since this thread has nevertheless continued gathering “I need this” comments, I’m going to lock it to reduce the notification flood. Please rest assured your voice is heard.

[bvaughn]

I have implemented this feature in the new DevTools (#16989) with the following caveats:

• It is only enabled in the browser extension (and react-devtools-inline NPM package) for now, so it only supports React DOM.
• It is not implemented for legacy renderers (v15) although it could be added by someone if they wanted to submit a follow up PR.

[bvaughn]

Closing this issue now that #16989 is landing. Will likely release 4.2 with the new feature today.

[XerDemo]

Look , it`s here.