-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Does "Trace React Updates" respect shouldComponentUpdate short-circuits? #337
Comments
you're right -- it's confusing. If you want to add a section to the Readme about this (maybe under FAQ) that would be great! To actually fix this problem, we'd probably need to make a change to react core, perhaps making |
Sure, I'll add a section to the FAQ about this. |
I think it would be very nice if this was an accurate indication of updates, since it's such a visual way of verifying performance. Will React v15 make this easier/harder? |
don't think v15 will change this -- but as I said above, I don't believe it would be too much of a change to support this |
Well, it goes pretty deep but indeed it looks like it might be doable. What is the best way to get this in v15? |
Given that v15 has an rc out, I don't imagine this would make it in as it's not a bugfix, but it won't be a breaking change so I'm sure it could get into 15.0.1 or 15.1 (depending on how they want to version it). If you want to take a whack at it, go ahead and open a PR to react and tag me in it |
Potentially relevant: facebook/react#6068 |
Definitely! Very good idea. |
Does this mean that the visual indicators over-represent what's actually being re-rendered? If so, how can their output be trusted/utilized effectively? |
It can’t. Unfortunately the feature was added without consideration for this. |
(We totally should fix it in the future. Maybe after Fiber is out.) |
This was fixed in React 16. |
Indeed it was fixed 🎉 |
It looks to me as if
shouldComponentUpdate
checks counts as an update in the devtools.Even if a component return false on
sCU
it will flash as updated. Child components of a falsysCU
won't flash, suggesting thatsCU
is probably not tracing renders per-se but thecomponentWillReceiveProps
part of the lifecycle.Here's a codepen to see what I'm talking about: http://codepen.io/stipsan/pen/grbaEr
With "Trace React Updates" flipped on I'd expect the first input to flash itself and its parent when you change the value. The second input guard itself with a
sCU
for its local state.But it flashes, suggesting the
sCU
returned true when it actually returned false.If the second input is changed, it'll only update its local state and the devtools will show a trace for just the second input, just as you'd expect.
If this is the intended behavior, then it should be much more clear so that lesser experienced devs isn't mislead into thinking pure components are rendering when they aren't.
The text was updated successfully, but these errors were encountered: