Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frustrations with React Hooks

blog.logrocket.com

Post reply on HN
Print view View original

31–40 of 139 posts

Re: Frustrations with React Hooks

#31

Post by bcyn »

bcheung wrote: post #30

Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved. But hooks creates abstractions the developer needs to deal with that never existed before. Hooks are not functional because they break referential transparency of functions. You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivale…

> You can't create abstractions where a hook calls another hook.

Not sure if I understand you correctly, but isn't this the purpose of custom hooks? You should be able to freely call hooks within other hooks.

Re: Frustrations with React Hooks

#32

Post by k__ »

The dependency array is the single most important improvement that hooks bring over lifecycle methods.

You're component gets rerendered when the array changes and not when you got the right mix of lifecycle methods going.

But yes, it's not always obvious what changes you really care for.

Re: Frustrations with React Hooks

#33

Post by wokwokwok »

bestest wrote: post #11

I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand. OP seems to be a bit stuck in a hole. If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. B…

That seems a bit unfair.

There are some weird edge cases with useEffect, no question.

I don’t think they’re bad enough to want to go back to using classes... but I think the OPs post was a bit more specific than you’re giving them credit for, and they stuff like useAsyncEffect exists because it is a common pain point.

For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha

The behaviour is weird sometimes; just because you can use the trivial use case easily doesn’t mean you won’t stumble, and if you do, good luck trying to understand what went wrong.

> ...they're very simple to understand...

They’re not simple.

They just superficially appear simple, which is good enough most of the time.

I think it’s entirely fair to complain that’s not ideal... even if you still think there’s a major benefit to the trade off compared to classes (which I do think is true too).

...but I’m very sympathetic to people hitting edge cases.

Re: Frustrations with React Hooks

#34

Post by peternicky »

Not to sound like a jerk but I cannot help but think this dude is whining about very petty issues. I read the article and found it to contain very weak arguments.

I totally can relate to the frustration when learning new stuff, especially when you have done things one way for years. Personally, the first month or so that I used hooks in react, it wasn’t pleasant, mostly due to me being uncomfortable with the additional load of learning this new convention.

Suck it up buttercup ;)

Re: Frustrations with React Hooks

#35

Post by jtreminio »

bestest wrote: post #11

I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand. OP seems to be a bit stuck in a hole. If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. B…

We're slowly refactoring our class-heavy React app to functional components with hooks.

One thing we haven't been able to replace, though, are classes that depend on refs. How to do this, since there's no instance with functions like there are with classes?

Re: Frustrations with React Hooks

#36

Post by Normal_gaussian »

bcyn wrote: post #31
bcheung wrote: post #30

Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved. But hooks creates abstractions the developer needs to deal with that never existed before. Hooks are not functional because they break referential transparency of functions. You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivale…

> You can't create abstractions where a hook calls another hook. Not sure if I understand you correctly, but isn't this the purpose of custom hooks? You should be able to freely call hooks within other hooks.

You absolutely can create abstractions where a hook calls another hook. It is perhaps the single most useful change hooks have given me.

Of course you need to follow the same rules in the hook (always call every hook it calls, in the same order, so you don't mess up the order above).

Re: Frustrations with React Hooks

#37

Post by shantly »

bcheung wrote: post #30

Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved. But hooks creates abstractions the developer needs to deal with that never existed before. Hooks are not functional because they break referential transparency of functions. You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivale…

> The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available.

IIRC it's because they implemented their own method lookup table (!) to associate with the Component object (!) but as a FIFO queue, more or less. I assume either for ideological (that's how they wanted it to work) reasons or because they (probably correctly) reasoned that loading down React apps with more strings at such a basic level would risk performance/memory problems. Plus if they did that then it'd really look like a method lookup table and be more obviously Rube-Goldbergian than it already is.

Re: Frustrations with React Hooks

#38

Post by bcyn »

wokwokwok wrote: post #33
bestest wrote: post #11

I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand. OP seems to be a bit stuck in a hole. If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. B…

That seems a bit unfair. There are some weird edge cases with useEffect, no question. I don’t think they’re bad enough to want to go back to using classes... but I think the OPs post was a bit more specific than you’re giving them credit for, and they stuff like useAsyncEffect exists because it is a common pain point. For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-…

> For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha

On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default.

In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref.

[1] https://github.com/facebook/react/issues/14387#issuecomment-...

Re: Frustrations with React Hooks

#39

Post by bcyn »

jtreminio wrote: post #35
bestest wrote: post #11

I absolutely love hooks and don't want to use the `React.Component` class ever again. And yes, hooks need to be grasped, they're quite something else. But once you get the hang of hooks, they're very simple to understand. OP seems to be a bit stuck in a hole. If you end up in a situation where your hooks come loose and the code becomes a mess — just delete them all and rethink your code / component logic structure. B…

We're slowly refactoring our class-heavy React app to functional components with hooks. One thing we haven't been able to replace, though, are classes that depend on refs. How to do this, since there's no instance with functions like there are with classes?

useRef was designed for this purpose: https://reactjs.org/docs/hooks-reference.html#useref

If you ran into something that isn't quite covered by this hook, I'm also curious! Can you write a minimal example in codesandbox and share?

Re: Frustrations with React Hooks

#40

Post by acemarke »

shantly wrote: post #37
bcheung wrote: post #30

Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved. But hooks creates abstractions the developer needs to deal with that never existed before. Hooks are not functional because they break referential transparency of functions. You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivale…

> The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available. IIRC it's because they implemented their own method lookup table (!) to associate with the Component object (!) but as a FIFO queue, more or less. I assume either for ideological (that's how they wanted it to work) reasons or because they (probably correctly) reasoned that loading…

The primary concern was transparent composition and enabling "custom hooks". All of the "named/keyed hooks" proposals from the community failed that test.

Custom hooks naturally fall out of the current implementation. Technically, React doesn't even know that custom hooks exist - it just knows that more of the primitive hooks are being called inside your own component.

If you've got time, skimming the original React Hooks RFC https://github.com/reactjs/rfcs/pull/68 ) is informative (and admittedly difficult, because there's hundreds of similar comments).

Post reply on HN