Here is our Farm Component, written as a class.

I’ve exaggerated a bit to prove a point — how often are you actually implementing shouldComponentUpdate ?— but otherwise it’s a pretty typical component.

And this is the same component, written functionally. Note that I use some helpers from the aforementioned library, recompose. I’ll explain exactly how recompose works later on.

Or even better, using recompose/compose:

At first glance, the two different styles can seem extremely different — but they really do the same thing.

Let’s say you have a Workshop component. And it’s used on a separate view or even in an entirely different application. You’d be able to ‘steal’ all the business logic from the Farm component— you could pick and choose the smaller HOCs or grab the composed enhance HOC — without even breaking a sweat.

How would you do this in typical, class-based components? You can’t. This is what makes writing React functionally with HOCs so damn awesome.

Introducing recompose:

“Recompose is a react utility belt for function components and higher-order components. Think of it like lodash for React.”

That’s taken directly from the README . Simply put, it’s a useful collection of HOCs and helpers that blaze the trail for you to write high-quality, functional React code.

Let’s deep dive into some recompose code. I promise it’s quite approachable — it isn’t doing anything mega funky under the hood.

Recompose/mapProps (Edited for brevity. original)

import { createFactory } from "react" const mapProps = propsMapper => BaseComponent => { const factory = createFactory(BaseComponent) return props => factory(propsMapper(props)) }

You can use mapProps to ‘map’ the props coming in to your component before they get there. Let’s say our props look like this initially:

{routerProps: {location, query, hash}, tools, ...props}

But your component doesn’t care where the routerProps come from — it just needs them as they are. An example propsMapper could be:

const propsMapper =

({routerProps, ...props}) => ({...routerProps, ...props})

Nothing crazy, it just spreads the routerProps .

So to use mapProps you’d do something like this:

const myMapProps = mapProps(propsMapper) const myEnhancedComponent = mapProps(myBaseComponent) // alternatively, all in one go: const myEnhancedComponent = mapProps(propsMapper)(myBaseComponent)

I think you’re starting to get the hang of this whole higher order thing.

Now — recompose has some really useful HOCs. But they’re basic, general and won’t solve every problem specific to your application. No worries —you can and should roll your own Higher Order Components to suit your needs. We have hundreds in our codebase.

Here is an example of an HOC that I wrote called withStateOfTypeSet .

It’s useful for avoiding reimplementation of the same logic across many components that have to store some local state which belongs in a Set. For those unfamiliar with how Sets behave in JS —check out the MDN docs.

withStateOfTypeSet

I’m hoping the code is pretty self-documenting. It’s a nifty HOC which abstracts away some of the funky stuff you have to do when initialising or adding/removing from a Set . The only thing I should really explain here is that recompose/withHandlers adds functions to your component that are called with the most up to date props. Check it out.

The extent to which you can compose HOCs is endless. These are the building blocks with which your application is built.

So far — I’ve only showed learning examples. Whilst cool — they don’t really show what functional React can look like when taken to the extreme.

EXTREME REACT

Below is the default export for one of our biggest components. It has a lot of behaviour and is one of the uglier of the bunch. But all of its functionality is composed of many small buildings blocks. All the handlers are tiny functions. And the view logic is a stateless functional component that does nothing besides declare how the component should look.

You can take these ideas and go pretty deep

Now — I’ve written a whole chunk about the what. But let’s jump to the extensive and overwhelmingly positive why.

I won’t cover the benefits of writing functional code in general — of which there are many — as this article would turn into a sermon. But it’s certainly within scope to explore some of the React-specific upsides.

Intra-component code reuse is significantly more feasible

You can now share code between components without copy-pasting. This is probably the biggest win. Your codebase will be more succinct, you’ll only have to change business logic in one place rather than 10, and code will be infinitely more readable. Plus, it’s so much easier for new developers to grok smaller functions and components than to try and grok 500 line monsters.

Sorry Mr. 500 line Class component. Take a hike!

The effect is compounding once your whole codebase follows the same patterns. Because as time progresses — as it inevitably does — you’ll find that you’ve already done this new thing that you’re trying to build. And you’ve written 90% of the HOCs you need! So it’s just plug and play and then you can ship! 🚢 (Kidding, but optimistic delusions aside, sometimes it actually feels like that.)

Often, components you end up crafting are composed of 1-many HOCs wrapping some generic component such as a modal, a button, or a link.