VJvjeux·Jul 21, 2014
(a) You can use the key attribute in order to get DOM reuse. If you are looping over N keys then React is going to reuse the nodes and move them around.
(b) You can implement shouldComponentUpdate in order to have a quick way not to re-render a sub-tree if nothing changed.
(c) See (b) but we're also working on changing the internal representation of the virtual DOM to plain js objects that can be reused[1]. We were super worried about GC but it turns out that it hasn't been the bottleneck yet for our use cases.
(d) If you are writing pure React, all the actions are batched and actually, it's write-only, React almost never reads from the DOM. If you really need to read, you can do it in componentWillUpdate and write in componentDidUpdate. This will coordinate all the reads and write properly.
A really important part of React is that by def
Read the rest
ault this is reasonably fast, but most importantly, when you have bottlenecks, you can improve performance without having to do drastic architecture changes.
(1) You can implement shouldComponentUpdate at specific points and get huge speedup. We've released a perf tool that tells you where are the most impactful places to[2]. If you are bold, you can go the route of using immutable data structures all over the place like Om/the elm example and you're not going to have to worry about it.
(2) At any point in time, you can skip React and go back to raw DOM operations for performance critical components. This is what Atom is doing and the rest of their UI is pure React.
[1] https://github.com/reactjs/react-future/blob/master/01%20-%2...
[2] http://facebook.github.io/react/docs/perf.html#perf.printwas...