This is the second part of the series on Higher-Order Components (HOCs). Today, I will cover different higher-order component patterns that are useful and implementable. With HOCs, you can abstract redundant code into a layer of higher order. However, like any other patterns out there, it will take some time to get used to HOCs. This tutorial will help you bridge that gap. 

Prerequisite

I recommend that you follow the first part of the series if you haven't already. In the first part, we talked about HOC syntax basics and everything you need to get started with higher-order components.

In this tutorial, we will be building on top of the concepts that we've already covered in part one. I've created several sample HOCs which are practically useful, and you can incorporate these ideas into your project. Code snippets are provided in each section, and a working demo of all the practical HOCs discussed in this tutorial is provided at the end of the tutorial.

You can also fork the code from my GitHub repo.

Practical Higher-Order Components

Since HOCs create a new abstract container component, here is the list of things that you can normally do with them:

• Wrap an element or component around a component.
• State abstraction.
• Manipulate props, e.g. adding new props and modifying or removing existing props.
• Props validation to create.
• Use refs to access instance methods.

Let's talk about these one by one. 

HOC as a Wrapper Component

If you recall, the final example in my previous tutorial demonstrated how a HOC wraps the InputComponent with other components and elements. This is useful for styling and for reusing logic wherever possible. For instance, you can use this technique to create a reusable loader indicator or an animated transition effect that should be triggered by certain events. 

A Loading Indicator HOC

The first example is a loading indicator built using HOC. It checks whether a particular prop is empty, and the loading indicator is displayed until the data is fetched and returned.

LoadIndicator/LoadIndicatorHOC.jsx

/* Method that checks whether a props is empty
prop can be an object, string or an array */

const isEmpty = (prop) => (
  prop === null ||
  prop === undefined ||
  (prop.hasOwnProperty('length') && prop.length === 0) ||
  (prop.constructor === Object && Object.keys(prop).length === 0)
);

const withLoader = (loadingProp) => (WrappedComponent) => {
  return class LoadIndicator extends Component {

    render() {


      return isEmpty(this.props[loadingProp]) ? <div className="loader" /> : <WrappedComponent {...this.props} />;
    }
  }
}


export default withLoader;

LoadIndicator/LoadIndicatorDemo.jsx

import React, { Component } from 'react';
import withLoader from './LoaderHOC.jsx';

class LoaderDemo extends Component {

    constructor(props) {
		super(props);
		this.state = {
			contactList: []
		}

	}

	componentWillMount() {
		let init = {
			   method: 'GET',
               headers: new Headers(),
               mode: 'cors',
               cache: 'default'
           };

        fetch
        ('https://demo1443058.mockable.io/users/', init)
        	.then( (response) => (response.json()))
        	.then(
        		(data) => this.setState(
        			prevState => ({
     					contactList: [...data.contacts]
		        	})
		        )
		    )
    }

	render() {

		return(
            <div className="contactApp">
				<ContactListWithLoadIndicator contacts = {this.state.contactList} />
			   </div>
     	  )
	}
}

const ContactList = ({contacts}) => {
	return(
        <ul>
             {/* Code omitted for brevity */}
        </ul>
	)
}

 /* Static props can be passed down as function arguments */
const ContactListWithLoadIndicator = withLoader('contacts')(ContactList);

export default LoaderDemo;

This is also the first time that we've used the second parameter as input to the HOC. The second parameter, which I've named 'loadingProp', is used here to tell the HOC that it needs to check whether that particular prop is fetched and available. In the example, the isEmpty function checks whether the loadingProp is empty, and an indicator is displayed until the props are updated.

You have two options for passing down data to the HOC, either as a prop (which is the usual way) or as a parameter to the HOC.

/* Two ways of passing down props */

<ContactListWithLoadIndicator contacts = {this.state.contactList} loadingProp= "contacts" />

//vs

const ContactListWithLoadIndicator = withLoader('contacts')(ContactList);

Here is how I choose between the two. If the data doesn't have any scope beyond that of the HOC and if the data is static, then pass them as parameters. If the props are relevant to the HOC and also to the wrapped component, pass them as usual props. I've covered more about this in my third tutorial.

State Abstraction and Prop Manipulation

State abstraction means generalizing the state to a higher-order component. All the state management of the WrappedComponent will be handled by the higher-order component. The HOC adds new state, and then the state is passed down as props to the WrappedComponent. 

A Higher-Order Generic Container

If you noticed, the loader example above had a component that made a GET request using the fetch API. After retrieving the data, it was stored in the state. Making an API request when a component mounts is a common scenario, and we could make a HOC that perfectly fits into this role.

GenericContainer/GenericContainerHOC.jsx

import React, { Component } from 'react';

const withGenericContainer = ({reqUrl, reqMethod, resName}) => WrappedComponent => {
    return class GenericContainer extends Component {

		constructor(props) {
			super(props);
		this.state = {
			[resName]: [],

		}
	}
		componentWillMount() {

				let init = {
					   method: reqMethod,
		               headers: new Headers(),
		               mode: 'cors',
		               cache: 'default'
		           };


		        fetch(reqUrl, init)
		        	.then( (response) => (response.json()))
		        	.then(
		        		(data) =>  {this.setState(
        			prevState => ({
     					[resName]: [...data.contacts]
		        	})
		        )}
		    )
		}

		render() {
			return(
				<WrappedComponent {...this.props} {...this.state} />)
		}

	}
}

export default withGenericContainer;

GenericContainer/GenericContainerDemo.jsx

/* A presentational component */

const GenericContainerDemo = () =>  {

    return (
      <div className="contactApp">
        <ContactListWithGenericContainer />
    </div>
    )
 }


const ContactList = ({contacts}) => {
    return(
        <ul>
             {/* Code omitted for brevity */}
        </ul>
	)
}

/* withGenericContainer HOC that accepts a static configuration object.
The resName corresponds to the name of the state where the fetched data will be stored*/

const ContactListWithGenericContainer = withGenericContainer(
    { reqUrl: 'https://demo1443058.mockable.io/users/', reqMethod: 'GET', resName: 'contacts' })(ContactList);

The state has been generalized, and the value of the state is being passed down as props. We've made the component configurable too.

const withGenericContainer = ({reqUrl, reqMethod, resName}) => WrappedComponent => {

}

It accepts a configuration object as an input that gives more information about the API URL, the method, and the name of the state key where the result is stored. The logic used in componentWillMount() demonstrates using a dynamic key name with this.setState.

A Higher-Order Form

Here is another example that uses the state abstraction to create a useful higher-order form component. 

CustomForm/CustomFormDemo.jsx

const Form = (props) => {

    const handleSubmit = (e) => {
		e.preventDefault();
		props.onSubmit();
	}

	const handleChange = (e) => {
		const inputName = e.target.name;
		const inputValue = e.target.value;

		props.onChange(inputName,inputValue);
	}

	return(
		<div>
         {/* onSubmit and onChange events are triggered by the form */ }
		  <form onSubmit  = {handleSubmit} onChange={handleChange}>
			<input name = "name" type= "text" />
			<input name ="email" type="text"  />
			<button type="submit"> Submit </button>
		  </form>
		</div>

		)
}

const CustomFormDemo = (props) => {

	return(
		<div>
			<SignupWithCustomForm {...props} />
		</div>
		);
}

const SignupWithCustomForm = withCustomForm({ contact: {name: '', email: ''}})({propName:'contact', propListName: 'contactList'})(Form);

CustomForm/CustomFormHOC.jsx

const CustomForm = (propState) => ({propName, propListName}) => WrappedComponent => {
    return class withCustomForm extends Component {


	constructor(props) {
		super(props);
		propState[propListName] = [];
		this.state = propState;

		this.handleSubmit = this.handleSubmit.bind(this);
		this.handleChange = this.handleChange.bind(this);
	}

	/* prevState holds the old state. The old list is concatenated with the new state and copied to the array */

	handleSubmit() {
      this.setState( prevState => {
      	return ({
        [propListName]: [...prevState[propListName], this.state[propName] ]
      })}, () => console.log(this.state[propListName]) )}


  /* When the input field value is changed, the [propName] is updated */
  handleChange(name, value) {

      this.setState( prevState => (
        {[propName]: {...prevState[propName], [name]:value} }) )
      }

		render() {
			return(
				<WrappedComponent {...this.props} {...this.state} onChange = {this.handleChange} onSubmit = {this.handleSubmit} />
				)
		}
	}
}

export default withCustomForm;

The example demonstrates how the state abstraction can be used along with a presentational component to make form creation easier. Here, the form is a presentational component and is an input to the HOC. The initial state of the form and the name of the state items are also passed as parameters. 

const SignupWithCustomForm = withCustomForm
({ contact: {name: '', email: ''}}) //Initial state
({propName:'contact', propListName: 'contactList'}) //The name of state object and the array
(Form); // WrappedComponent

However, note that if there are multiple props with the same name, ordering is important, and the last declaration of a prop will always win. In this case, if another component pushes a prop named contact or contactList, that will result in a name conflict. So you should either namespace your HOC props so that they don't conflict with the existing props or order them in such a way that the props that should have the highest priority are declared first. This will be covered in depth in the third tutorial.

Prop Manipulation Using HOC

Prop manipulation involves adding new props, modifying existing props, or ignoring them entirely. In the CustomForm example above, the HOC passed down some new props.

    <WrappedComponent {...this.props} {...this.state} onChange = {this.handleChange} onSubmit = {this.handleSubmit} />

Similarly, you can decide to disregard props entirely. The example below demonstrates this scenario.

// Technically an HOC
const ignoreHOC = (anything) => (props) => <h1> The props are ignored</h1>
const IgnoreList = ignoreHOC(List)()
<IgnoreList />

