Stacking Higher-Order Components

In React, a set of props can flow from one wrapper component to another to another, down a practically limitless chain, receiving modifications from each component. This creates infinite possibilities for combining HOCs. Extracting small pieces of functionality into HOCs, instead of allowing components to grow in complexity, is an important skill for keeping a React codebase manageable.

In this section, you’ll add a new feature to Carousel: the ability to auto-advance the slideIndex on Carousel with a timer. All of the timer logic will be encapsulated in a new HOC.

Working with Timers

Let’s create a new HOC called AutoAdvances. It’ll be designed to work inside of a HasIndex, calling the increment function it receives after a certain time interval. The interval will be specified by a prop with a default value of, say, 10 seconds. The HOC should take two arguments, specifying which prop it should increment and which it should use to compute the upper bound for the increment function. The internal timer will reset every time the target prop (e.g., slideIndex) changes so that the carousel doesn’t auto-advance immediately after the user switched slides using the “Prev” or “Next” buttons.

Start by creating a dummy implementation:

Then formalize the HOC’s requirements as a suite of tests. For the sake of brevity, all of the tests are presented at once below. If you’re trying to practice TDD, you should add one test at a time, then modify the implementation to make that test pass before adding the next one:

​①​

10e3 is scientific notation for 10 followed by 3 zeros, i.e. 10,000. This is a handy way to express the value “10 seconds” in milliseconds, the standard unit for timers in JavaScript.

​②​

Using real timers would make our tests painfully slow, so Jest offers the ability to mock out the native timer functions with jest.useFakeTimers().^[67] Calling it before each test ensures that the timer state is reset.

​③​

When using fake timers, you need to manually “advance” them with jest.advanceTimersByTime(). For example, a simulated 10s timer will go off after one or more jest.advanceTimersByTime() calls adding up to a total of 10s.

​④​

It’s important to ensure that timers are cleaned up when components are unmounted. Enzyme’s unmount() simulates this, invoking the component’s componentWillUnmount() lifecycle method.

Now you have all the tests you need. Before you go on, you might want to brush up on React lifecycle methods.^[68] This implementation will make use of componentDidMount(), componentDidUpdate(), and componentWillUnmount():

​①​

The logic here compares the current value of the target prop to the previous value (that is, the value before the update that triggered componentDidUpdate()) and calls startTimer() if the value has changed. Likewise if the upper bound prop value has changed.

​②​

When a component uses timers that should only fire if the component remains mounted, it should clear those timers in componentWillUnmount(). The underscore prefix for the timer handle, this._timeout, is a common convention for locally bound variables on component instances.

​③​

Clearing any existing timer at the start of startTimer() ensures that only one timer is ever pending.

​④​

Here, upperBound is allowed to be either a numeric value or the length of an array. In the case of Carousel, we know the upper bound will always be computed as slides.length, but allowing a number gives the HOC more flexibility.

Ready for a commit:

Testing Multiple Higher-Order Components

Adding the new auto-advance functionality to Carousel should be a simple matter of importing the new AutoAdvances HOC and inserting it between the HasIndex wrapper and the core component:

But how do you use tests to confirm that all of these parts are wired together the way you expect? shallow() is ill-suited to this task. This calls for mount():

​①​

One of the biggest “gotchas” in Enzyme’s mount() is that a component’s state changes don’t cause its tree to re-render. So whenever you want to test that the mounted tree changes in response to some event, you’ll need to manually call update().^[69]

With those tests green, you can commit with confidence:

That concludes the coding portion of this chapter. You’ve successfully used HOCs for both refactoring and keeping new features in isolation, preventing complexity sprawl. Before the chapter concludes, we’ll take a brief look at the components you’ve built from another angle.