Hacker News Reader

Comment by masterj | Hacker News Reader

> How does React know that only that sub-component needs to be re-rendered?

It doesn't. By default it will render the whole tree again. This happens in javascript and is probably much faster than you think.

However, when an app grows large enough, this can be a source of performance issues, which is why React provides ways you can inform it about work it shouldn't have to do, namely shouldComponentUpdate. If you can compare the data and determine that a particular sub-tree doesn't need to be updated you can implement a shouldComponentUpdate callback that does this. Immutable data that can be cheaply compared by checking reference equality is the preferred way of doing this.

More info on this was recently added to the docs: http://facebook.github.io/react/docs/advanced-performance.ht...

View on HN

I'd like to hear more about performance issues in large apps. Some of the other virtual dom libraries, namely Mithril and Mercury do not have an equivalent to shouldComponentUpdate. I'm wondering how those perform in large apps.

First someone would have to build a large app with them...

I'm sure someone's built something at least semi-large with React by now. Would love to hear about the performance at scale.

I've built an entire SPA based on React (and Backbone), which I guess can be considered semi-large.

Performance was not an issue throughout the project, even with complex components like data grids. The rendering is negligible next to things like acquiring data from the backend, that's where most of the optimization went (caching, loading resources upfront, etc). React just makes it a no-brainer.

Uh... like Facebook and Instagram?

I was referring to Mithril and Mercury. I work on a huge React app :)

I want to know how React performs at scale as well. So mind sharing? Do you have to use shouldComponentUpdate a lot? Have you tried omitting it?

Yes, I'm aware that it is possible to go around this limitation. The problem I have with this is that it kind of defeats the purpose of the library: keeping the view logic in one place.

Have you looked at immutable.js[0] and the benefits PureRenderMixin[1] give you?

[0] https://github.com/facebook/immutable-js

[1] http://facebook.github.io/react/docs/pure-render-mixin.html

> keeping the view logic in one place

Each component has its own logic. If you are rendering your main app state in child components you will be passing the state via props.

    var UserInfo = React.createClass({
      shouldComponentUpdate: function (nextProps, nextState) {
        if (nextProps.id !== this.props.id) {
          return true;
        }

        return false;
      }
    })

which makes perfect sense

Imagine I have a control with a large number (say N) of sub-components. Now something changes in the state of the control, which corresponds only to one of the sub-components. This change has to propagate to the right component. However, the shouldComponentUpdate() function is invoked on each of the components. This is O(N) work. This seems unreasonable.

To work around this, I could determine which component needs to change in the parent control. But this would mean a separation of logic.

But are you really going to have a single list of 1 million components or are you going to have 1000 components that each contain 1000 components? The second case is much more common and is handled just fine. If you really do need a 1 million top-level sub-components, then you need to look at different data structures other than just a flat list

Reply on news.ycombinator.com