Day 21: something I like to call Chrismukkah

Welcome to the (H)OC

I’m gonna level with you, I don’t know to explain higher-order components to you. I work in analogies and there just isn’t one for HOCs.

HOCs are like bacon-wrapped dates, where bacon is functions and dates are components, and bacon harvests dates for the wrapped dates to shove inside themselv…

WHAT DA?!

Yeah, no good analogies. Read the docs.

The good news

The good news is that most HOCs share a basic skeleton.

Using our language from yesterday, here’s a HOC named withKnowledge.

function withKnowledge(UnkowingComponent) {
  class KnowingComponent extends React.Component {
    state = { knowledge: "Things I know" }

    render() {
      return (
        <UnkowingComponent
          {...this.props}
          knowledge={this.state.knowledge}
        />
      )
    }
  }
}

withKnowleding wraps our knowing component in a function that takes an unknowing component as an argument and smooshes them together.

Bring your own “knowledge” and you know everything you need to about HOCs.

Why though?

Higher-order components are another way of uncoupling components. Many popular libraries use them.

I think there are only a couple reasons to use them and you’ll likely never run into one in regular app code.

Tinker with it

Explore the code below. I’ve used the higher-order component pattern to uncouple FetchPokemon from Pokemon. It’s now withPokemon().

Can you change it to use a render prop? Which do you prefer?