Optimizing React Rendering

&gt; So all you have to do is use PureComponent everywhere and you’re good to go. There’s nothing more to it. Enjoy your new blazing fast React app!<p>(I work on React.) This isn&#x27;t quite right. If we recommended that PureComponent be used everywhere, it would probably be the default already. Rather -- the comparison to decide whether or not a component should be rerendered costs something, and in the case that you <i>do</i> want to rerender, all of the time spent checking whether you should have rerendered is wasted.<p>Instead, we&#x27;d suggest you be conscious of where you need to do the comparisons. It&#x27;s usually only in a couple of places in your app. Good candidates are on the children of a long list or around large parts of the app that change independently (that is, cases where you know the parent should often rerender but the child shouldn&#x27;t). A few well-placed shouldComponentUpdate (or PureComponent) uses can go a long way.

This is actually a pretty decent article, in part because it signals its audience properly: (semi-?)experienced React developers who haven&#x27;t dealt with optimization yet.

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&#x27;t really care about it the most of the time.<p>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.<p>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&#x27;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.

Pretty good post, minus the advice to always use PureComponent everywhere (per Ben&#x27;s comment in this thread).<p>If anyone&#x27;s interested, my React&#x2F;Redux links list has a large section of other articles on various React-related performance concerns, including benchmarking and optimization approaches: <a href="https:&#x2F;&#x2F;github.com&#x2F;markerikson&#x2F;react-redux-links&#x2F;blob&#x2F;master&#x2F;react-performance.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;markerikson&#x2F;react-redux-links&#x2F;blob&#x2F;master...</a> .

From the article:<p>&gt; Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed.<p>Not a frontend guy but I&#x27;ve seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn&#x27;t efficient DOM manipulation by pruning non-necessary changes kind of their thing?

Along the same lines as the advice in TFA: If you pass an object literal as the `style` prop, it&#x27;ll always re-render, because the object reference will change. Solution: instead of the object literal, pass a reference to an existing object.

One thing that has been bothering me is that React is slow by default. It re-renders everything every time unless you start looking into shouldComponentUpdate.<p>Even if I agree that premature optimization is the root of all evils, I like when the language and the framework I use make it writing fast code as easy as writing slow code.<p>I wonder if anybody has evaluated, the improvement they get in development speed using React when they add the time they have to spend to optimizing their React code.<p>In my experience, I am not even frustrated with React itself most of the time but with the other things in the ecosystem.

From what I&#x27;ve found in my current job creating a js react app as well as side project with cljs is that advanced optimsation of js react === basic usage of clojurescript reagent. I&#x27;ve found no redeeming features when developing the is app, issues with hot reloading and constant integration work to get everything to play nice with immutable js

Is there special logic in react that binds arguments of a function to the props with the same name? I&#x27;m talking about the handleDelete &quot;fix&quot; in the article:<p><pre><code> render() { const views = this .props.dataList.map((d, i) =&gt; { return &lt;Data data={d} index={i} onDelete={this.handleDelete} &#x2F;&gt; }); } handleDelete(index) { &#x2F;&#x2F;... } </code></pre> I guess they just call that function from within the Data component with the correct parameter. But then, Data component needs to know how to call that function. Is there a better way?

I&#x27;m the author of CxJS[1] which uses React for rendering. Before rendering, the whole tree is scanned for data changes and with that information available shouldComponentUpdate is very simple.<p>Another technique that I find very useful is to use a dedicated data declaration component which then decides if children should update or not. Try grid sorting on this page: <a href="https:&#x2F;&#x2F;worldoscope.cxjs.io&#x2F;yyrsmjk" rel="nofollow">https:&#x2F;&#x2F;worldoscope.cxjs.io&#x2F;yyrsmjk</a><p>[1]: <a href="https:&#x2F;&#x2F;cxjs.io" rel="nofollow">https:&#x2F;&#x2F;cxjs.io</a>

Would using mobx to manage state solve most of these problems?

I would generally say that there is a reciprocal relationship of performance and maintainable code, no matter what you use.<p>React is a powerful way to build your front-end, but it&#x27;s power is in structure &#x2F; code.<p>In my experience with React, fine-tuning components for faster rendering is always a pain. Too much magic happens behind the scenes and too difficult to keep that in mind while writing your beautiful components.

Off-topic: what is the theme and color syntax theme ?

Quick question - can printWasted be used with RN too?