Hacker News Reader

I agree, I think they took a left turn at Albuquerque trying to get into the state management game and honestly saying this as a person that likes FP for everything but UI components, I prefer objects when it comes to modeling UI's it's the one domain in which it fits without impedance mismatch. The problem is UI has state and state and it's management does not fit well with objects as it tends to be event, time and data dependent.

There are some good solutions to state management that are complimentary to React such as XState and it really should be dealt with as a separate concern from a UI component library.

I am concerned that React's object based approach is going to become a second class citizen in lieu of Hooks and that state management is going to get to hardwired to the UI component library.

Exactly. I'm a big believer that state-as-an-implementation-detail is a code smell, but that if your program is fundamentally concerned with state (as UIs nearly always are), you should equip yourself with tools that let you ergonomically manage that state instead of trying to sweep it under the rug and pretend it doesn't exist. Hooks feel like state-denialism to me.

> and that state management is going to get to hardwired to the UI component library

I don't really see how that's a different state of affairs than class-based components. You just do this if you wanted...

    const [thisState, setState] = useState({});

...and its uses would generally be semantically identical to state-based stuff without hooks.

I believe there are genuinely people who think of hooks as intuitive:

1. Hooks handle a lot more of React's lifecycle in a way that better matches how they're used

2. They allow more widespread usage of functional components. No more rewriting to and from classes while refactoring!

3. Concurrent mode all the things!

Unfortunately, the opposition to hooks has gotten lost in the sea of people trying to wrap their heads around it. It's also really easy to respond to criticism with "Just wait! Cool things are coming!". That's no fun for someone who has legitimate criticism and doesn't really see a way to voice those concerns.

It's a lot of what made me seriously consider other communities. React may be dominant, but gosh, at least I can roughly predict where other projects are going and can contribute in meaningful ways

> Is there anyone who would argue that React Hooks are "intuitive", or at least become that way after you've used them for long enough?

Yes. I've been using React for a while, started with class and functional components very close in time, and almost immediately found functional components with hooks far more intuitive than class components and lifecycle methods.

Of course, I also started programming before the mid-1990s OOP hegemony, and while I did use OOP early on my programming career, I also used lots of other paradigms early on, too. I think for people whose programming knowledge is entirely OOP, Class components and their lifecycle methods are probably more intuitive. Though given that React imposes unusual restrictions on state management in class components, that mean using usual OOP class design doesn't work for class components, I find even that a bit odd. React’s rules attached to hooks seem a lot less uncanny valley to me than React’s rules applied to classes.

IME, hooks get awkward mostly when a component is managing too much unrelated local state—which in a class component (or, really, even a functional one, though one associates this more with OOP) would mean you are flagrantly flouting the SRP. I actually find the friction that hooks provide in that case—which does seem to bite sooner than with class components—a welcome nudge to reassess responsibilities and refactor before the component becomes unmanageable. (And usually that involves moving more state management out of components and into, for the apps I work on, redux.)

People keep mentioning lifecycle methods, but I very rarely found myself using them. Those, too, were a code smell to me, especially if they caused side-effects in application state. I don't see them as an integral part of the class-component paradigm at all.

If you don't need lifecycle methods in class components, you probably don't need hooks much in functional components, since the most used hooks are direct substitutes for lifecycle methods.

I saw hooks more as a replacement for this.state/setState (or your state management library's equivalent). So if you've got a dropdown that can be either open or closed, for example. Is that not the case?

Well, useState/useDispatch is a substitute for that, useEffect is a substitute for most lifecycle methods, useMemo is a hybrid that is basically useState + useEffect for updates.

IME, useEffect is where the complications tend to arise (assuming you are using a state management library for non-local state, which seems to be the dominant approach even with functional components.)

I also prefer hooks. They give you the flexibility of mixins with a better composition story. And reusing hooks in my experience is more like a lightweight OOP style, compared to the somewhat clunky FP ceremony of higher order components, as the API makes it feel like I'm passing around instances of little state objects. The refactoring flow is also dead simple. I prototype behavior inline at the top of a render function, then just cut all that out to a reusable hook which I can then choose to move to props or context above the now dumb component, and factor out into smaller hooks as I wish. Slicing the behavioral model of a component up to jam into the class lifecycle methods was painful to me in comparison. The static analysis tooling also finds and allows auto-fixing of scores of dumb mistakes that used to catch me at runtime when using classes or HOCs. My experience with hooks actually got me more interested in learning ReasonML & Elm!

Sure, I've developed React apps since it first appeared, and hooks I find to be by far the most intuitive API. They work closer to how I understand React to work internally, with minimal boilerplate. The things I find annoying about React were an annoyance before hooks (mainly to do with async). I find the code written with hooks cleaner, easier to read and write, less ceremony, less repetition, easier to test.

I realise some people don't like this API, find hooks unintuitive. But a huge amount of people like the hooks API and prefer it over the class-based one. It's not just a fad, it's just a nice API, it works pretty well.

> Is there anyone who would argue that React Hooks are "intuitive", or at least become that way after you've used them for long enough?

In my experience, they make life much, much easier than using class components as soon as you have any complicated amount of lifecycle management. A lot of componentDidMount, componentDidUpdate, componentWillUnmount, etc stuff collapses down into single useEffect statements, which you can then turn into your own hook wrapper if you're reusing functionality.

I guess I saw lifecycle methods as a code smell anyway. I pretty much only used them when I had to bridge the gap to some third-party code that didn't live nicely within my React/state management world, or when I was forced to do some manual DOM fiddling in one or two cases. Nothing related to my core logic or state would ever live there, so I never reached a point of "complicated lifecycle management".