-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Data: Refactor and optimize withSelect, withDispatch handling of registry change #11027
Conversation
const hasRegistryChanged = nextProps.registry !== this.props.registry; | ||
if ( hasRegistryChanged ) { | ||
this.unsubscribe(); | ||
this.subscribe( nextProps.registry ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like that we're doing this magic in shouldComponentUpdate
. It doesn't seem like the best function for this kind of side effects. Ideally it's componentWillReceiveProps
but this one has been deprecated, so not sure what's the "good" approach for these at the moment.
I see shouldComponentUpdate
as a function that can be called multiple times by React even without rendering (especially in async) as it's supposed to be a pure function just returning a boolean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My general approach with these components has been to happily throw out all best practices if it means performance could suffer even marginally in the individual case by following them.
If there's an unexpected behavior that could occur in how we're implementing (even "number of calls"), we should have a unit test to cover it in whatever fix need to be made.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 The e2e tests spoke for this :P
There's a small unit test breakage to fix and rebase
f14e050
to
39a7399
Compare
Pushed rebased branch. Including two issues to have been resolved:
|
This pull request seeks to refactor the implementations of
withSelect
andwithDispatch
to avoid dependency upon -- and thus enable the deprecation of -- theremountOnPropChange
higher-order component.A few notes as to the rationale:
remountOnPropChange
used broadly outside this specific context could serve as a "footgun", since it can have negative effects in focus loss (example)withSelect
andwithDispatch
are two of the hottest code paths, and as implemented prior to these changes would each have aremountOnPropChange
wrapperremountOnPropChange
wrapper forwithDispatch
is actually not necessary, due to its behavior of proxying function calls to resolveregistry.dispatch
only when the mapped prop is called.Testing Instructions:
This is a refactoring change. There should be no impact on usage.
Ensure unit tests pass: