Making stupid React smart in re-rendering

Joel Mun
Joel Mun
Oct 3, 2019 · 6 min read

I believed React is smart enough to know this…. but aye?

We had a bunch of large component trees in our company’s web application. And I saw them re-rendering from the top to deep down to the bottom for no reason. At first, I thought it would be easy to get them correct.

Of course, the tree was much bigger than this. The tree didn’t just reach the end. This made useless re-rendering even a bigger concern. From the top to bottom, Provider, ConnectedRouter, App, PersistGate, ComponentA, ComponentB, .... and so on.

And I saw that there were no use of shouldComponentUpdate/ PureComponent/ memo in our app yet. So I decided to make use of them, still not yet aware of what was to come for me.

Takeaway 1: Parent component pretty much does not care about its children

I was optimizing the app and witnessed an interesting fact. Here’s the code to demonstrate it:

And do you think Child1 and Child2 are going to re-render upon Parent component's mouseEnter? See what happens:

Oops. They re-render. But I do not see a reason why (The same thing happens for class components, if you wonder. You can try that!). The children do not even have their own props or states to listen for any changes. How can this happen? This is from React's own documentation:

shouldComponentUpdate() is invoked before rendering when new props or state are being received. Defaults to true.

It defaults to true! What… Ok. React is made that way.

Then how can we make it better?

Takeaway 2: use the children prop

Ok. The only difference is that we use children prop.

And the result?

It does not re-render the children components anymore! I still have not understood exactly why React can in this code but cannot in the previous code, but this is what it is.

Takeaway 3: use React.memo

memo literally memoizes the functional component receiving a certain props, and if the props stay the same, it will just return the previously rendered (same) component. The result? Same as solution 1. It does not re-render Child1 and Child2. So I'm just gonna copy and paste the gif from above for those who are lazy to read what's written, just like me:

Ok. But if you are using passing in nested objects as props, you should implement your own areEqual function for memo, like this:

Yeah. I know it’s an ol’ school style to check nested object equality, but it works well. In practice, you use something like isEqual from react-fast-compare that would handle nested object comparison for you.

Ok. Now, what’s the result?

Child1 no longer knows obj prop stays the same because memo only runs a shallow comparison between prevProps and nextProps But Child2 exactly knows, by using areEqual function, that obj is actually staying the same and therefore it does not need to re-render itself.

Takeaway 4: Use PureComponent/shouldComponentUpdate

Of course, you might wanna use your class component. So here’s a brief explanation on that as well:

Above is an exact replica of the functional component implementations. Here are the details:

  1. You use PureComponent for Child1, but it won't serve its purpose, just like memo, because it has a nested object as its prop. It will keep re-rendering upon its parent component re-rendering. It would work if there were no nested object properties.

Of course, the result is the same as the last code snippet. Let’s again copy and paste the same gif for the people:

Takeaway 5: Deal with functions from props when comparing

There are many cases where props are functions, especially when you plug your functions into components with redux’s mapDispatchToProps, or passing your functions as props from parent down to children to get notified of what happened in children.

Dealing with functions might sound like really a basic thing, but it can really harm your application’s performance if you don’t do.

We see lots of patterns like this:


  1. Now, the obj prop no longer an object. It's just become num.

But why!? Well..

In javascript, there is hardly a way to compare functions.

This will always return false, because functions are objects in javascript, meaning they are compared not with values, but references:

The only way to make it possible is to have the same reference:

Then how can we deal with functions in props? Well, there are two ways:

  1. Exclude them

1. Exclude them

You can use lodash’s _.isFunction to check if something is a function. Then you only have object properties that are not functions, to apply that to areEqual function.

Now, you can do this:

Result? Only parent component re-renders. Essentially, you are only comparing props which are not functions.

2. Stringify them

By default, JSON.stringify does not support stringifying functions. So you've gotta use third party libaries like jsonfn.

Let’s do this:

JSONfn.stringify will generate a string looking like:

Using this function will give you the same result as the last example. Here’s another copy and paste:

Yeap. That’s all.


  • If you do not use children prop, every component inside the render function of a parent will re-render by default.

Originally published at


First of all, thank you for the insightful comments.

  1. The cost of stringifying the functions may be larger than the benefit of optimization itself. So don’t use stringify, really.

The Startup

Medium's largest active publication, followed by +567K people. Follow to join our community.

Joel Mun

Written by

Joel Mun

code stuffs.

The Startup

Medium's largest active publication, followed by +567K people. Follow to join our community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade