Making Higher-Order Components

In the abstract, a higher-order component is defined as any function that takes a component and returns another component. Typically, the component returned by the HOC function is a wrapper around the original component that adds functionality. Here’s a simple example:

​①​

The BindProps HOC takes two arguments, a component and a props object to “bind” to that component.

​②​

Since the boundProps passed to the HOC are spread into the component after the props passed directly, the boundProps take precedence.

​③​

displayName is a special property that gives React components a name for debugging purposes. We haven’t had to deal with it so far because JavaScript functions and classes have a name property that usually works as a fallback. But for a dynamically generated component like this one, you’ll need to set the name manually. Using a name of the form "HOC(Component)" is a common convention.

​④​

Here BindProps is used to generate a component that behaves exactly like Carousel, except that it will always receive data-test-id="carousel".

In the next section, you’ll build an HOC to manage an index, like the slideIndex in Carousel. Then you’ll refactor Carousel to make it a stateless component using that HOC.

Creating a Higher-Order Component

Open the test-driven-carousel project from the previous chapter and take a look at the Carousel component. In addition to rendering a somewhat complex DOM tree, it also has one piece of state and two event handlers that manipulate that state. Let’s try building an HOC that encapsulates that logic.

Well-implemented HOCs tend to be highly reusable, and this one will be no exception. It’ll manage the state for any component that has an “index” prop, meaning a number that can go from 0 up to some limit. Call it HasIndex. Start with a minimal dummy implementation that you can run tests against:

To replace the slideIndex logic in Carousel, we need HasIndex to provide three props to the wrapped component: the index itself (with the given indexPropName), an increment function, and a decrement function. To support wrap-around, the increment and decrement functions should accept an upper bound argument. Write a test suite with those requirements:

Then try modifying the implementation to meet those requirements. You should end up with something like this:

Now that all of HasIndex’s tests are green, this would be a good time to commit your work:

Refactoring with Higher-Order Components

With HasIndex, you can now make Carousel a stateless component. Instead of having an initialState and performing setState operations, Carousel will receive slideIndex as a prop and use the slideIndexDecrement and slideIndexIncrement props to update that value.

This change will make the “core” of Carousel simpler (especially as you add new features related to the slide index), but it complicates the shallow testing story. Up to now, Carousel has been a single component that contains all of its own logic. Now it will, in effect, be two components. You’re going to need three types of test to achieve full coverage:

1. Tests for the component generated by HasIndex (which you already have)
2. Tests for the core Carousel component
3. Tests to ensure that the core and the HOC are properly wired together

Start by modifying Carousel.js so that it exports both the core Carousel component and, as the default export, a HasIndex-wrapped version:

In Carousel.test.js, you’ll need to import and test both components. Since the component wrapped with HasIndex is the one that your library’s users will consume, import it as Carousel, and import the unmodified component as CoreCarousel:

The tests in the describe(’component with HOC’, ...) block only need to verify that the core component is correctly wrapped by HasIndex, since you already have solid test coverage for HasIndex itself. An effective way to confirm that is to check that the core component receives both the props generated by the wrapper component and the props passed to the wrapped component:

The describe(’core component’, ...) block should be essentially the same as the old Carousel tests, except the tests need to deal with slideIndex as a prop instead of state:

​①​

jest.fn() creates a mock function, a function that keeps track of calls to itself.^[64]

​②​

expect(mockFunction).toHaveBeenCalledWith() is an assertion that verifies that mockFunction was called with the given arguments.

With the tests updated, you’re ready to implement the refactoring:

​①​

We don’t want slideIndexDecrement and slideIndexIncrement to be part of the rest props, since those are passed through to the DOM. Instead, this code pulls them out as variables prefixed with the underscore character, _. The underscore prefix is a convention that we’ll make use of momentarily.

ESLint isn’t too happy about the _slideIndexDecrement and _slideIndexIncrement variables this code creates as a side effect of keeping those props out of the rest spread. But this is the best available pattern. So, let’s modify the linter rules to ignore unused variables whose names start with an underscore:

There! The linter is happy. More importantly, you’ve successfully made Carousel a stateless component, with its state logic extracted to a reusable HOC. Time to commit your work, using the recommended gitmoji for refactoring:

This is a powerful refactoring. In the rest of the chapter, you’ll take advantage of this structure to add two new features to Carousel without making any modifications to the core component.