Skip to content
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

Closed
joewood opened this issue Apr 8, 2017 · 5 comments
Closed

Efficiency of Deep Equality Checks in Prop Updates? #7

joewood opened this issue Apr 8, 2017 · 5 comments

Comments

@joewood
Copy link

joewood commented Apr 8, 2017

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

@berickson1
Copy link
Collaborator

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.
import ReSubOptions from 'resub/dist/src/Options'; ReSubOptions.shouldComponentUpdateComparator = ReSubOptions.shouldComponentUpdateComparator = <T extends {}>(a: T, b:T ): boolean => { // Custom equality logic goes here return true }

@joewood
Copy link
Author

joewood commented Apr 10, 2017

Could you add a special base class as a PureComponent? The problem with mutating state is that there are many community components that are optimized to not update through mutated prop changes. I think this is one of the reasons why the reducer approach in redux has become popular.

@ms-deregtd
Copy link
Contributor

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.

@joewood
Copy link
Author

joewood commented Apr 20, 2017

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

@berickson1
Copy link
Collaborator

I made some changes in #96 that brings shouldComponentUpdate back to returning true (inline with React's guidance)
If you want a proxy for React.PureComponent you can implement a custom comparator that does a shallow comparison of props and state. You can either apply this globally to all components or utilize the decorator with custom comparator as seen in #96

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants