The Application

The playground application is pre-configured with create-react-app 2.1.1. And has only 4 components and the data source.

App: root component which has other 3 components and a button to increment his count state;

Search: input data filter;

Container: container to all Cards;

Card: simple button with name from data;

data: array of names

Application UI

Seeing what is updating

By using the Chrome Developer Tools with React Developer Tools we can see how our components are being updated. For instance: we can see at the yellow bar that is some javascript happening, and if we scroll in we can see that chrome developer tools recognizes react components and show what react is doing since React Tree Reconciliation until React Card (Mount).

Reverse Christmas Tree

Since the javascript is single thread, where a component is doing something it is hogging the main thread and preventing another component to run, we are able to see that behaviour at the last line, each card being mounted.

Note that by avoiding wrappers we will have a smaller reverse christmas tree and so less updates to do. Briefing: we want to avoid some really deep.

Also, to help us to check when our app is updating we can use React Developer Tools wrapper highlight, this tool work as follow: when something is updating on browser it will highlight, the more updates occurs more vivid color will be the highlight, it is very helpful for detecting an unnecessary render cycle.

Keep in mind that seeing vivid color highlight isn’t necessarily bad thing, its going to be expected when we are doing things like sliders or scrolling or any UI elements that triggers frequent updates. But if we are just clicking a button and something vivid is happening that can be a mark about a thing that we need to fix.

By using chrome developer tools and react developer tools we are able to see how our react application is being updated.

Managing the Updates

So, now we are able to see where and when our application is updating but how to avoid this update? By checking the React Lifecycle Component we can see that in update cycle we have shouldComponentUpdate method before the render.

In order to avoid the re render shouldComponentUpdate() gives us the ability to control this update cycle. If shouldComponentUpdate() return true the update will occur, else the update will not occur.

Example

In our application we have a button in App component which should update App Component state when we clicked on:

By updating this state as we said before all children of App Component will be updated too, but we don’t need that our Card Components to be updated so we can implement in our Card Component:

So our component will be updated only when his state clicked change or his props name change. So we probably are asking: this is really useful or helpful? Well let’s run some test.

Testing

The test was simple: 59 clicks in 12 seconds on click button while we are recording.

With shouldComponentUpdate().

Testing using shouldComponentUpdate()

Without shouldComponentUpdate().

Testing not using shouldComponentUpdate()

Side by side.

shouldComponentUpdate() (localhost #3) without (localhost #2)

Ps: there is a huge lag when we don’t se shouldComponentUpdate().

But we need to keep in mind that adding shouldComponentUpdate we are also creating a function call before render so, we have a penalty here too. So don’t use to every single component, measure it.

We can also use PureComponent. This means that only will re render when its props actually change, it will implement shouldComponentUpdate for us. I personally like use shouldComponentUpdate which does the same thing but we have a bit of control.

Throttling

Throttle will ensure that the function is only called one time every interval. Throttling reduces the frequency of how many times the function will be called.

Testing

So, as before, the test was simple: 50 clicks in 8 seconds on Card component.

Implementing throttling with 1 second interval on Card component (when clicked change background color) we have the information below. We can see that scripting takes a long time but only during an interval. That is really important to note because by implement throttling we are increasing the code complexity so, naturally, it will take more time.

Testing using throttle

On the other hand, by avoiding throttle we have a constant scripting use. And in the end we take 2x time than using throttle.

Testing avoiding throttle

Side by side.

with throttle (localhost #5) without (localhost #6)

Debouncing

Debounce will ensure that the function will only run after the specific given delay/timeout value assuming the function has not been called again within that time span. Unlike throttle where the function will execute every interval, debounce will “reset the timer” if the function is invoked before the timer ends.

To debounce I used react-debounce-input.

Testing

So, as usual, the test was simple: write Jackqueline and deleting character by character during 10 seconds on Search Component.

Side by side, we can see that didn’t have so much difference. BUT if we think about requests, each input change value can be a request and by debouncing we can improve the number of requests (but this improvement is for another text).

with (localhost #10) and without (localhost #11) debouncing

So…

Now we are fully capable to check visually when our component are doing unnecessary updates, and manage this with shouldComponentUpdate() and PureComponent AND if this isn’t enough we can use throttle technic to improve even more.