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

71–80 of 139 posts

Re: Frustrations with React Hooks

#71

Post by hardwaregeek »

useEffect is such a weird name. I get that it's kinda general in usecases but whenever I see the name my first thought is "what the hell is an effect and when do I use them?" and this is coming from someone who has actually heard about effect systems. Going from componentDidMount which is a nice, clear name that dictates when the function is run, to useEffect(() => console.log("Mounting!"), []) is so confusing. I'm not super thrilled that the difference between running on mount, on new props and on unmount is implicitly determined via the second argument or returning a new function. I get that useEffect has a nice coherence and is more general but that's not always a good thing.

Not to mention the docs for useEffect just mention the one usecase of running on mount and on update and neglect to even talk about running something just on mount.

That being said, the reducer hook is amazing and a great replacement for overly complicated setState or overly simple Redux stores. Definitely reminds me of ReasonReact in a good way.

Re: Frustrations with React Hooks

#72

Post by dceddia »

mattkrick wrote: post #19

Hooks are absolutely fantastic. However, there are still a few pain points: - useState with an array is bad news if more than 1 component is consuming or setting the state.The clunky alternative is to keep it in a ref & call a forceUpdate whenever you would normally call your setter - useCallback doesn't scratch the itch for things like document event listeners since everything inside the callback will be stale. The…

> useState with an array with more than 1 component setting the state...

It sounds like you might be setting state by modifying the array and then calling the setter. This won't work:

    array.push(thing)
    setArray(array)
Instead, you have to update the array immutably, like setArray([...array, thing]).

> useCallback for event listeners

useEffect is usually the right place to set up event listeners (and has a built-in way of cleaning them up, by returning a cleanup function).

> Sometimes I want to return null before a hook.

Hooks pretty much have to be at the very top of the component, and eslint-ignore'ing those errors will probably cause weird issues later. Better to think about another way to solve the problem that doesn't involve returning early.

An issue I ran into recently: I had a modal Edit dialog with some form state that was initialized with the current values of the thing I wanted to edit. If that modal was always mounted and merely shown/hidden (), the state would be initialized once and wouldn't update when I changed the item-to-be-edited. The fix was to unmount the dialog, and only mount it when there was an item to edit, {itemToEdit && }

Re: Frustrations with React Hooks

#73

Post by csande17 »

acemarke wrote: post #70
YuukiRey wrote: post #68

Many people aren't event aware of the unnecessary renders caused by using hooks. If your app is so tiny that it doesn't matter if everything renders all the time, then you might not be aware of your `useCallback` recreating callbacks way too often ( https://github.com/facebook/react/issues/14099 ), or that you're not even using it in the first place. Considering that front end is probably the area of software develop…

A lot of people don't understand that React's default behavior is to re-render _everything_. When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that care…

Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: (https://reactjs.org/docs/optimizing-performance.html)

> Internally, React uses several clever techniques to minimize the number of costly DOM operations required to update the UI. For many applications, using React will lead to a fast user interface without doing much work to specifically optimize for performance.

My experience with React applications (both writing them and as an end-user) hasn't really borne this out.

Re: Frustrations with React Hooks

#74

Post by dumbmatter »

bcyn wrote: post #38
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-…

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

I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable.

I'm not sure if there is a less confusing way of doing it, but it's damn confusing.

Re: Frustrations with React Hooks

#75

Post by shantly »

s_y_n_t_a_x wrote: post #43
marmada wrote: post #42

Earlier quoted context omitted.

I don't understand the hate against class based components. React class-based components are dead simple to understand.

Nothing is simpler than a function. Easier to write, debug, and test. * Removed "pure" to make my main point clear.

Simplicity does not necessarily imply clarity.

Re: Frustrations with React Hooks

#76

Post by aidos »

csande17 wrote: post #64
kybishop wrote: post #57

Earlier quoted context omitted.

Have you seen the ReactConf talk on hooks? [1] It's absolutely worth the watch, even if you're somewhat familiar with hooks. They go through the pitfalls of class-based components and how hooks solve them. It more-or-less boils down to: 1. class-based components force your lifecycle logic to live in disparate locations. 2. Class-based hooks are obtuse with hidden gotchas whereas pure functions tell you exactly what t…

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.

Re: Frustrations with React Hooks

#77

Post by Blackstone4 »

I spent maybe 1.5-2 years working on a medium size React app and after taking maybe 6 months off, I came back to it. I started reading about React Hooks and honestly I did not fully understand them. Maybe it's just JS fatigue and me feeling like I'm trying to building a house on quick sand. Everything is always changing...

Recently I built a bolierplate JSON-api web app project in vuejs and golang (previously I was using TypeScript, Apollo GraphQL and Express). I find the terminology around vuejs much more user friendly and it comes with a router and state management built in...I try to avoid using any other JS module. The golang ecosystem is much more stable than nodejs which is a relief....I have a feeling I might just settle on vuejs + golang for all future web apps

Re: Frustrations with React Hooks

#78

Post by sprokuski »

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

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.

Re: Frustrations with React Hooks

#79

Post by ng12 »

csande17 wrote: post #73
acemarke wrote: post #70

Earlier quoted context omitted.

A lot of people don't understand that React's default behavior is to re-render _everything_. When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that care…

Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: ( https://reactjs.org/docs/optimizing-performance.html ) > Internally, React uses several clever techniques to minimize the number of costly DOM ope…

Could you elaborate? Rendering perf is pretty much the least of my concerns, even on my apps which support IE10. Most "perf" problems I find are related to fetching and appropriately caching data.

Re: Frustrations with React Hooks

#80

Post by sebringj »

From your complaint of deep comparisons in hooks, you should not be doing deep comparisons though which is the point of immutability in checking refs which is the whole craze of redux but craze meaning warranted in this case. In plain classes with redux, you usually check against a simple property or ref change anyway.
Post reply on HN