Hacker News Reader

Comment by patientplatypus | Hacker News Reader

I don't get it. I thought the main appeal of functions were that they were stateless so you had immutability. We already have classes if we want state, so why is this an improvement? Functions have slightly less overhead maybe? But then why didn't the React team just work on making classes have less overhead? It seems sort of "extra".

View on HN

You should think about it in is this way - class components do not actually control its state. Using classes is just a convention supported by React that allows components to express their intention about what state they should have and how it should be updated, so it is just a form of interface. And hooks is a different way to interact with same underlying subsystem of the React, but they allow you to abstract, reuse and compose the logical parts of the interaction with the state.

I've been working with hooks for quite a while now; its main benefit is composability - before hooks up you rely on Higher order components (HOCs, HOFs but in component rendering) to provide composability of component behaviour - this is messy, very messy, and not performant.

By using hooks the logic tidies up massively (so working on it becomes a lot quicker) and several hard to diagnose performance bottlenecks disappear.

The 'not classes' stuff is a side benefit.

Can you please give some example of behaviour that you share across components that couldn't be factored out into a function?

https://overreacted.io/making-setinterval-declarative-with-r... is the article that solidified hooks as a useful concept for me.

They can always be factored out into a function, after all, both HOCs and hooks are functions. One big (or at least obvious) benefit of hooks over HOCs is the fact that they can be composed without the possibility of prop name conflicts.

Well they can, except that function needs state as a parameter or calls from lifecycle, which means changing many places inside the component to have that state as well as call that component.

A HOC previously served as a minimally invasive way to compose these behaviours (compose the HOC + use its param in render).

If you are writing a moderately complex animation, you can quickly end up needing state, willMount, and willUnmount, plus the render change plus the logic, thats five places in a class. If this animation applies to many components you abstract to a HOC and simplify dev overhead at a performance cost.

Using a hook lets you abstract that all into one function as you suggest.

Most of the HOCs I wrote had to do with just local state + store state + logic, so not as extreme (editable, updatable, draggable, deletable etc.); but when you have many, the penalty adds up.

I tried to explain it here.

https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

Hope it helps!

I'd encourage you to read through the Hooks docs [0], which explain the motivations, and Dan Abramov's posts on some of the internals [1] and what problems they're meant to solve [2].

[0] https://reactjs.org/docs/hooks-intro.html

[1] https://overreacted.io/why-do-hooks-rely-on-call-order/

[2] https://dev.to/dan_abramov/making-sense-of-react-hooks-2eib

For the vast majority of web apps, you’re going to need state that changes over time. Making individual components immutable is a nice architecture choice for several reasons, and hooks doesn’t really change that. Hooks just provide a way to plug state (which can change over time) into your components, which is something you already had to do. Where you were previously using class components, HOCs, or render props, you can now optionally use hooks, which have some well-documented advantages.

I can't speak for everyone, but the reusability with custom hooks looks really nice and better readability than using say HOCs.

Not specific to React, but with CommonJS modules you can use module scope instead of global scope to get private methods and variables, which the function can access via the closure.

    var foo = 1;
    var bar = x => x++;
    module.exports = function baz() { return bar(foo) }

I find this much more simple then classes. I even consider it an anti-pattern to make a class for something this simple.

That gets you a single instance, but the whole point of React components is that you can use them lots of time and each will do its own instance of the thing.

The next dev that comes along and naively imports your module into another part of the app will waste their time trying to figure out why foo keeps getting overwritten by the second instance.

It's no longer about function. It's a component that happens to use `function` as an implementation detail.

To add to the other answers, the type-ability of hooks is so much nicer. useContext means I'm going to be using context a lot more in TypeScript code now that I don't have to add a bunch of type definitions to every component I want to use it in.

Closures are poor man's objects and vice versa.

Reply on news.ycombinator.com