Change:
As it is known (but ), React's SyntheticEvent is pooled. This is confusing for many users as they don't understand why the event starts to behave strangely when used in an async callback, like inside a , a or a callback. There has already been an attempt to solve this problem here: The code of SyntheticEvent's default methods is: It may make sense to be more defensive because calling on a pooled event will raise . It would be more useful to add a check like:
To illustrate the problem in not being defensive, I would give you this commit that has made it into production as a workaround in React-tappable: Basically the user is trying to assign an empty function to a SyntheticEvent that as been put back in the pool (the call to persist was from another PR at the same time). And we were basically 3 concurrent PR to try different solutions to the exact same problem.
As the person who made the PR in a panic, I did find the code that broke in react itself. the preventDefault method tries to call the method on . A simple if check for in the method, and a no-op if null would be a great fix to this problem. Similar to how setState is handled on an unmounted component.
I think React should not swallow this error and be fail fast, because this does not make any sense to preventDefault in an async callback (because the default already has been applied), React should rather throw an error. But this is only my opinion, because the browser behavior with dom events is not fail fast and swallow that bad usage of preventDefault. I mean the browser does not throw an error when we do: It simply has no effect (like what you suggest) I don't like this and would rather change the behavior of both React and the browser, but I don't think I can do much on my own... Maybe at least React could issue a warning in DEV env?
Yeah, I think warning is appropriate here.
A warning would be great!
Just wonder what kind of message should be put into this warning. If event pooling is not going to be documented (will it?), it may be strange to explain the pooling system inside a warning no?
Yes, event pooling should/will be documented. Feel free to submit a PR. We should add a warning to let the user know that the event has been returned to the pool and so invoking methods on it makes no sense. Once the docs are written, we can add a link to the end of the warning.
Got a PR for this! Would really appreciate some feedback.

Discussion:
--- markdown: redcarpet name: React <ins> description: A JavaScript library for building user interfaces </ins> redcarpet: extensions: - fenced_code_blocks

- Gemfile.lock - README.md - Rakefile <ins> url: http://facebook.github.io </ins> baseurl: /react permalink: /blog/:year/:month/:day/:title.html

<meta property="og:description" content="A JavaScript library for building user interfaces" /> <link rel="shortcut icon" href="/react/favicon.ico"> <ins> <link rel="alternate" type="application/rss+xml" title="{{ site.name }}" href="{{ site.url }}{{ site.baseurl }}/feed.xml"> </ins> <link rel="stylesheet" href="/react/css/react.css"> <link rel="stylesheet" href="/react/css/syntax.css">

<ins> --- layout: none --- <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>{{ site.name }}</title> <description>{{ site.description }}</description> <link>{{ site.url }}{{ site.baseurl }}</link> <atom:link href="{{ site.url }}{{ site.baseurl }}/feed.xml" rel="self" type="application/rss+xml" /> {% for post in site.posts limit:10 %} <item> <title>{{ post.title | xml_escape }}</title> <description>{{ post.content | xml_escape }}</description> <pubDate>{{ post.date | date_to_xmlschema }}</pubDate> <link>{{ site.url }}{{ site.baseurl }}{{ post.url }}</link> <guid isPermaLink="true">{{ site.url }}{{ site.baseurl }}{{ post.url }}</guid> </item> {% endfor %} </channel> </rss> </ins>