Skip to content

Fix potential flaw in pure Higher Order Component#7654

Closed
nerrad wants to merge 1 commit intomasterfrom
fix/potential-flaw-in-pure
Closed

Fix potential flaw in pure Higher Order Component#7654
nerrad wants to merge 1 commit intomasterfrom
fix/potential-flaw-in-pure

Conversation

@nerrad
Copy link
Copy Markdown
Contributor

@nerrad nerrad commented Jul 1, 2018

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 how pure is intended to function.

Currently pure examines the prototype of the incoming Wrapped component and if the prototype is a class component it extends it so that a shallow compare of state can 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. MyComp in 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?

  • see unit test demonstrating the potential concern.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@nerrad nerrad added [Type] Bug An existing feature does not function as intended [Package] Element /packages/element labels Jul 1, 2018
@nerrad nerrad assigned youknowriad and unassigned gziolo Jul 1, 2018
@nerrad
Copy link
Copy Markdown
Contributor Author

nerrad commented Jul 1, 2018

@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 withSelect and withDispatch HOCs and it appears that the expectation is only "they" are made "pure" (irregardless of what the original component being wrapped by the composed HOCs is). In this case its appears that the expected behaviour for pure is it only wraps and affects its immediate fed component. If so then this pull is invalid and its just something that maybe should be documented as the expectation when using pure as a part of a composed HOC.

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).

@nerrad
Copy link
Copy Markdown
Contributor Author

nerrad commented Jul 1, 2018

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).

@nerrad nerrad closed this Jul 1, 2018
@aduth aduth deleted the fix/potential-flaw-in-pure branch January 25, 2019 21:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Package] Element /packages/element [Type] Bug An existing feature does not function as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants