Higher Order Components in React

Traditionally, engineers use mixins, decorators, inheritance, and plain code duplication to add common functionality to a handful of components. Mixins and decorators can modify the target object in such a way that you are never really sure what methods are safe to override without unwanted side effects. Inheritance can quickly get out of hand as you choose a base class and later discover that you actually need functionality from several base classes. Code duplication increases your technical debt and creates more work later. Sometimes, these patterns are the smart choice to solve your problem, but often, you can solve them more effectively with higher-order components.

Described by the React team as an alternative to using mixins with React, the higher-order component design pattern can help us author reusable, testable components in our web applications. In the simplest terms, a higher-order component is a function that accepts a component, and returns a new component that wraps the original. While traditional mixins and inheritance modify the target component, higher-order components use composition to add new functionality into existing objects.

Let’s look at a scenario where the use of higher-order components can simplify our codebase. The source code samples here use React and assume you have a basic understanding of React and ES6+ features like arrow functions and classes.

Our project

Let’s say we have a simple React web app in which we have three views: homepage, account, and schedule. The account and schedule views reside behind some kind of user authentication mechanism and are only accessible by logged in users.

A common way to accomplish this sort of conditional rendering is by, well, conditionals.

The render method of our authorized components check if a user is authorized, and, if so, renders their content. If the user is not authorized, they present a login form instead. This may approach may work fine for the first component, but let’s take a look at another.

The rendering conditional is identical in each component that needs authorization.

Adding authorization to another component will further duplicate code, and removing authorization from a component requires you to make changes to the component, where there is always a risk of making a mistake that might introduce new bugs.

The visual component should not need to know how it is being displayed, just that it is.

Enter higher-order components

The good news is that we can fix all of those problems by using higher-order components. Our goal is to separate our authentication logic (choosing when to display the intended content and when to display the login form) from our component.

To declare our higher-order component, we just need to declare a function that accepts an existing component, and returns a new component that wraps the original component with additional logic.

We call the Authorized function and pass in the component we want to be reserved for users only.

The Authorized function creates a new component and returns it.

The new component performs the same authorization logic we used to use, but now it is only used in one place. Upon authorization, the original, wrapped component, is rendered (passing through any properties that were provided).

To use this new Authorized function, we just need to call it on our existing components to create the authorized versions.

In our small example here, a higher-order component was able to resolve each architecture and code quality problem we mentioned earlier.

First, removing the authorization logic from every other component removes our duplicate code and puts our logic in one, known, component. This makes things easier to test, and easier to troubleshoot.

Second, separating our authorization code has also made our presentational components more stable. If we need to add authorization to a component in the future, all we need to do is wrap it on our Authorized component. Need to remove authorization from a component? Just unwrap it. We no longer need to update the components when we need/don’t need components to be behind the authorized barrier. Our tests for authorization logic can now dwell with the authorization component rather than be sprinkled around in unrelated places.

Third, our components are simpler. They are no longer concerned with determining if a user is authenticated. Need some logic that is more complex? That’s easy too. Since it’s just a function call, we can easily add more complex features to our Authorized component. Imagine you had components that were allowed only for admins, and not regular users? All we need to do is add that logic to Authorized, and leave our other components alone.

const adminPage = Authorized(SomePage, 'admin');

That’s great.. but my authentication system isn’t like this

Higher-order components aren’t just for authentication systems, but can be used to solve a variety of problems. Be on the lookout for other places where you could use higher-order components, you might be surprised on their versatility.

You can see that this design pattern packs a lot of punch. Higher-order components may not be the silver bullet solution to all your problems, but they deserve a significant place in your design pattern tool belt. How do you know if your problem is a good a fit for this pattern? If you are adding the same code, especially code to your render method, to multiple components, this pattern might be a good fit.

If you are interested in learning more about higher-order components, read about them out in the React Docs.