[uranian]

For some reason the focus is always on preventing re-rendering if it comes to optimising a React app. I understand that it can be really effective and is often the easy way out, but re-rendering in itself is not costly and I don't really care about it the most of the time.

I am more concerned that the code that runs during a re-render is not rebuilding huge static lists that never change and so. I see that over and over again in React apps. I tend to build a lot of the static stuff in the ComponentWillMount stage to prevent that. Only when already optimised code is getting to slow I start thinking about preventing re-rendering if possible.

My reason for not starting with ShouldComponentUpdate is that you have to be very careful not creating nasty bugs with that like I did some times. If a year later you write some code and it doesn't work for some reason it is painful if you find out after a long search that a stupid child component did not update for some prevention rule you forgot about. I really try hard to avoid premature optimisations.

[dounan]

That's a great point, and being aware of the dangers of shouldComponentUpdate is what this post is all about. There are a lot of gotchas when using PureComponents, and can lead to bugs if you're not careful.

Also, recalculating derived data (building static lists) in render() is very wasteful, and is also another gotcha when using PureComponents (object copying). Removing object copying from render() speeds up the actual render() call and allows you to take full advantage of PureComponents.

We are experimenting with ways to make all of this a bit easier, and hopefully will have some good news to share in Part 2 :)