-
Notifications
You must be signed in to change notification settings - Fork 52
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
Efficiency of Deep Equality Checks in Prop Updates? #7
Comments
You're correct, immutable data and shallow checks would be more efficient, however we decided to let consumers make their own decisions with respects to data immutability. In our uses of ReSub we have large amounts of immutable data (enforced by typescript compiler using readonly attributes) and have provided a custom comparator to detect when we're using immutable structures and do a shallow comparison. We left the ability for consumers of ReSub to provide their own callback for props and state equality checking, so you could choose to use a shallow comparator there. |
Could you add a special base class as a |
Can you possibly list some examples of these? I'm confused how a component that doesn't respond to props changes is supposed to work, or what its purpose would be. |
Any React component that is built on React.PureComponent will only update on a shallow property change comparison. This is common for components built to be used with a high level of data changes (e.g. real time dashboards etc..). It's a React best practice to use immutable data structures |
I made some changes in #96 that brings shouldComponentUpdate back to returning true (inline with React's guidance) |
I notice that by default ReSub does a deep equality check when properties are updated, rather than preferring immutability and shallow checks. Wouldn't it be more efficient to do the deep equality check in the store, and push immutable structures to PureComponents (i.e. deep check once at source, rather than in each consumer?).
The text was updated successfully, but these errors were encountered: