I want to check all properties and state if they are changed, return true if any changed and make a base component for all my root components.
I'm wondering if it won't be the best practice and make my components slow.
Also, what I did always returns true:
shouldComponentUpdate: function(newProps, newState) {
if (newState == this.state && this.props == newProps) {
console.log('false');
return false;
}
console.log('true');
return true;
},
Is there anything wrong with my code?
Should I check for every variable inside props and state?
Won't check for objects inside them make it slow depending on their size?
It is considered best practice to compare props and state in shouldComponentUpdate to determine whether or not you should re-render your component.
As for why it's always evaluating to true, I believe your if statement isn't performing a deep object comparison and is registering your previous and current props and state as different objects.
I don't know why you want to check every field in both objects anyway because React won't even try to re-render the component if the props or state hasn't changed so the very fact the shouldComponentUpdate method was called means something MUST have changed. shouldComponentUpdate is much better implemented to check maybe a few props or state for changes and decide whether to re-render based on that.
I think there's a problem in most of the tutorials I've seen (including the official docs) in the way that stores are accessed. Usually what I see is something like this:
// MyStore.js
var _data = {};
var MyStore = merge(EventEmitter.prototype, {
get: function() {
return _data;
},
...
});
When I used this pattern, I found that the newProps and newState in functions like shouldComponentUpdate always evaluate as equal to this.props and this.state. I think the reason is that the store is returning a direct reference to its mutable _data object.
In my case the problem was solved by returning a copy of _data rather than the object itself, like so:
get: function() {
return JSON.parse(JSON.stringify(_data));
},
So I'd say check your stores and make sure you're not returning any direct references to their private data object.
There is a helper function to do the comparison efficiently.
var shallowCompare = require('react-addons-shallow-compare');
export class SampleComponent extends React.Component {
shouldComponentUpdate(nextProps, nextState) {
return shallowCompare(this, nextProps, nextState);
}
render() {
return <div className={this.props.className}>foo</div>;
}
}
Related
Using React and Redux, imagine you have a component method that sends a request to an external API.
import React, { Component } from 'react';
import { connect } from 'react-redux';
class MyComp extends Component {
boolUpdate (val) {
fetch('http://myapi.com/bool', { val });
}
shouldComponentUpdate (nextProps) {
return false;
}
render () {
return <h1>Hello</h1>;
}
}
const mapStateToProps = ({ bool }) => ({ bool });
export default connect(mapStateToProps)(MyComp);
Now let's say that you want to invoke boolUpdate() each time the bool prop changes, but this should not trigger a component update because nothing in the render of the component is affected.
What's the best way to do this in React?
Until recently people used to do something like:
componentWillReceiveProps (nextProps) {
if (nextProps.bool !== this.props.bool) this.boolUpdate(nextProps.bool);
}
But as of React v16.3 componentWillReceiveProps() has been deprecated. In this example we can't use componentDidUpdate() either, because shouldComponentUpdate() prevents that from happening. And getDerivedStateFromProps() is a static method, so it doesn't have access to the instance methods.
So, the only option we're left with seems to be using shouldComponentUpdate() itself. Something along the lines of:
shouldComponentUpdate (nextProps) {
if (nextProps.bool !== this.props.bool) this.boolUpdate(nextProps.bool);
return false;
}
This looks rather "hacky" to me though, and not what shouldComponentUpdate() was designed for.
Does anybody have a better pattern to suggest?
Is there a preferred way to listen to specific prop changes and trigger component methods?
Thanks!
If you want to run some code (e.g. data fetching) when props change, do it in componentDidUpdate.
componentDidUpdate(prevProps) {
if (prevProps.id !== this.props.id) {
this.fetchData();
}
}
In your example, this won't work because shouldComponentUpdate returns false. I'd argue this is not a very common case because typically you still want to re-render if props change.
For example, if the user ID changes, you might want to show a loading indicator while the data for the new user is loading. So avoiding a re-render is not very useful in this case.
However, if you're absolutely sure you both need to prevent a re-render and need to perform a side effect like fetching data on props change, you can split your component in two. The outer component would do the data fetching in componentDidUpdate, and return <InnerComponent {...this.props} />. The inner component would have a shouldComponentUpdate implementation that prevents re-rendering further. Again, I wouldn't expect this to be a common scenario, but you can do this.
Based on the React docs and this discussion on github, The place to fetch new data based on props change is actually componentDidUpdate.
The rendering was actually splitted to two phases, the Render Phase which is pure and creates no side effects and the Commit Phase which can run side effects, work with the DOM and schedule updates.
You can see that explained well in Dan Abramov's diagram:
Dan also mentioned:
People used to mix these two different things in
componentWillReceiveProps, which is why we have to split it into a
pure method (getDerivedStateFromProps) and an existing impure one
where it’s okay to do side effects (componentDidUpdate).
And for the solution itself, Im attaching the example from the docs:
Fetching external data when props change
Here is an example of a component that fetches external data based on props values:
Before:
componentDidMount() {
this._loadAsyncData(this.props.id);
}
componentWillReceiveProps(nextProps) {
if (nextProps.id !== this.props.id) {
this.setState({externalData: null});
this._loadAsyncData(nextProps.id);
}
}
After:
static getDerivedStateFromProps(nextProps, prevState) {
if (nextProps.id !== prevState.prevId) {
return {
externalData: null,
prevId: nextProps.id,
};
}
return null;
}
componentDidMount() {
this._loadAsyncData(this.props.id);
}
componentDidUpdate(prevProps, prevState) {
if (this.state.externalData === null) {
this._loadAsyncData(this.props.id);
}
}
My understanding was that PureComponent leverages shouldComponentUpdate() and does a shallow comparison of state and props but I created a little example that operates differently than I expected.
The example app displays a list of people. Each list item has the ability to change its name. Try it out and inspect the code here.
In the parent component, I have a method that looks like this:
updateName(id, newName) {
const { people } = this.state
const idx = people.findIndex(person => person.id === id)
people[idx].name = newName
this.setState({ people })
}
The object that I'm passing back into setState has the same reference as the previous object. In this case, shouldn't this component not update if it's doing a shallow comparison?
Secondly, another part that's unclear, I changed the child component Person from PureComponent to Component and I'm still getting the benefit of only the child that was updated re-rendering (I'm doing a console log on each child render if you want to inspect that). Clearly this is something that React is doing internally to decide for the child whether it should update but I assumed that if the component was re-rendering it would re-render everything.
shouldn't this component not update if it's doing a shallow comparison?
Yep. And it isn't updating. You can see that the App component's render() method does not get called again after the initial render. This means the shallow comparison is working as you expect and the component is (correctly) not updating.
I believe the part that's throwing you off is this line in Person.prototype.handleSubmit():
this.setState({ value: '' })
Since oldState.value !== newState.value, this will trigger a re-render on the modified Person component, regardless of whether Person is a PureComponent or not.
If you take this line out, you will see that nothing updates (the behavior you're expecting).
Clearly this is something that React is doing internally to decide for the child whether it should update.
Nope, the child is setting its own state. The parent-child relationship is irrelevant here. React will update the child directly.
In the future you should try isolating your tests. The reason this confusion occurred is because you were relying on the render() method to determine whether a child received new props. But the render() method is called when a child receives new props AND when a child sets new state.
A better test for this situation would have been checking whether componentWillReceiveProps() is called, thus eliminating state from the picture:
componentWillReceiveProps(newProps) {
console.log('receiving props', newProps)
}
If you plug this into the Person component, you will see that it does not get called. Exactly as you're expecting.
In short, React.PureComponent works exactly as you were thinking.
What is the best place to store the result of an expensive calculation from the React props which I use in render() but do not want to execute at each render() ?
constructor(props) {
super(props)
const result = this.doExpensiveCalculation(props)
}
componentWillReceiveProps(nextProps) {
// if nextProps differ from props
const result = this.doExpensiveCalculation(nextProps)
}
doExpensiveCalculation(props) {
// Some expensive stuff
}
render(){
// Use doExpensiveCalculation(this.props) here
}
The options are this and state but both I see rather unsatisfying. Is there a ready solution which uses memoisation?
On the other hand, should I worry about optimizing this ? I read that React can rerender component even if the props have not changed but does this happen often ?
You can handle the re-rendering in the lifecycle method of shouldComponentUpdate. Default value is always return true. By returning false there React will not re-render the component.
See the docs for more. Besides that, React only updates if a state change occurs since props are read-only.
Your options are to store it as you suggested or have a class with a static field to keep it there.
If all you want to do is perform the expensive calculation whenever you get new props, instead of on every render, you probably want componentWillReceiveProps:
componentWillReceiveProps() is invoked before a mounted component receives new props.
As far as where to store them, you can either store them in state, or as a property directly on the component instance. Either will work just as well.
You want to make sure compare values though, to avoid unnecessarily recomputing.
For example:
componentWillReceiveProps(nextProps) {
if (nextProps.someValue !== this.props.someValue) {
this.someResult = this.performExpensiveCalculation(nextProps.someValue);
}
}
I'm trying to understand something about react and would like to get thoughts on the better way to do it.
Basically, I want to do some transformations/calculations on incoming props. I have limited event based state changes currently, but that may change in the future. Basically, is it better to do these calculations in render, or in componentWillMount and componentWillReceiveProps and set state?
in render example:
render() {
var url = this.getUrl() // get url transforms some props into a valid url
var something = this.getSomething() // etc etc
return <a href={url}>{something}</a>
}
outside of render:
componentWillMount() {
this._checkAndSetUrl(this.getUrl(this.props.data));
},
componentWillReceiveProps(nextProps) {
const currentGivenUrl = this._getUrl(this.props.data)
const nextGivenUrl = this._getUrl(nextProps.data)
if (currentGivenUrl !== nextGivenUrl) {
this._checkAndSetUrl(nextGivenUrl);
}
},
_checkAndSetUrl(url) {
// check validity and do some stuff to url
url = "new url"
something = this.getSomething()
this.setState({url: url, something: something})
}
My thinking is the second way is better because you don't do the calculations on every render, only when things are changed. What's the accepted way to do this?
Just for simplicity and readability you should keep them in render, and implement shouldComponentUpdate:
shouldComponentUpdate: function(nextProps, nextState) {
// TODO: return whether or not current chat thread is
// different to former one. this.props refers to the 'old' props.
}
If you return false from shouldComponentUpdate, render will not be called again. If this.props.data === nextProps.data you can probably return false.
It avoids you keeping around unnecessary state, and is readable. If you want to make the checks more granular you can split up your url and something into different components, with their own shouldComponentUpdate.
For more information, see https://facebook.github.io/react/docs/advanced-performance.html
I am unclear about the use of this.state in React components. While I can create this.state.myvar, why should not I just create this.myvar?
class MyComponent extends Component {
state = {myvar: 123};
render() {
return <span>{this.state.myvar}</span>;
}
}
or
class MyComponent extends Component {
myvar = 123;
render() {
return <span>{this.myvar}</span>;
}
}
I realize that there are helpers like this.setState, but at the end this.state is just a convenience, right? Or does it play a bigger role in React? Should I avoid setting properties directly on this to store my state? If so, why?
No, in fact; rather wrong.
this.state in a react component is a special React-backed container that is only acknowledged as having been updated when you use setState, which triggers a re-render, which might cause DOM updates (or not, depending on what React's diff algorithm sees happening in the JS virtual dom).
You can, of course, also use object properties bound to this, but changing them does absolutely nothing for the component itself. React doesn't look at your full component instance for changes, it only looks (internally) at the state, and (when changed by parents) at the props.
As such, you can't "create" things like this.state.myvar and then expect them to actually exist from lifecycle function to lifecycle function: as a special management construct, any values you tack onto state outside of proper this.setState(...) calls have undefined behaviour. They might exist, or they might not. If you really are working with the internal state, then you need to signal changes via this.setState({ myvar: value }).
Of course, that doesn't mean you can't use this.myvar, that'll work fine, but changing it will not "do" anything other than literally just that.
When would you use this.val instead of state? When your component has to perform operations that lead to an "intermediate" state, neither being one renderable state, nor the next. For instance, when code can update a state value multiple times between renders, during those changes your component is in an intermediate state, and so you don't want it to re-render. In fact, expecting it to can lead to huge bugs:
...
doTest() {
this.setState({ val: this.state.val+1 });
this.setState({ val: this.state.val+1 });
this.setState({ val: this.state.val+1 });
},
...
This code will not yield a this.state.val that's 3 higher than before, because state updates are queued, and overwrite each other. Only the last instruction before a re-render "wins". So in that case you'd need something like:
...
doTest() {
var localval = this.state.val;
localval++;
localval++;
localval++;
this.setState({ val: localval });
},
...
And then if we also need that value accessible outside of this function, then we finally have a legitimate use for a this property:
...
doTest() {
this.accessibleval = this.state.val;
this.updateValueAFewTimes();
this.setState({ val: this.accessibleval });
},
...
this.state plays a larger role than you realize.
Setting state via this.setState triggers the component to re-render (among other things). Otherwise, React would have no way of knowing when something it depends on changed.