5 ms·
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
by 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 agoWe 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 agoWe’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.