React - should Higher Order Component be written as a function?

Question

I'm learning React. It seems to me that HOC like the following example from React's official docs:

function withSubscription(WrappedComponent, selectData) {
    // ...and returns another component...
    return class extends React.Component {
        constructor(props) {
            super(props);
            this.handleChange = this.handleChange.bind(this);
            this.state = {
                data: selectData(DataSource, props)
            };
        }

        componentDidMount() {
            // ... that takes care of the subscription...
            DataSource.addChangeListener(this.handleChange);
        }

        componentWillUnmount() {
            DataSource.removeChangeListener(this.handleChange);
        }

        handleChange() {
            this.setState({
                data: selectData(DataSource, this.props)
            });
        }

        render() {
            // ... and renders the wrapped component with the fresh data!
            // Notice that we pass through any additional props
            return <WrappedComponent data={this.state.data} {...this.props} />;
        }
    };
}

can be rewritten in this way:

class WithSubscription extends React.Component {
    constructor({ component, selectData, ...props }) {
        super(props);
        this.handleChange = this.handleChange.bind(this);
        this.state = {
            data: selectData(DataSource, props)
        };
    }

    componentDidMount() {
        DataSource.addChangeListener(this.handleChange);
    }

    componentWillUnmount() {
        DataSource.removeChangeListener(this.handleChange);
    }

    handleChange() {
        this.setState({
            data: selectData(DataSource, this.props)
        });
    }

    render() {
        return <component data={this.state.data} {...this.props} />;
    }
}

Then use it like this:

<WithSubscription component={BlogPost} selectData={(DataSource) => DataSource.getComments()} />

Are they both HOC? When is one style preferred than the other?

Answer 1

I was struggling with HOC too at first. Another way of looking at this is at wrappers of components that you could use to isolate the functionality from one component.

For example, I have multiple HOC. I have many components that are only defined by props, and they are immutable once they are created.

Then I have a Loader HOC Component, which handles all the network connectivity and then just passes the props to whatever component is wrapping (This would be the component you pass to the HOC).

The loader does not really care which component it is rendering, it only needs to fetch data, and pass it to the wrapped component.

In your example, you can actually accomplish the same, however it will become much more complex once you need to chain multiple HOC.

For example I have this chain of HOCs:

PermissionsHOC -> LoaderHOC -> BorderLayoutHOC -> Component

First one can check your permissions, second one is loading the data, third one is giving a generic layout and the forth one is the actual component.

It is much easier to detect HOCs if you realize that some components would benefit from having a generic logic on the parent. You could do the same in your example, however you would need to modify the HOC every time you add a child component, to add the logic for that one. Not very effective. This way, you can add new components easily. I do have a Base component which every component extends, but I use it to handle the helper functions like analytics, logger, handling errors, etc.

Answer 2

The second one is not a HOC.

They coin the word HOC from higher order functions. One example of a higher order function is a function that takes a function as an argument and returns another function.

Similarly, a HOC is a function that takes an component as argument and returns another component.

This does sound weird to me because a higher order component is not a react component; it is a function instead. I guess the reason they call it HOC is because:

A react component is a class, which is indeed a constructor function in JavaScript (except that functional components are simply functions). A HOC actually takes a function (a constructor function) and returns another function (another constructor function), so it is actually a higher order function if you think about it. Probably because it is in the react context and this is a pattern to transform components, they call it HOC.

As to the difference between the two styles you mentioned:

First one: you would use the first one to generate a class like MyComponnet = withSubscription(AnotherComponent, ...), and whenever you need it in a render call just write <MyComponent><MyComponent>

Second one: this is less common. Every time you need it in a render call, you would need to include the WithSubscription component as you mentioned in the description <WithSubscription component={BlogPost} selectData={(DataSource) => DataSource.getComments()} />

Answer 3

What they call an "HOC" is basically a function (just a regular function, not React specific) that behaves like component factory. Meaning it outputs wrapped components that are the result of wrapping any inside-component of your choice. And your choice is specified with the "WrappedComponent" parameter. (Notice how their so-called "HOC" actually returns a class).

So I don't know why they called it an "HOC" tbh. It's just a function that spits out components. If anyone knows why I'd be interested in hearing the reason.

In essence their example is doing exactly what you're doing, but it's more flexible because WrappedComponent is being taken in as a parameter. So you can specify whatever you want.

Your code, on the other hand, has your inside component hard coded into it.

To see the power of their example, let's say you have a file called insideComp.js containing:

import withSubscription from './withSubscription';

class InsideComp extends React.Component{
// define it
}

export default withSubscription(InsideComp);

And when you use insideComp in another file:

import myComp from './insideComp.js';

You're not actually importing insideComp, but rather the wrapped version that "withSubscription" had already spit out. Because remember your last line of insideComp.js is

export default withSubscription(InsideComp);

So your InsideComp was modified before it was exported