PMG Digital Made for Humans

Common React Mistakes: Monolithic Components and a Lack of Abstraction

3 MINUTE READ | July 5, 2017

Common React Mistakes: Monolithic Components and a Lack of Abstraction

Author's headshot

Christopher Davis

Christopher Davis has written this article. More details coming soon.

coding photo

Following best practices ensures your application is in the best possible position to live a long healthy life. Some frameworks come with a strong set of opinions that shape best practices. React, however, is very new and very much a library, not a framework. As such, its best practices are still taking shape.

In the past year, PMG has built several single page applications with React and Redux. We’ve learned some of our own best practices through the best (worst) way possible: messing things up.

Monolith components are large components — either class based or functional — that contain a lot of functionality. They’re generally hard to understand and maintain. The goal is to break components like this up into smaller pieces. A lack of abstraction is a similar issue: things that should be broken into pieces are not.

Here are some common code smells and some suggestions for each.

This can originate in the typical control flow structures or because of nested JSX.

For example, a common pattern would be to map across a list and render an element for each item.

A more readable approach would be to pull the row elements into a component.

Say you have some conditional rendering in your component, something simple like:

To really test this in a monolithic component, you have to adjust the props and then fully render to see what actually happens. Extracting that conditional rendering into its own component means you can test it independently. This allows you to do shallow rendering in the bigger component to verify things. Functional components are great for this.

We’re used to extracting common functionality into methods and functions in just about any other language. Duplication in JSX, however, can be a bit more hidden. For example, you may do something like this a lot:

A content + sidebar pattern. Spot the duplication? The magic className values scattered everywhere. Those are prime candidates to pull out into components.

This strategy is a good way to reduce nesting as well.

We’re fans of composition over inheritance in pretty much any programming language. It’s tempting to treat your component’s render method as a template method. Similarly, it’s tempting to use inheritance to provide common functionality to child components.

In both cases, composition is a better approach.

For template method renders, a better approach would be to use specialization of a generic component — see the example above. Providing common functionality is done better with pure functions that can be tested on their own.

Stay in touch

Bringing news to you

Subscribe to our newsletter

By clicking and subscribing, you agree to our Terms of Service and Privacy Policy

When working with a new library or framework, some trial and error is expected. Code that isn’t easy to read, understand, or test indicates the need for modification. Hopefully, the above suggestions will help you build more sustainable React applications.

Related Content

thumbnail image

AlliPMG CultureCampaigns & Client WorkCompany NewsDigital MarketingData & Technology

PMG Innovation Challenge Inspires New Alli Technology Solutions

4 MINUTES READ | November 2, 2021

thumbnail image

Applying Function Options to Domain Entities in Go

11 MINUTES READ | October 21, 2019

thumbnail image

My Experience Teaching Through Jupyter Notebooks

4 MINUTES READ | September 21, 2019

thumbnail image

Working with an Automation Mindset

5 MINUTES READ | August 22, 2019

thumbnail image

3 Tips for Showing Value in the Tech You Build

5 MINUTES READ | April 24, 2019

thumbnail image

Testing React

13 MINUTES READ | March 12, 2019

thumbnail image

A Beginner’s Experience with Terraform

4 MINUTES READ | December 20, 2018