Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Devtools V4: Where is Highlight Updates? #16437

Open
k3flo opened this issue Aug 17, 2019 · 24 comments

Comments

@k3flo
Copy link

commented Aug 17, 2019

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?

image

image

Version: 4.0.2 (8/15/2019)

@johannesmutter

This comment has been minimized.

Copy link

commented Aug 17, 2019

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

@gaearon

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2019

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

@apostolos

This comment has been minimized.

Copy link

commented Aug 17, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2019

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

This comment has been minimized.

Copy link

commented Aug 18, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 18, 2019

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

This comment has been minimized.

Copy link

commented Aug 19, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 19, 2019

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 comment has been minimized.

Copy link

commented Aug 21, 2019

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

This comment has been minimized.

Copy link

commented Aug 21, 2019

+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 totally fine like when we update Context).

@gaearon

This comment has been minimized.

Copy link
Member

commented Aug 21, 2019

+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

This comment has been minimized.

Copy link

commented Aug 22, 2019

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 comment has been minimized.

Copy link

commented Aug 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

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

This comment has been minimized.

Copy link

commented Aug 23, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2019

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

This comment has been minimized.

Copy link

commented Aug 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2019

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:
Video demonstrating profiler "why did this render?" feature

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

This comment has been minimized.

Copy link

commented Aug 26, 2019

@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

This comment has been minimized.

Copy link

commented Aug 29, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2019

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

This comment has been minimized.

Copy link

commented Sep 12, 2019

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

This comment has been minimized.

Copy link

commented Sep 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.