-
Notifications
You must be signed in to change notification settings - Fork 46.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warn when reading from event which has been returned to the pool #5939
Comments
I may be wrong but I think this is by design (and equivalent to how it worked before a couple of versions back). You can grab the stuff you need from the event object: handleClick(e) {
const { target } = e
this.setState({
clicked: this.state.clicked + 1
}, () => {
console.log(target)
})
}, |
Thanks for the comment @gaearon. I updated my issue to be more specific about why I'd rather avoid doing that.
If it were just
After, only these remain as non-null:
So I could definitely keep a reference to those and monkey patch them back on, but I'd love to find another solution :-) |
I should point out that the specific code I'm working with is a fork of rackt/react-autocomplete, specifically these lines. So I imagine anyone utilizing any properties from the |
Why not shallow clone the event if you want to keep it around?
|
Maybe I'm missing something, but... https://facebook.github.io/react/docs/events.html#event-pooling Seems like you want to call |
I didn’t know |
That totally worked. I'll PR rackt/react-autocomplete with that. Thanks @jimfb :-) |
Can we warn on accessing |
As noted in [this issue on React](facebook/react#5939), `0.14.7` (released yesterday) introduces some memory leak fixes that result in `event` having most of its properties (like `target` for example) set to `null`. Calling `event.persist()` will prevent React from removing those properties ([docs](https://facebook.github.io/react/docs/events.html#event-pooling)).
Not sure I know what you're suggesting. But maybe this is what you mean. Maybe in development mode we could replace them with getters that will throw a clear error indicating that those properties are removed after the initial handlers have been called and if you need access to them, you should find another way to do what you're trying to do or use |
Yeah, this is what I meant. |
Yeah, probably a good thing to do. |
I'd love to make this my first contribution if you don't mind holding off for a bit for me to work on it. 😄 |
…leased syntheticEvents Closes facebook#5939
…leased syntheticEvents Closes facebook#5939
…leased syntheticEvents Closes facebook#5939
The title is an assumption based on my experience upgrading. Here's an example of what I'm seeing:
Here's a jsbin that demonstrates the behavior with
0.14.6
: https://jsbin.com/gasozit/edit?js,console,outputHere's a jsbin with
0.14.7
: https://jsbin.com/vaberi/edit?js,console,outputNotice in the console, that the log inside the callback is logging that
e.target === null
evaluates totrue
. In my app, I'm passing theevent
to anonChange
handler which utilizes thetarget
. So this update breaks that situation.This may or may not be a bug. It may just be necessary for avoiding the memory leak. If that's the case, then it's a support request 😄 How should I handle this if I'm passing the
event
to another callback and I want that event to have references to things liketarget
?The text was updated successfully, but these errors were encountered: