4 ms·

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 som

by 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
    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.
    - aidos 4y ago
      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.

by aidos 4y ago

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
  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.
  - aidos 4y ago
    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.