The Little-Known Key to Optimized React Loader Components

Learn the detail that even some experienced developers miss

One might think that implementing a React loader component is pretty straightforward—and it really is. However, there’s a detail that even some experienced developers miss that will make this code more efficient and less prone to errors.

Let’s start with the simplest possible implementation:

We’d use it like this:

Before we look at the proposed improvements, let’s take a step back and make sure we understand the code evaluation order.

Let’s say we have the following code:

I hope we can all agree that the order of execution of the above functions is: function3, function2, function1. Basic stuff.

Now, what does this have to do with React components?

To write the code for rendering a component, most of us rely on an XML-like syntax called JSX (used above when rendering Loader).

But when this code goes through the compiler (Babel, most commonly), it’s transformed into raw JS, from:

To:

Try it out.

Another way to write the Loader usage is:

Pretty cool, huh?

By using the knowledge that we established at the beginning of the article regarding code evaluation order, we should understand that dataList.map(…) gets evaluated regardless of the value of isLoading or the values of dataList.

We assumed that dataList will only be populated when isLoading becomes false. But now we know that it will be used even before that. So when that happens, we need to have defensive code, to protect against the case when dataList is undefined.

Writing defensive code is one way to fix this, but what about efficiency? Wouldn’t we want to avoid executing dataList.map(…) altogether, if we don’t need to, e.g. when isLoading is true?

A pattern we can use is the following:

So instead of sending the already-computed content to be rendered, we send a function that will return that content. That function is actually a thunk. You might already know about thunks from redux-thunk. For this to work, we need to modify the Loader component as follows:

In this scenario, children is the function that returns the content.

This pattern is efficient because it delays computing the code to render children until it’s actually needed. This is useful when the children might not need to be rendered.

We can avoid the errors we’d get if we tried to compute render content before having the data it depends on.

This enables us to write shorter code that doesn’t require as much defense (since we’re computing only when we have all the data we need).

This pattern can be used with other components just as well (think any component that renders its children conditionally; for instance, based on the user’s permissions).

Thanks for reading! I hope this has improved your understanding of how code is evaluated on render.