Performance of React relies on the architecture, components and libraries that you use in your application. To catch the performance chokepoint, you must first understand the underlying architecture.
Since you’re reading this post, you’re probably familiar with React. I also suppose that you are looking for reasons why your application does not work fast enough and how to speed up your React App.
I have prepared a series of 2 blog posts for you, in which I will highlight the techniques for making your React app faster.
This article covers 2 issues:
Complex variables in render
In my next post I will focus on:
- Reselect - return values only when they are needed
- Redux good practices
What’s exactly wrong with React?
React is a simple and light library just to... render the components which are compiled into html. Communication between modules or classes is done via props from a parent. Each time the props are changed, the render method of all components is triggered. It’s called one-way data binding. Sounds great?
In small and simple apps this approach works very well. But sometimes, when our project is growing to include new features, we can see that performance drops. Loading views takes more time, refreshing components seems to be harder than before. You may ask yourself:
Why? What did I do wrong?
The answer is:
Render is the most memory-consuming function. But when we plan our app structure in a good way, we can prevent unnecessary rendering.
Before we start, however, let’s define what “long loading time” means exactly. Fortunately, https://github.com/maicki/why-did-you-update comes with help. It’s a small library (719 kb unzipped) which lets us know how many components render in a particular view.
As developers we should know that something is wrong when we see this image:
Complex variables in render
Perhaps most of us have heard of react lifecycle method, shouldComponentUpdate.
This method gives us control over when the component should update. Shocking ;)? But in this article I will tell you one thing:
Before you use this function, check your render method.
Solution: Avoid complex data declaration in render.
Let’s consider a simple example. We have two components: Box and Paragraph. Box contains Paragraph and listens to prop ‘clicks’. Paragraph has an options prop, with text and style. Each time ‘clicks’ is changed, Box is rendered. What about Paragraph? It shouldn’t be refreshed.
In this case, the solution will keep our options object as variable or property of class:
This example is based on an object, but the same happens with arrays and functions.
As you can see, all the components are written as classes. Personally, I prefer to use stateless components because they are more readable, and help us avoid this context problem. In this case Recompose library comes with help.
To prevent re-rendering (sorry, our jargon) Paragraph in our example, we had to write it as a class and define ‘shouldComponentUpdate’ method. This can be done more easily thanks to Recompose which gives us a lot of helpful hoc’s.
I recommend using pure higher order component or purecomponent from React.
Let’s see how this example can be written in that way:
And using PureComponent:
If you want to familiarize yourself with other methods of this library, and there are a lot of them, visit https://github.com/acdlite/recompose.
I hope the tools and techniques presented in this blogpost will help you make react apps faster.
Thanks for reading. If you want to learn about Reselect and Redux good practices,
take a look at my new post coming soon. So, stay tuned.