Hacker News Reader

Thanks for the update.

There’s always a lot of complaining about hooks but honestly I think they’re generally pretty wonderful. Occasionally you need to do some gymnastics but more recently I’ve lent on the useEvent pattern to detach reactive and non-reactive code and it’s working nicely.

Is there something I should know about useEffectEvent vs useEvent? We use the pretend / poly fill version and I understand it behaves slightly differently. But in general we just want a function that doesn’t change that always calls the latest version of the real function. Mostly we’re passing it down to other components that use it as an event handler or sometimes in a useEffect themselves.

As ever, thanks for the work on React.

>Is there something I should know about useEffectEvent vs useEvent?

Yea. It still proxies to the latest version, but it doesn't give you a stable function. (In fact, it always gives you a new one in DEV to avoid depending on its identity.) Instead, the _linter_ lets you (actually, forces you) to omit it from dependencies. Conceptually, it's a non-reactive piece of code. There's also a new limitation that you're supposed to only call it but not pass around (also enforced by the linter). There's a bunch of reasons for this design which we'll write up in the RFC. (TLDR: you only really know whether something should be reactive or not next to the actual callsite.)

Sounds like that’s probably ok in practice - you can use it nearer to the location of the useEffect.

Though, in our case we use mobx so a lot of our components are effectively memoised on shallow prop comparison. Here the ergonomics of stable function identity work well at a higher level in the stack. You can avoid rerendering large parts of the tree if your event handlers are stable.

I’m a little worried that the api you describe will work against us here (and I’m also generally a little concerned that the smarter compiler stuff you guys are working on might not play as nice with a mobx world - but maybe that’s not true).

We can only play very well with the stuff that works by the React rules. It's the only direction that it makes sense go into, IMO — we are exploring a particular paradigm, and we might as well squeeze everything we can out of it. So to reap its benefits we also need to work within its model. We do have escape hatches for the other stuff but this is exactly the reason we're cautious about recommending something that is in a different direction than our model. At some point we want to rely on some property, and if it's not there, it just doesn't work.

We’ve actually been through our code after this conversation to look at the impact. Switching to the model where we use useEvent in the local component only is working fine and is easier to reason about.

I'm having hard time understanding why `useEffectEvent` is so limited.

> * Only call them from inside Effects.

> * Never pass them to other components or Hooks.

(https://react.dev/learn/separating-events-from-effects#limit...)

The original proposal was more about `events` this one is about effects.

According to these rules, i can't do

    const x = useEffectEvent((event) => console.log("abc"))
    return <MyCustmButton onClick={x}/>

Why isn't it allowed?

TBH I can't even figure out what useEffectEvent does after reading the docs and looking at just about every Google hit for it. Please let me know if you figure it out.

The idea with them is to “break” reactivity. In the local space where you define them that’s totally fine because you’re obviously doing it in order to have useEffects that only run when their real dependencies change.

If these are passed down you’re invisibly breaking the reactivity of the child components. It’ll be too easy to shoot yourself in the foot in a child component by assuming that that you can use one of these in your own useEffect.

I really strive to find actual example of shooting myself in foot with passing "stable" callback to component below.

Like, do you know if there is actual example somewhere, where things break? They (react devs) only talk about something concurrent, but no actual code, only hand waving potential dangers.

OT but if I never see connection handling and connection callbacks mixed in with React components and stale state refs in a real, production app I'm responsible for.. It'll be too soon.

Alas, since it's being "promoted" in the React doc examples I'm guessing I haven't seen the last of this :|

On-topic: I read all that and have no clue what useEffectEvent does. Why can't I just use a closure? Passing the effect event is listed as a limitation, but it's never explained why it can't be passed. What happens?

Yeah, I’ve helped build some of those huge apps, and I’ve ran in these issues and wasted countless hours debugging and working around them in all of them.

And what do we get from the React team? After five years? More vague promises. More RFCs. More blog posts. More tweets. More docs mentioning nonexistent APIs. No actual shipped solutions. Forgive me, but I just don’t believe you anymore at this point. Five years.

I mean, with that attitude?

You’re obviously a bit frustrated but as someone who has done a lot of React over the years I don’t quite get what you’re running into that would make you that upset.

Can you be a bit more specific about which issues you've ran into? That would help me know whether we're addressing them or not. (The linked issue is very broad so it's not super clear which part of it you're referring to. We think it conflates a few unrelated things.)

I think it's fair criticism we've been slow on shipping this Hook. We try to take a very cautious approach to introducing new APIs, so we are currently testing it in our internal codebase. Once we feel confident the approach makes sense, we will make a stable release with it.

What an incredibly entitled attitude.