You can also do some validation/filtering props using this technique. The higher-order component decides whether a child component should receive certain props, or route the user to a different component if certain conditions are not met. 

A Higher-Order Component for Protecting Routes

 Here is an example of protecting routes by wrapping the relevant component with a withAuth higher-order component.

ProtectedRoutes/ProtectedRoutesHOC.jsx

const withAuth = WrappedComponent => {
  return class ProtectedRoutes extends Component {

    /* Checks whether the used is authenticated on Mount*/
    componentWillMount() {
      if (!this.props.authenticated) {
        this.props.history.push('/login');
      }
    }

    render() {

      return (
        <div>
          <WrappedComponent {...this.props} />
        </div>
      )
    }
  }
}

export default withAuth;

ProtectedRoutes/ProtectedRoutesDemo.jsx

import {withRouter} from "react-router-dom";


class ProtectedRoutesDemo extends Component {

  constructor(props) {
    super(props);
    /* Initialize state to false */
    this.state = {
      authenticated: false,
    }
  }
  render() {

    const { match } = this.props;
    console.log(match);
    return (

      <div>

        <ul className="nav navbar-nav">
          <li><Link to={`${match.url}/home/`}>Home</Link></li>
          <li><Link to={`${match.url}/contacts`}>Contacts(Protected Route)</Link></li>
        </ul>


        <Switch>
          <Route exact path={`${match.path}/home/`} component={Home} />
          <Route path={`${match.path}/contacts`} render={() => <ContactsWithAuth authenticated={this.state.authenticated} {...this.props} />} />
        </Switch>

      </div>


    );
  }
}

const Home = () => {
  return (<div> Navigating to the protected route gets redirected to /login </div>);
}

const Contacts = () => {
  return (<div> Contacts </div>);

}

const ContactsWithAuth = withRouter(withAuth(Contacts));


export default ProtectedRoutesDemo;

withAuth checks if the user is authenticated, and if not, redirects the user to /login. We've used withRouter, which is a react-router entity. Interestingly, withRouter is also a higher-order component that is used to pass the updated match, location, and history props to the wrapped component every time it renders. 

For instance, it pushes the history object as props so that we can access that instance of the object as follows:

this.props.history.push('/login');

You can read more about withRouter in the official react-router documentation.

Accessing the Instance via Refs

React has a special attribute that you can attach to a component or an element. The ref attribute (ref stands for reference) can be a callback function attached to a component declaration.

The callback gets invoked after the component is mounted, and you get an instance of the referenced component as the callback's parameter. If you are not sure about how refs work, the official documentation on Refs and the DOM talks about it in depth.

In our HOC, the benefit of using ref is that you can get an instance of the WrappedComponent and call its methods from the higher-order component. This is not part of the typical React dataflow because React prefers communication via props. However, there are many places where you might find this approach beneficial. 

RefsDemo/RefsHOC.jsx

const withRefs = WrappedComponent => {
    return class Refs extends Component {

      constructor(props) {
          super(props);
      	this.state =  {
      		value: ''
      	}
      	this.setStateFromInstance = this.setStateFromInstance.bind(this);
      }
    /* This method calls the Wrapped component instance method getCurrentState */
    setStateFromInstance() {
			this.setState({
				value: this.instance.getCurrentState()
		  })

	 }

	  render() {
		return(
			<div>
		{ /* The ref callback attribute is used to save a reference to the Wrapped component instance */ }
		    <WrappedComponent {...this.props} ref= { (instance) => this.instance = instance } />

			<button onClick = {this. setStateFromInstance }> Submit </button>

			<h3> The value is {this.state.value} </h3>

			</div>
		);
      }
	}
}

RefsDemo/RefsDemo.jsx

const RefsDemo = () => {

  return (<div className="contactApp">

      <RefsComponent />
    </div>
    )

}

/* A typical form component */

class SampleFormComponent extends Component {

  constructor(props) {
    super(props);
    this.state = {
      value: ''
    }
    this.handleChange = this.handleChange.bind(this);

  }

  getCurrentState() {
    console.log(this.state.value)
    return this.state.value;
  }

  handleChange(e) {
    this.setState({
      value: e.target.value
    })

  }
  render() {
    return (
      <input type="text" onChange={this.handleChange} />
    )
  }
}

const RefsComponent = withRefs(SampleFormComponent);

The ref callback attribute saves a reference to the WrappedComponent.

 <WrappedComponent {...this.props} ref= { (instance) => this.instance = instance } />

this.instance has a reference to the WrappedComponent. You can now call the instance's method to communicate data between components. However, use this sparingly and only if necessary. 

Final Demo

I've incorporated all the examples in this tutorial into a single demo that you can use below. 

Summary

This is the end of the second tutorial on higher-order components. We learned a lot today about different HOC patterns and techniques, and went through practical examples that demonstrated how we could use them in our projects.

In the third part of the tutorial, you can look forward to some best practices and HOC alternatives that you should know of. Stay tuned until then. Share your thoughts in the comment box.