-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
static propTypes = { | ||
style: PropTypes.object.isRequired, |
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.
Care to explain why we are passing this in while it is available on context?
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.
This is just to not re-compute the background from the given seed for each render (it's computed once, at least while the seed isn't changing, by the Redux mapStateToProps
method.)
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.
Couldn't it just have been done in componentWillMount
?
I think the single calculation is great, just concerned about "special cases" where we start doing things inconsistently.
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.
Doing it in componentWillMount
would mean that it won't update on seed
update. This could be done however in componentWillReceiveProps
but it means it's linked to the state.
So we'd have to choose whether to do it in the component or have a state-less component with props managed by Redux. Not sure which is the best practice. Performance wise, it's kind of the same (if done correctly, ie. implementing shouldComponentUpdate
if not state-less)
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.
So we'd have to choose whether to do it in the component or have a state-less component with props managed by Redux.
A general note:
Both Redux & Mobx encourage users to split React components into "dumb"/presentational and "smart"/behavioural. We'd have a smart component connecting the store/state to the React components tree and lots of "dumb", pure components beneath.
However, memoizing the background computation and returning a value that can be checked for equality by React should work in terms of performance.
CI tests still seems to have issues, will get back to this once recovered. |
Yep, |
Related to #3240
Mainly pre-render accounts list so the click on the Accounts tab instantaneously render something instead of waiting for all the accounts to be rendered.
Smarter Account Summary Component and better tabs (used to be rendered around 30 times whenever the tabs switched).
Also added React Perf in dev mode : in JS console:
Perf.start()
Perf.stop()
Perf.printWasted()
This will show in a table all the useless re-renders.