Comment by wokwokwok | Hacker News Reader

Comment by wokwokwok | Hacker News Reader

Parent Full thread

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.

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

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.

But it's a pretty straightforward rule once you know it right?

This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs.

Once you know refs updates won't re-render, you won't make this mistake.

I don't understand why "a thing you need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn.

> but most people think of refs as...

This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.

Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune.

Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated.

Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes?

(I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)

What is the use case for re-rendering based on change of DOM ref? (that can't be accomplished by putting some data in state?)

Ref's are basically a 1 to 1 replacement for instance fields for mutable data (that doesn't cause rerenders).

https://reactjs.org/docs/hooks-reference.html#useref

There's always need for escape hatches and maybe I'm missing your use case, but in the context of a discussion about how hooks are more complicated than classes, what were you doing before with refs to solve your "re-render" on change scenario?

Your example was likely contrived, but modifying innerHTML should be replaced by putting whatever in state and simply rendering it. And use state for dependencies where you want to re-run on change. Refs are just another way to keep state but not have it affect render cycle.

Stuff like https://reactjs.org/docs/hooks-faq.html#how-can-i-measure-a-...

If you're not aware of that, it is very tempting to use `useRef`, which is what I have often seen. Before hooks, we did not have the temptingly-named footgun `useRef` for this scenario (although we did have other footguns for other scenarios, and overall I love hooks).

It’s obviously a contrived case.

It’s harder to just use state for example, when you need a ref to a canvas to get the 2d context.

I suspect this may be one of those cases where there's an 'aha' moment involved, and people who get that moment early find it simple to understand, people who haven't got to that moment yet are going argh, and people who got to it late sigh and/or write "yet another X tutorial" in the hopes that how they got their aha moment will work for other people.

The classic X here, of course, is monads.

But as personal examples, it took me ages of headbanging to get the 'aha' moment for git, even though a bunch of people I know got it almost immediately.

In the case of hooks, once I built a mental model of how they were (theoretically) implemented, I went 'ooh' and found them obvious and relatively easy from then on. It looks to me like the author of this piece didn't have that luck, and so for him, they're not simple (although maybe later, post-aha-moment, they will be).

tl;dr: "They seem simple to understand once you understand them, but are mystifying up until that point" seems to me to be the most likely hypothesis here.

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.

Reply on news.ycombinator.com