Fix potential flaw in pure Higher Order Component#7654
Conversation
|
@youknowriad I've assigned to you for initial look as I discovered from blame that you primarily implemented this as a part of (#6313). I see the impetus for adding this was for wrapping Anyways, just thought I'd run this by you (I kinda "hope" its invalid, if so, I can rework the pull to simply update the documentation). |
|
Actually nvm, after thinking about it, it looks like this is expected behaviour (and the test I wrote is behaving as expected in this case). |
Description
While working on #7557 I realized that the pure higher order component could lead to some potentially unexpected results when used with
compose. I decided to document this possible flaw with a unit test and create this pull. I say "possible" because it actually may already be a known thing and it just is my misunderstanding of howpureis intended to function.Currently
pureexamines the prototype of the incomingWrappedcomponent and if the prototype is a class component it extends it so that a shallow compare ofstatecan be used to determine whether a component is re-rendered. Otherwise it only results in a shallow compare of just props.Now if the expectation is that when pure is used in compose (as the left most function), that the original component does not re-render on shallow compares of state (i.e.
MyCompin the test I added), then it's fine as is and there's no bug. However if the expectation is that the original component DOES re-render on shallow compares of state then this is a bug. Also this could just be a usability thing that the developer would have to be aware of when using pure with compose.I'm only bringing this to your attention in "case" its not something you're already aware of as it could lead to some unexpected wrapped component behaviour if you're not.
How has this been tested?
Checklist: