dounan

> Correct me if I'm missing anything!

You're not missing anything :) That approach also works. The important point is that you have to pass the extra index prop down to the child to avoid the bind in render.

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 :)

I've updated the post to say 'in the right places' instead of 'everywhere' until we get some profiling data.

In our experience, React is not necessarily 'slow' by default. Re-constructing parts of the element tree each time can be a bit wasteful, but it is only as slow as your render() methods, and that is outside of React's control.

We have survived over 3 years with a massive application (over 2000 modules) and tons of wasteful re-rendering, but have only now started to notice any sluggishness. That makes React pretty fast in my mind.

Having said all that, we are experimenting with an 'all PureComponents' approach to potentially make React, but whether that turns out to be a good idea is yet to be seen (object comparisons in sCU are not free).

First off, thanks for your work on React! Makes all of our lives easier as developers :)

As dmnd pointed out, I'm not entirely convinced that dropping PureComponent everywhere is not a good idea.

For our app specifically, we unfortunately do data loading in a lot of places, which means that there are quite a bit more than just few places that can benefit from being a PureComponent. Our current idea is to try to make everything a PureComponent, and go back and 'unpurify' the places that have wasteful sCU comparisons. This might not turn out to be a good idea though, for the reasons you mentioned.

I'll make sure to do some profiling in our codebase once we get to that point, and see how much wasted sCU we are doing.

For this specific example you don't have access to the list index in the constructor.

In general binding like that in the constructor works only if you depend on props, but at that point, there isn't a need to bind at all since you can just reference the prop in the callback.

Atom editor with the 'One Dark' theme

nit: new component instance (not element)

> I guess they just call that function from within the Data component with the correct parameter.

Yep

> Is there a better way?

We're experimenting with some other options internally. Once we have a better sense of what works best, we will post another article on our learnings :)

The reason arrow functions and bind don't play well with PureComponents is that they return a new function instance each time. This means that the Data pure component will wastefully re-render even if none of the other props change.