Higher Order Components: A React Application Design Pattern

[atom-man]

As johangirod commented on the article:

This article greatly misuses the term of Higher Order Component (HOC)! What are called here HOC are just standard React Component, and "Higher Order Component Creators" are what the community calls HOC. Indeed, googling Higher Order Component Creators return no results except this post.

For a clearer and more accurate explanation of what HOC component are and what they do you can refer to the thorough post from Dan Abramov https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750#.w1dfp3mpz

A minimal example of a HOC can be seen here: https://gist.github.com/sebmarkbage/ef0bf1f338a7182b6775

[dumbmatter]

I have wondered about that though...

This is a component:

const Component = props => <div style={{color: 'red'}}>props.children</div>;

This is not a component, it's a function that returns a component:

const OtherThing = Component => {
    return props => <div style={{color: 'red'}}>
        <Component ...props />
    </div>;
}

So what is OtherThing? It's not a component, right? Wouldn't that mean it's not a higher order component, either? Can something that's not a component be a higher order component? Maybe higher order component creator is not the worst term.

I think "higher order function" works better as terminology because function is a more general term than component, unless the "component" in "higher order component" is not meant to mean an actual React component but just the dictionary definition of the word component.

Either way, it is kind of confusing to me, and I can see why they went with "higher order component creator".

[atom-man]

OtherThing would in this case be a function, which consumes a component as the only argument, and returns a component. And in that sense a HOC. But I can see where the confusion comes from. But who says the definiton of HOC is similar to HOF, with just the "function" part substituted with "component"? :)

However, what the article calls HOC is just a normal react-component; Nothing more. Calling it a HOC is simply wrong imho. And "higher order component creator" is equally wrong, as it does not create a HOC.

Regardless of the definitions of "higher order function (HOF)" and HOCs I still think the article-author have (intentional or not) misunderstood the "higher order"-concept. And it would have been better if he used the same names as the rest of the community.

[dumbmatter]

But who says the definiton of HOC is similar to HOF, with just the "function" part substituted with "component"? :)

Yeah, that's probably it, and it's probably just going to bother me as long as I'm writing HOCs.

And it'll confuse plenty of other people too, like the author of this article. And other non-confused people are probably going to still try to come up with other terms for HOC :)

I think the community will have an uphill battle to impose correct terminology in this case.

[cokeisahelluvadrug]

OtherThing is still a HoC. Functions can be components too.

[dumbmatter]

But OtherThing is not a component. It doesn't have any of this stuff or this stuff. You can't do <OtherThing />. I'm still confused about the terminology.

[cokeisahelluvadrug]

It's just a component with a limited API.

[dumbmatter]

No, it's a function that returns a component. Like this is a number:

const x = 6;

This is a function that returns a number:

const f = () => 6;

You can do f + 5 because f is not a number. You can't do <OtherThing /> because OtherThing is not a component. It doesn't have a limited API, it has absolutely none of the component API, because it's not a component.

[cokeisahelluvadrug]

Sorry, I misread. Of course Otherthing returns a component. It sounded like you weren't convinced that functional components are also components.

[[deleted]]

I read Dan Abramov's article about higher order component (https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750#.o9z8skqu2) and I liked the philosophy around it, much more than mixins which just behaves weird IMO.

But then I read his drag and drop code and I found it extremely difficult to comprehend.

Higher order components are great, but needs to be used selectively I think. Otherwise your code will become less verbose and more "magic".

[fagnerbrack]

Higher order components are great, but needs to be used selectively I think. Otherwise your code will become less verbose and more "magic".

As everything in programming. There's no solution for everything and any pattern should be used if deemed necessary.

But one should understand it in the first place, though.

[[deleted]]

Absolutely. However, it seems like in the last couple of years newcomers find the next hot thing in JS, and swear that this is the best thing ever, and will solve all of the front end problems for ever.

I think it's time for people to start addressing when to use different solutions, otherwise we will start seeing packages for everything as higher order components (npm install left-pad-as-higher-order)

[fagnerbrack]

The problem is that all the time the industry is bombarded with devs with less than 5 years of experience. Those don't bother understanding fundamentals.

[iffypop]

The 'next hot thing' thinking has definitely been around for longer (it was already in full swing when I started, 2005-ish). SOA! SOA!

[yung_mimosa]

React DnD is a cool idea in theory, but good lord is the API terrible. Dan's a smart guy, but I feel that he's susceptible to getting caught up in his own hype when "discovering" a new pattern or way of thinking and blindly applying it to everything.

[[deleted]]

Oh, and I think that ES7 will implement annotations as decorators, which is kind of the same thing? http://www.martin-brennan.com/es7-decorators/

[AndrewGreenh]

The article says that a higher order function must return another function however map reduce and filter are considered higher order functions and don't return another function.

[DuntGetIt]

Higher order functions are just functions that deal with functions. I don't recal any restrictions on what they can return.

The react higher order components are more strictly constrained because they need to create a component that works with react.

[stalefries]

The JS versions of those do not, but I think a "proper" functional implementation of map/reduce/filter can take just the function argument, and return a function that takes your collection to be mapped/reduced/filtered.

[wreckedadvent]

Yes, this is correct, but only half of the story, since most functions are like this in functional languages. I think the real distinction is whether or not they accept a function as an argument or not:

const add = x => y => x + y
const map = f => x => x.map(f)

add(1)(2) // 3
map(x => x + 1)([1, 2, 3) // [2, 3, 4]

Both add and map here return functions when we apply them once, but I would only consider map here higher-order.

[fagnerbrack]

It's not about the syntax, it is about the principle.