React: React DevTools: Display whether render was unnecessary

[kentcdodds]

It would be nice if the React DevTools gave some indication that the render didn't result in a commit or side effect callback and was therefore unnecessary. It's possible that I'm missing something on the nuance here that makes this more challenging than practical.

[OlegLustenko]

Pretty sure you already known about package,
https://github.com/welldone-software/why-did-you-render

The most I'm afraid of, devs might want to to optimize unnecessary updates and look for recepts. But it could be not always necessary. I would say it's challenging in terms of clear requirements and recommendations

[bvaughn]

What would this indicator look like? The concept of a render doesn't really exist in DevTools, except perhaps for the Profiler- although that's focused on commits rather than renders. Is there something new you think the Profiler should do? (What's missing from the current Profiler UI in this regard?)

A render might happen without any resulting mutations. Hopefully in that case it would be fast b'c it would bail out without deeply re-rendering the tree. I assume this request is primarily thinking about how to avoid the wasted cycles from such a render.

There are other reasons as render might not get committed too though. React might also toss out a render because of an error or a higher priority interrupt- or maybe it might be pre-rendering something at idle priority that doesn't end up getting used.

[kentcdodds]

Hopefully in that case it would be fast b'c it would bail out without deeply re-rendering the tree.

Unfortunately, if people aren't careful about how they compose things, then can end up re-rendering the entire tree starting from the app component.

As far as how it would look, I think having some sort of note on the right panel:

And the learn more could be a short article explaining what triggers a render of a component and explaining that it can be the source of performance bottlenecks in some situations.

[kentcdodds]

On top of that, maybe there could be some sort of indicator that sums up the amount of time spent on unnecessary renders.

And I think that this would exclude anything that was unnecessary thanks to concurrent mode dropping a render.

[eps1lon]

And I think that this would exclude anything that was unnecessary thanks to concurrent mode dropping a render.

I think what Brian was trying to say is that a dropped render might not be something "bad" in the sense of that a user can do something about it. Even worse: it might not be deterministic.

While it's certainly interesting to know if a render was dropped it might lead users down a rabbit hole where they try to prevent dropped renders that are out of their control.

[kentcdodds]

I agree. If it's not deterministic or actionable then that would make this feature request DOA. But I'm not sure of a situation that applies. This is assuming that React has some mechanism to communicate to the DevTools when a render is dropped. I think this is the case because the only thing that shows up in the DevTools is commits. So what would be left there would be to identify all components that were rendered and then tag the ones which were rendered but did not trigger DOM updates or side-effect callbacks.

[gaearon]

The bigger problem is that IMO this feature wouldn't be practically useful in most cases. E.g. if we render <div onClick={() => {}) /> there is no way tell whether this was "useful" because we don't know if that click handler closes over some props/state or not. Sure, we updated it, but we don't know if we had to. And I think most cases where you needlessly re-render do lead to eventual event handler changes. Needless top-down re-renders that don't result in any event handler changes are very rare.

[kentcdodds]

Ah yes, that's a very good point @gaearon 👍 Thanks!