HOA — Higher Order Apps

Higher Order Apps refers to the following pattern, in which foo, bar and baz are functions that take the app function and transform custom props into props app can work with.

baz(bar(foo(app)))({
  // Custom props!
})

or

app(baz(bar(foo({
  // Custom props!
}))))

That isn’t bad, but this would be much nicer!

app(foo)(bar)(baz)({
  // Custom props!
})

Now, that requires adding more bloat to core! 😭

So, what’s to do and can we find a middle ground?

Maybe!

compose(app)(foo)(bar)(baz)({
  // Custom props & profit!
})

The compose function can be implemented this way! ❤️

function compose(props, enhancers) {
  return typeof props === "function"
    ? enhancer => compose(enhancer, (enhancers || []).concat(props))
    : (enhancers || []).reduceRight((enhancer, reducer) => reducer(enhancer), props)
}

[SkaterDad]

I think this talk is relevant. Michael Jackson (of React-Router), advising against Higher Order Components, and I agree with most of his points. The arguments could apply to higher order apps in hyperapp, in my opinion. https://www.youtube.com/watch?v=BcVAq3YFiuc

I’m not sure I see the point in supporting higher-order apps? Is there a particular use-case in mind for this?

As @okwolf mentioned, you have to worry about merging props correctly. It re-introduces what mixins were doing to begin with, which seem to be on their way out? I can’t keep up 😕

[jorgebucaran]

@jacktuck Mixins are just as evil. That’s why we are moving away from them in #219! 🏄