Hacker News Reader

Comment by el_dev_hell | Hacker News Reader

Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability.

The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.

View on HN

I actually think that useEffect is an amazing abstraction. It lets you group related functionality like subscribing and unsubscribing into one place and makes it very difficult to leak stuff or use stale values.

I didn’t write many class components beforehand though, so my mental model didn’t have to change all that much.

I wrote a lot of class components and getting used to effects was a 2-week-long headache for me. But then it clicked and I can't go back ever again. Hooks are really nice abstraction. However, sometimes I would like people to name their effects: `useEffect(function clickHandler() {})`, but I understand it looks ugly.

Same experience, I've started working with React when Hooks were introduced in a greenfield project. My last experience with JavaScript was jQuery and Angular 1. I was blown away by the functional-declarative approach of React Hooks, I can't believe that people haven't used it before.

I don't disagree that useEffect is a great extraction overall. But the mental load to understand it vs. explicit lifecycle methods is significantly worse.

The ability to subscribe is indeed amazing (this was much more verbose in class components).

agreed. transition from classes to hooks and useEffect was confusing at first but it now seems very predictable and sensible (does get a little hairy when you have one effect dependent on another).

just started writing my own named effects (eg useAuth() for encapsulating firebase auth) and still in a bit of an uncanny valley with doing that - but again it's very logical once you get used to it and actually in the end a simpler mental model of component state.

never want to go back.

junior devs, start with useState, it'll all flow from there.

As someone familiar with the old react API, I agree 100% about useEffect being super arcane.

There's just too much magic going on, which is the same thing that makes me reluctant to write Vue or Svelte (after reading this)

If you use `<script setup>` in Vue, yeah it's some compiler magic similar to Svelte, but otherwise that's not really the case, for example Vue tracks depdendencies using ES6 Proxy, which is just a language feature.

I agree, but it can be made easier by exposing named functions that help like useUnmount

https://github.com/streamich/react-use/blob/master/src/useUn...

Why do you think it's terrible?

Overloading the meaning of native language features is not the most beginner friendly. It’s a quirk you just have to remember.

Compared to an explicit method name it is much less intuitive.

Nothing about its usage implies what it actually does. It's about API affordances. You can't simply just read the code as someone inexperienced with React and say "oh, I know what this does". Returning a closure as the result of another closure has no inherent meaning as to when that closure would be called, because there's no "name" for that functionality.

And don't even get me started about the dependencies array, which has different behaviour whether you omit the argument, or pass an empty array, or pass actual `useState` dependencies, or pass other unrelated variables. Again, it's something you just "need to memorize" to use React.

If I hadn't been using React for many years before they introduced useEffect and various other hooks, they would have all been incredibly confusing. They still are really confusing when used in "clever" ways, especially with developers being allergic to writing comments. Even something as simple as `// this will do X when the component unmounts` make reading usages of useEffect 10x easier (vs. having to remember what happens when you return a function)

Sometimes I do miss the simplicity of componentDidMount... I guess you can always still write class-based components. Too bad they're not in vogue anymore! Feels like every library is hooks-based these days.

Totally agree re comments. They're necessary. Hooks do have huge advantages for composability and flexibility, and that can't be denied. But the API is just so arcane.

If my company wasn't a React shop, I'd probably be using Vue. I used Vue at my previous company and liked it a lot.

Headless libraries like `react-table` that use hooks are a revelation though. So nice to get pretty much all the behaviour you could ever need, without it making UI decisions for you. Difficult to use at first and wrap your head around, but hoo boy is it great to have the power to fully control the rendering!

It's very easy to convert a hook to a HoC, purely wrapping that functionality in a class component.

Also true. It just seems like `class` has become a bit of a dirty word, at least the last two places that I've worked on React codebases.

I agree it has. I think this is because hooks have been talked about by facebook as the future of react. There seems to be no appetite for class based react improvements in the future. No wonder people move to the thing that will be better supported, regardless what it is.

Reply on news.ycombinator.com