-
Notifications
You must be signed in to change notification settings - Fork 46.8k
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
Document that events are pooled #3657
Comments
event objects are pooled. you can use I agree this should be documented though |
Ah, interesting, didn't know that. |
👍, this surprised me, too. Plus, I'm curious about the motivation 😄 |
I think the motivation was performance (it is expensive to create lots of short lived objects, puts lots of pressure on the javascript garbage collector). onClick wouldn't be a big deal, but a mouse-move event could fire very often. Having said that, this issue keeps coming up as a surprising/confusing part of the framework (lots of people spend lots of time debugging an issue before they realize the problem), so it might make sense to consider changing this. cc @zpao @spicyj But yes, we should document it if we are going to keep this behavior. |
I also run into this issue sometimes. @jimfb another thing that probably should be done is good error/warning messages in case of using SyntheticEvent's methods while the object has been put back in the pool. For example I had a case where I tried to call preventDefault: function() {
this.defaultPrevented = true;
var event = this.nativeEvent;
if (event.preventDefault) {
event.preventDefault();
} else {
event.returnValue = false;
}
this.isDefaultPrevented = emptyFunction.thatReturnsTrue;
},
stopPropagation: function() {
var event = this.nativeEvent;
if (event.stopPropagation) {
event.stopPropagation();
} else {
event.cancelBubble = true;
}
this.isPropagationStopped = emptyFunction.thatReturnsTrue;
}, I think the SyntheticEvent methods should rather be defensive and explain the pooling when the user face it |
calling preventDefault on the event received in onTap is currently broken on iOS. This fixes that.
The solution is to fire the tap event always synchronously (already fixed). So the React event pooling can behave as usual. Removed the attempt to assign an empty function to preventDefault, because it does not make sense to assign a function to a SyntheticEvent that has been put back in the pool. It should be the role of React to be defensive agaiin using preventDefault on events that are already put back in the pool. (See facebook/react#3657 (comment) )
Closed with #4634 |
I ran into an issue where I had an event handler that called
setState
by passing in a function and accessinge.target.value
inside that function. It seems that Reacts synthetic events are "garbage collected" after the event handler has finished executing, which gave me an error when I tried to accessvalue
ofundefined
(since all properties were removed from the event object).This is fine, and easy to fix by destructuring the event as in the argument (
({target: {value}}) => this.setState(...)
instead ofe => this.setState(...)
), but it should probably be documented.The text was updated successfully, but these errors were encountered: