Hacker News new | ask | show | jobs
by kaoD 2694 days ago
> The fact that you can build complex interface logic and bundle it into a function that can then be extended and composed is a huge leap forward.

Unless you already used HOCs (in the Recompose sense).

Every single blog post is obsessed with comparing hooks with classes (I guess because it's the only thing they improve upon). What about HOCs? I'm not sure hooks are really that much of a leap forward compared to them.

HOCs only wart is their pollution of props which admittedly hooks solve (by virtue of using local variables), but hooks have their own warts too as evidenced in this article.

2 comments

Hocs had several problems, they couldn't access context, re-using one result in another is hard, they create a new component for every thing you want to do, etc.

Take this example for instance: https://codesandbox.io/embed/26mjowzpr

It measures out the view, reads out media queries, uses the results to construct a grid, uses a hook to turn it into an animatable, and just spits out the view as if nothing happened. All of this in the same component, with small, re-usable utility functions tapping into the host-components lifecycles. Just by looking at it you know what it's doing.

This is how a component should behave from now on, an entity that hooks into the host, instead of a class the host calls into. In my experience this is the first time you can express logic linearly: x > y > z > view, without wraps, inversion of control and DI.

Now imagine doing this with hocs ... even stacking two is already destroying any hope of guessing what's going on.

As someone who uses Typescript, HOCs are a nightmare, and hooks are a world of difference.