3 ms·
> 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 javascr
by masterj 12y ago
> 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.html http://facebook.github.io/react/docs/advanced-performance.ht...
- amelius 12y agoYes, 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.
- pests 12y agoHave you looked at immutable.js[0] and the benefits PureRenderMixin[1] give you? [0] https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js [1] http://facebook.github.io/react/docs/pure-render-mixin.html http://facebook.github.io/react/docs/pure-render-mixin.html
- mikewhy 12y ago> 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
- amelius 12y agoImagine 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.
- TheCoelacanth 12y agoBut 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
- Touche 12y agoI'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.
- masterj 12y agoFirst someone would have to build a large app with them...
- Touche 12y agoI'm sure someone's built something at least semi-large with React by now. Would love to hear about the performance at scale.
- hcarvalhoalves 12y agoI'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.
- marknutter 12y agoUh... like Facebook and Instagram?