I wanted to know the real use case on when to use PureComponent over Component in React? What is truly the difference between the two besides the fact that PureComponent implements shouldComponentUpdate method with shallow state checking. What is the true purpose of this API
Thanks
You've kind of answered the question yourself. React.Component will always update if you haven't implemented a shouldComponentUpdate (even if the state is shallowly equal).
React.PureComponent will not not update following a shallow state check (assuming the state and props remained the same). So if you want to prevent unnecessary updates and don't want to have to implement your own shouldComponentUpdate function, then use PureComponent to help save boilerplate.
Related
I need to know what is the meaning of shallow comparison when using PureComponent. Actually I read some treats but I could not understand the meaning of that so please simplify it.
An other question is, when we could use PureComponent and when using shouldComponentUpdate?
About Shallow Comparison you can check this answer
https://stackoverflow.com/questions/36084515/how-does-shallow-compare-work-in-react#:~:text=Shallow%20compare%20is%20efficient%20way,you%20don't%20mutate%20data.&text=shallow%20comparison%20is%20when%20the,comparisons%20deeper%20into%20the%20properties.
About shouldComponentUpdate [https://en.reactjs.org/docs/react-component.html#shouldcomponentupdate]
Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior.
Basically, the component will be re-render every single change of state, if you want to prevent it, you can use the shouldComponentUpdate().
About PureComponent[https://blog.logrocket.com/pure-functional-components-in-react-16-6/]
A React component can be considered pure if it renders the same output for the same state and props. For class components like this, React provides the PureComponent base class. Class components that extend the React.PureComponent class are treated as pure components.
I do strong recommend you to read about React Hooks[https://en.reactjs.org/docs/hooks-intro.html] It makes easy to have PureComponents and to control when and how it should be re-render.
Regards.
They say we can improve the performance of React app by using React.PureComponent in some cases, because it shallow compares its props before updating the component.
https://reactjs.org/docs/react-api.html#reactpurecomponent
On the other hand, react-redux's mapStateToProps uses shallow comparison when it decides whether we need to update the component.
https://redux.js.org/faq/reactredux#why-is-my-component-re-rendering-too-often
So, can I say I do not need React.PureComponent when its props are from react-redux connect, and it has no state? Or is there any difference between them?
As long as your component receives all its props from Redux and all changes to state can be recognized with a shallow comparison, you can use regular Component to the same effect as PureComponent. Just make sure when you update the state you don't mutate it, but instead return a new copy of the state. Immutable.JS is extremely helpful for this.
If I define a PureComponent that
only has a render() method, and
does not use this.state,
...is it effectively identical to a stateless functional component? Or are there any differences in behaviour or performance?
This is not a duplicate of React functional stateless component, PureComponent, Component; what are the differences and when should we use what? because the answer to my question is not contained there, at least not in a way that's easy to pinpoint. That is a big, wide-ranging question, and mine is very specific.
A stateless functional component is effectively identical to React.Component without lifecycle methods and state, not to React.PureComponent.
The whole point of React.PureComponent is to use one of the life cycle methods (shouldComponentUpdate) and make it to return true only if properties & state have changed, using shallow comparison.
There is no way how to do that in stateless functional components since they are always rendered and have no way to define shouldComponentUpdate.
This behavior is described in detail in Optimizing Performance.
According to the docs, React.Component doesn't implement shouldComponentUpdate ?
So how about a lifecycle of a component (the-component-lifecycle) (shouldcomponentupdate) ?
React.PureComponent is similar to React.Component. The difference
between them is that React.Component doesn’t implement
shouldComponentUpdate(), but React.PureComponent implements it with a
shallow prop and state comparison.
By default, using Component, shouldComponentUpdate returns true (no diffing of props happens), unless its defined by you (result dependent of what you put in). Using PureComponent react does a shallow diff of props by default.
Feel free to take a look at the react source code, roughly, it checks if shouldComponentUpdate is defined and is a function. Then checks if it is a pure component, then returns true by default.
https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberClassComponent.js
I have been reading the React docs and came across shouldComponentUpdate(). My understanding is that everytime setState() is called, a re-render of that component will be updated.
My question is that If the value to be updated is the SAME as the current state value, would this trigger a re-render event? or I would have to manually checks for the current value and value to be updated in shouldComponentUpdate()
The official React documentation states:
The default behavior is to re-render on every state change...
https://reactjs.org/docs/react-component.html#shouldcomponentupdate
This means that by default, render() will be executed if any of a component's state or props values changes.
You can override this default behavior using shouldComponentUpdate(). Here's an example that only updates if a state value changes.
shouldComponentUpdate(nextProps, nextState) {
return this.state.someValue !== nextState.someValue;
}
Note: this example completely ignores props. So, any changes to props will not trigger render().
Adding more to #Jyothi's answer regarding implementing shouldComponentUpdate() to skip unnecessary re-renders, in React 15.3 they introduced a new concept PureComponent. From reactjs docs
The difference between them is that React.Component doesn’t implement
shouldComponentUpdate(), but React.PureComponent implements it with a
shallow prop and state comparison.
This allows to skip unnecessary calls of render in class components by just implementing PureComponent instead of the usual Component. There are a few caveats with PureComponent though, from the docs about React.PureComponent’s shouldComponentUpdate():
... only shallowly compares
the objects. If these contain complex data structures, it may produce
false-negatives for deeper differences.
... skips prop updates for the whole component subtree. Make sure all the
children components are also “pure”.
Usage of PureComponent can in some cases improve performance of your app. Moreover, it enforces you to keep state and props objects as simple as possible or even better, immutable, which might help simplify the app structure and make it cleaner.
I dont know if I understood your question correctly but react only re renders when there is difference between virtual dom and real dom.
And as Jyothi mentioned in his answer that render method will be called irrespective of the value passed in the set state function but rerendering will depend on what this render method returns.
In functional components, calling setState() with the equal value won't cause a rendering, while in a class component it does: https://dev.to/sunflower/reactjs-if-it-is-setting-a-state-with-the-same-value-will-the-component-be-re-rendered-5g24
Note that we're just talking about virtual (React) renderings here. Brower-rendering won't happen in any case - i.e. neither in the functional component nor in the class component - as long as the state (or to be more precise: the effective DOM) doesn't change.