There are two steps of what we may call "render":

Virtual DOM render: when render method called it returns a new virtual dom structure of the component. As I mentioned before, this render method called always when yor make setState(), because shouldComponentUpdate always returns true be default. So, by default, there is no optimisation here in React.

Native DOM render: React changes real DOM nodes in your browser only if they were changed in the Virtual DOM and as little as needed - this is that great React's feature which optimizes real DOM mutation and makes React fast.

Ref: https://stackoverflow.com/q...

So I suppose the native DOM doesn't get updated in your first example. If so, is the re-render still expensive?

Yes. Its is still expensive in larger applications, where the virtual DOM changes would trigger diffing process. Diffing process is where the virtual DOM is checked with real DOM for the reconciliation process. Though there is no repaint, there is still diffing cost+virtual DOM creation cost involved.

Wont a component also re-render when it receives new props?

Components only re-render when the state changes, so a component won't re-render unless you update the state when it receives new props.

Ur gender

shaikfaraz no but

As explained in the article components will, by default, re-render when they receive new props, unless you return false from shouldComponentUpdate.

How is this true? How are the functional components get re-rendered then, if they have no state but only props?

Say we are sending data to a functional component via props. If there is change in the props values, the func component gets re-rendered again.

Really good article on shouldComponentUpdate()

okay but if it rerenders all components when only a specific components gets updated , then whats the point ? its just doing the same :/ , with/without a virtual dom

okay but if it rerenders all components when only a specific components gets updated , then whats the point ? its just doing the same :/ , with/without a native dom

Great Article, thanks a lot!! Keep writing! :)

I have one question :
Suppose i have a list lets say of 10 elements which are currently in state which causes a render of that list, now i am updating list by 20 elements which has start elements as it is and added new 10 elements so my question is react re-render only last updated 10 elements on UI or render all over the list?

It depends. React will do the less update if you have following things done.
1. Assigned a unique key as a prop to each of the elements.
2. Try to implement the shouldComponentUpdate(Or simple extends the PureComponent instead of Component)

Here is a demo: https://codesandbox.io/s/re...

Recommend resources:
https://reactjs.org/docs/re...

But rather than making a bunch of extra code by filling the shouldComponentUpdate method, shouldn't you really make a strong effort to never store non-UI properties in this.state and instead, hold them in any other property of the class like any other framework?

I haven't been using React for very long, but it's been my understanding that for simple data passing that has nothing to do with UI work, you should just reference your Redux store.

Yes. shouldComponentUpdate every-time is bit annoying and its not recommended all the time. Instead if you are using redux, you can stop it at the mapStateToProps function.

React does kinda already account for example #1, although maybe they could make it a bit clearer. Buried in the middle of their State and Lifecycle documentation at https://reactjs.org/docs/st... they say, "If you don’t use something in render(), it shouldn’t be in the state."

After that I guess they leave it up to the developer to decide if they want to include extra data in the state and just take the performance hit or specify when to re-render.

Absolute must-read for anyone wanting to go to production with React! IMO the main take-away is this sentence: "Unfortunately, by default React is incredibly simplistic and basically re-renders everything all the time." - and that most React developers actually don't know that.

Aw, thanks! Glad you found it useful :)

"Returning false does not prevent child components from re-rendering when their state changes." in the future :v. Actually shouldComponentUpdate has 2 parameter: nextProps and nextState

Really nice article.

Thank You for posting. V. useful

Nice article, isn't it better to store the whole state separately and use pure functions instead? Then by passing in only the necessary props avoid the whole componentShouldUpdate checks? (And as a plus you can get rid of the whole 'class' - thing ;-) )

I'd add to Hassan's reply by also mentioning that there are no performance benefits to implementing functional stateless components in contrast to stateless class-based components.

i.e.

const FuncComponent = ({ some, props, here}) => <fancymarkup/>

and

class ClassicalComponent extends Component {
render () {
return <fancymarkup/>
}
}

Perform identically the same. In Fact, the ClassicalComponent can implement ShouldComponentUpdate and eliminate any unnecessary re-renders. So if you have a big app with many stateless functional components you might actually see performance gains by refactoring your functional components to be class-based and then implement shouldComponentUpdate.

A component sometimes need it's own internal state in order to make it truly reusable and encapsulated. Consider two instances of a "Counter" component. Having the state of the counter (counter's value) outside will give you a hard time updating a counter without affecting the other. Converting the functional component to a class with a state might be good to have in a Counter component.

+1 ;)

Just ran across this post. Very nice summary! I would add in a mention of `forceUpdate()`, though.

My standard description is:

A React component re-renders in three situations:

1) The parent component re-renders, which causes all of the parent's children to try to re-render, _even if the props from the parent haven't changed_.
2) The component calls `this.setState()`, which queues a state update and a re-render
3) The component calls `this.forceUpdate()`, which queues a re-render.