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

81–90 of 139 posts

Re: Frustrations with React Hooks

#81

Post by tracker1 »

aidos wrote: post #76
csande17 wrote: post #64

Earlier quoted context omitted.

I'd argue that hooks didn't really make anything better, they just replaced the pitfalls with different obtuse pitfalls and unergonomic solutions. Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCa…

I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.

I don't quite get the obsession with the order of hooks... You call all the hooks in your component function and don't optionally do so. In the end, if you're optionally calling different hooks differently in the same component, you're probably doing something wrong, and/or they should be separate components.

Re: Frustrations with React Hooks

#82

Post by ssalka »

aidos wrote: post #76
csande17 wrote: post #64

Earlier quoted context omitted.

I'd argue that hooks didn't really make anything better, they just replaced the pitfalls with different obtuse pitfalls and unergonomic solutions. Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCa…

I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.

Coming from the FP world, hooks are a terror because they break all the nice rules functions are supposed to uphold. Hook components don't necessarily return the same value when given the same arguments, making them impure (stateful). The benefit of function components IMO has always been that you can use the function scope as a container for pure, stateless rendering logic. With the introduction of hooks I can no longer ensure that.

Re: Frustrations with React Hooks

#83

Post by machiaweliczny »

concerned_user wrote: post #8
iraldir wrote: post #4

Interesting to hear someone who clearly tried to use it seriously. That said I do agree with the first comment on the article itself, he is using his "useFetch" in a very far fetched (haha) way. A hooks should not be called as a callback to an event, you should "trigger an action" (whether redux, a callback from a higher component etc.) that update a state which in turns trigger the hook. I understand this can be len…

I use redux and react-saga for more complex flows, sagas translate into generators and make async code flows look almost like synchronous code which is nice.

Sagas are nice to read but hard to test. IMO simpler async functions are enough. Is there any benefit to sagas that I don't see?

Re: Frustrations with React Hooks

#84

Post by mjpuser »

I think the part that is hard to grasp is that React essentially has it's own runtime tangled with JS. With the introduction of hooks, there are non JS things going on, which is why React relies on the quirk of having the same order and number of hooks in your component. It also has Suspense which allows you to exit from the render function and return to that spot, which is definitely not a feature of JS. So yea, it's weird. I think the interesting question is trying to figure out what this means for the next version of React. I would like to see if it takes a page or two out of Svelte's book.

Re: Frustrations with React Hooks

#85

Post by acemarke »

machiaweliczny wrote: post #83
concerned_user wrote: post #8

Earlier quoted context omitted.

I use redux and react-saga for more complex flows, sagas translate into generators and make async code flows look almost like synchronous code which is nice.

Sagas are nice to read but hard to test. IMO simpler async functions are enough. Is there any benefit to sagas that I don't see?

Sagas are a great power tool... and 95% of Redux apps don't actually need them. Using them just for basic data fetching is overkill. Sagas are most useful when you need to do complex async logic, like cancellation, debouncing, and decoupled "background-thread"-like computations.

Thunks are sufficient for most use cases, but the main thing they can't do is respond to dispatched actions.

For more info, see the Redux FAQ entry on choosing an async middleware:

https://redux.js.org/faq/actions#what-async-middleware-shoul...

Re: Frustrations with React Hooks

#86

Post by peternicky »

mjpuser wrote: post #84

I think the part that is hard to grasp is that React essentially has it's own runtime tangled with JS. With the introduction of hooks, there are non JS things going on, which is why React relies on the quirk of having the same order and number of hooks in your component. It also has Suspense which allows you to exit from the render function and return to that spot, which is definitely not a feature of JS. So yea, it'…

What “non-js” things are going on?

Re: Frustrations with React Hooks

#87

Post by aidos »

ssalka wrote: post #82
aidos wrote: post #76

Earlier quoted context omitted.

I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.

Coming from the FP world, hooks are a terror because they break all the nice rules functions are supposed to uphold. Hook components don't necessarily return the same value when given the same arguments, making them impure (stateful). The benefit of function components IMO has always been that you can use the function scope as a container for pure, stateless rendering logic. With the introduction of hooks I can no lo…

Nothing stops you from using pure function components, and you should where possible. But eventually, you need to hold state somewhere. You don't need to put it in your components, but you do need to deal with it. If anything, hooks are a nice middle ground where the behaviour becomes declarative.

Re: Frustrations with React Hooks

#88

Post by RussianCow »

aidos wrote: post #76
csande17 wrote: post #64

Earlier quoted context omitted.

I'd argue that hooks didn't really make anything better, they just replaced the pitfalls with different obtuse pitfalls and unergonomic solutions. Hooks have their share of weird issues; they explode if they're called in a different order/number from how they were called the first time the component rendered (making them not at all pure functions), and it's super easy to screw up the dependency array to useMemo/useCa…

I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.

The issue I have with the "rules of hooks" is that it makes some previously trivial things cumbersome at best, and downright complicated at worst. For a quick example, something as simple as mapping an array onto a series of elements with a callback requires (as far as I can tell) that the inner element be broken out into its own component that calls `useCallback`, since you can't create a unique callback for each item in the parent.

Re: Frustrations with React Hooks

#89

Post by fishnchips »

dynamite-ready wrote: post #63
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…

`useContext` is excellent. React.context is a solid alternative to the likes of Redux and Apollo, but takes a fair amount of boilerplate to add to a class based React component. But with `useContext`, applying global state is a breeze. A lot easier to manage than Redux, at the very least. The only real dislike I have, is in how `useEffect` confuses the React lifecycle. It took me a little while to grok the lifecycle…

I understand how contexts can replace Redux, but can you please elaborate how they can be used instead of Apollo? Do you mean the whole of Apollo or Apollo local state?

Re: Frustrations with React Hooks

#90

Post by RussianCow »

sprokuski wrote: post #78
wokwokwok wrote: post #33

Earlier quoted context omitted.

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-…

I think you can make that first useEffect block fire by passing in an empty array as your params. This should run the code block on mount. To run a function on unmount, return it from the same useEffect with the empty array params.

My frustration with this is that it's completely unintuitive and doesn't read very well. Yes, you'll get used to it once you work with hooks enough, but at first glance, the empty array and the return value from the function passed to `useEffect` don't give me any useful information as to what the code is actually doing. It's an entirely React-specific abstraction that forces you to memorize a bunch of obtuse rules in order to use it effectively, as opposed to building on simpler primitives, which had previously always been the appeal of React.
Post reply on HN