Pro Tips For Designing Robust React Components

As you already know, React components are written as functions these days, not classes. Among other things, it allows us to dispense with binding methods and the this prop. But with both ways, you ultimately have to write a render method that returns a part of the DOM in the form of JSX.

They return a part of the DOM and do not generate a completely new one because the DOM is quite expensive to update, so developers try to minimize the number of DOM updates as much as possible.

Hence, most web developers reduce the number of components renders to a minimum to reduce the load on both the client's browser and the server.

Another important requirement of React components is that they update their UI fairly quickly. This prevents users from unnecessarily waiting on the app frontend and improves user experience.

Finally, it helps when your components are reusable. Not only do you avoid writing the same code twice, thus satisfying the DRY (Don't Repeat Yourself) principle, you can also be confident that each instance of your reusable, independent components will do a minimal number of re-renders.

In this article, and in the next few articles in this series, I will share with you some tips to reduce the number of renders your web app makes.

Try to partition the app so that each component is independent ofothers

The reason for this is, if your components are interdependent, then each state update in one component will likely require a state update in the other component. This causes a re-render, so you end up rendering multiple times when you do a higher-level component update. Ideally, you want to update components once per high-level update, but of course, this may not always be possible.

It would help if you tried to make each component partitioned in such a way that represents the UI layout of your app. For example, most apps have a header bar with buttons and links on it. So you should contain your button components in that location inside a header component.

Each component you create adds complexity to the whole application. You have to make sure the parameters are correct, and the returned JSX is what you expected, and, in the case of arrow or lambda functions, that they are defined in an order such that a function does not call another such arrow or lambda function above it in the file.

Try to make the nesting level of components as flat as possible. Although the way React updates the DOM ensures that nested components are not re-rendered if they have not been modified in a parent component, the advantage of making the component tree flat is that it makes it easier for you to debug each component by itself.

When to use prop destructuring

Prop destructuring in methods can greatly cut down the length of your prop variable names-if done properly. For one thing, it is not recommended to destructure multiple layers of props simultaneously (nested destructuring) because you cannot validate the data in the intermediate-level props, so that is a source for semantic errors.

It is not uncommon for components to have a few dozen props, so just the spelling of those props by itself will get messy when you write your functional component.

You should destructre your props, one level at a time, when there are a small number of them like this:

Credits: https://javascript.plainenglish.io/destructure-react-props-with-es6-object-destructuring-for-cleaner-code-3984453e484d

So that you avoid writing functions that continuously reference props like this:

Credits: https://javascript.plainenglish.io/destructure-react-props-with-es6-object-destructuring-for-cleaner-code-3984453e484d

Using another component as an example, we can do two different destructuring assignments to drill down the props, doing the equivalent of nested destructuring:

Credits: https://stackoverflow.com/questions/60589914/destructuring-props-in-react

In addition to that, the spread operator fits nicely on the right side of the assignment involving a destructured variables.

That's all for today folks. Stay tuned for next week's post where I write about pro tips for managing component state. Also, let me know in the comments below if you have any questions.

Cover image by Raphal Biscaldi on Unsplash