Disclaimer: this is not an introduction to React, and some familiarity with React is required. For an introduction to React, check my other article: React.js: a better introduction to the most powerful UI library ever created.
Over the years I came to a realization that the only proper way to develop high-quality React applications is by writing stateless functional components.
In this article, I will give a brief introduction of functional components, and of higher-order components. After that, we’ll dive right in into refactoring a bloated React component into a clean and elegant solution consisting of multiple composable higher-order components.
Photo by Dean Pugh on Unsplash
Introduction to Functional Components
Functional Components are called so because they literally areplain JavaScript functions. An idiomatic React application should consist exclusively of functional components.
First of all let’s take a look at a very simple class component
And now let’s rewrite the same component as a functional component:
As you can see, the functional component is much cleaner, shorter, and is easier to read. There’s also no need for the this keyword.
Some other benefits:
- Easy to reason about - functional components are pure functions, which means that they will always produce the same output for the same input. Given name Ilya, the above component will render
<h1>Hi, Ilya</h1>, no matter what. - Easy to test - since functional components are pure functions, it is very easy to run assertions against them: given some props, expect it to render the following markup.
- Help prevent abuse of component state, favoring props instead.
- Encourage reusable and modular code.
- Discourage huge, over-complicated “god” components that have too many responsibilities.
- Composable - behavior can be added as needed with a higher-order component.
If your component has no methods other than the render() method, then there’s really no reason to use class components.
Higher Order Components
A higher-order component (HOC) is a technique in React for reusing (and isolating) component logic. You’ve probably already encountered HOCs — Redux’s connect is a higher-order component.
Applying a HOC to a component will enhance the existing component with new features. This is usually done by adding new props that will get passed down to your component. In the case of Redux’s connect your component will get new props that got mapped with mapStateToProps and mapDispatchToProps functions.
We often need to interact with localStorage, however, interacting with localStorage directly inside of a component is wrong because it is a side effect. In idiomatic React, the components should have no side effects. The following simple higher-order component will add three new props to the wrapped component, and will enable it to interact with localStorage.
Then we would simply apply it in the following way: withLocalStorage(MyComponent)
A Messy Class Component
Photo by freestocks.org on Unsplash
Let me introduce you to the component we’ll be working with. It is a simple sign up form consisting of three fields with some basic form validation.
The above component is messy, it is doing many things at once: handling its state, validating form fields, and rendering the form. It is already at 140 lines of code. Adding any more functionality would soon make it impossible to maintain. Can’t we do any better?
Let’s see what we can do about it.
The Need for Recompose
Recompose is a React utility belt for function components and higher-order components. Think of it like lodash for React.
Recompose allows you to enhance your functional components by adding state, lifecycle methods, context, among other things.
Best of all it allows you to have clear separation of concerns - you can have the main component responsible exclusively for layout, a higher-order component responsible for handling form inputs, another one for handling form validation, another one for submitting the form. And it is very easy to test!
The Elegant Functional Component
Photo by Austin Neill on Unsplash
Let’s see what can be done about the bloated class component.
Step 0. Install recompose.
Let’s add recompose to our project.
yarn add recompose
Step 1. Extract input form state.
We’ll be making use of the [withStateHandlers](https://github.com/acdlite/recompose/blob/master/docs/API.md#withstatehandlers) higher-order component from recompose. It will allow us to isolate the component state from the component itself. We’ll use it to add form state for the email, password and confirm password fields, as well as event handlers for the above-mentioned fields.
The withStateHandlers higher-order component is very simple - it takes the initial state, and an object containing the state handlers. Each of the state handlers will return new state when called.
Step 2. Extract form validation logic.
Now it’s time to extract the form validation logic. We’ll be using [withProps](https://github.com/acdlite/recompose/blob/master/docs/API.md#withprops) higher-order component from recompose. It allows adding any arbitrary props to an existing component.
We’ll use withProps to add the emailError, passwordError, and confirmPasswordError props, which will contain errors if any of our form fields are invalid.
One should also note that the validation logic for every one of the form fields is kept in a separate file (for better separation of concerns).
Step 3. Extract form submission logic.
In this step we’ll extract form submission logic. This time we’ll make use of the withHandlers higher-order component to add the onSubmit handler.
Why not use withProps as before? Having arrow functions in withProps significantly hurts performance — a new instance of the function will be created under the hood every time, which will result in useless re-renders. withHandlers is a special version of withProps , which is intended to be used with arrow functions.
The handleSubmit function takes the emailError , passwordError , and confirmPasswordError props passed down from the previous step, checks if there are any errors, and if not posts data to our API.
Step 4. Here comes the magic.
And finally we combine the higher-order components we’ve created into a single enhancer that can be used on our form. We’ll be using compose function from recompose which enables combining multiple higher-order components.
Note how elegant and clean this solution is. All of the required logic is simply being added on top of another to produce one single enhancer component.
Step 5. A Breath of Fresh Air.
Now let’s take a look at the SignupForm component itself.
The new refactored component is very clean, and does only one thing - rendering the markup. Single responsibility principle states that a module should do one thing, and it should do it well. I believe that we have achieved this goal.
All of the required data and input handlers are simply passed down as props. This in turn makes the component extremely easy to test.
We should always strive for our components to contain no logic at all, and only be responsible for rendering. Recompose allows us to do just that.
Project Source Code
If you run into any issues following along, you can download the entire project from github.
Bonus: optimizing performance with pure
Recompose has [pure](https://github.com/acdlite/recompose/blob/master/docs/API.md#pure), which is a nice higher-order component that allows us to re-render the components only when needed. pure will ensure that the component doesn’t re-render unless any of the props have changed.
Summary
We should always follow the single responsibility principle, and strive to isolate logic from presentation. We do this by first of all outlawing class components. The main component itself should be functional, and should only be responsible for rendering the markup and nothing else. All of the required state and logic is then added as higher-order components.
Following the above rules will make your code clear and clean, easy to read, maintainable, and easy to test.
An article on testing higher-order components is coming soon.