5 ms·

It might have, but that RFC has been withdrawn.

danabramov 4y ago
The quick version is we're looking at this from two different sides: - To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event https://react.dev/learn/separating-events-from-effects#decla... - To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon. We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely. In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.
- nayroclade 4y ago
  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.
  - aidos 4y ago
    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.
  - danabramov 4y ago
    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.
  - kristiandupont 4y ago
    What an incredibly entitled attitude.
- aidos 4y ago
  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.
  - danabramov 4y ago
    >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.)
    - aidos 4y ago
      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).
      - danabramov 4y ago
- Rapzid 4y ago
  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?
- febusravenga 4y ago
  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#limitations-of-effect-events 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?
  - Rapzid 4y ago
    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.
  - aidos 4y ago
    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.
    - febusravenga 4y ago
      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.

The quick version is we're looking at this from two different sides: - To avoid re-triggering stuff from Effects, we _are_ adding a Hook. It has the same API as the original `useEvent` proposal but is more tightly scoped to this particular use case (and different semantics). We'll submit a new RFC for it after some more testing, but it's available (as `useEffectEvent`) in experimental builds, and the docs mention it: https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event https://react.dev/learn/separating-events-from-effects#decla... - To improve rendering performance, we are working on an automatic compiler that analyzes your code and makes rendering much more granular. It's still in active R&D but we hope to share an update on it soon. We think these two things together will likely be able to mostly address the issue. If not, we'll look at the specific gaps and work on them more closely. In general though, people have shipped huge apps with Hooks, and it's definitely production-ready. Always an opportunity for improvement, sure.

nayroclade 4y ago
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.
- aidos 4y ago
  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.
- danabramov 4y ago
  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.
- kristiandupont 4y ago
  What an incredibly entitled attitude.
aidos 4y ago
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.
- danabramov 4y ago
  >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.)
  - aidos 4y ago
    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).
    - danabramov 4y ago
Rapzid 4y ago
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?
febusravenga 4y ago
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#limitations-of-effect-events 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?
- Rapzid 4y ago
  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.
- aidos 4y ago
  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.
  - febusravenga 4y ago
    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.