jiebi/CodeConvo huggingface dataset:
Code change:
<h2 className="commentAuthor"> {this.props.author} </h2> <del> {converter.makeHtml(this.props.children.toString())} </del> <ins> {marked(this.props.children.toString())} </ins> </div> ); } }); ``` <del> All we're doing here is calling the Showdown library. We need to convert `this.props.children` from React's wrapped text to a raw string that Showdown will understand so we explicitly call `toString()`. </del> <ins> All we're doing here is calling the marked library. We need to convert `this.props.children` from React's wrapped text to a raw string that marked will understand so we explicitly call `toString()`. </ins> But there's a problem! Our rendered comments look like this in the browser: "`<p>`This is `<em>`another`</em>` comment`</p>`". We want those tags to actually render as HTML. That's React protecting you from an XSS attack. There's a way to get around it but the framework warns you not to use it: <del> ```javascript{5,11} </del> <ins> ```javascript{4,10} </ins> // tutorial7.js <del> var converter = new Showdown.converter(); </del> var Comment = React.createClass({ render: function() { <del> var rawMarkup = converter.makeHtml(this.props.children.toString()); </del> <ins> var rawMarkup = marked(this.props.children.toString(), {sanitize: true}); </ins> return ( <div className="comment"> <h2 className="commentAuthor">

Related discussion:
text: Since copy+pasting our code makes it too easy for people to XSS themselves, lets just add a comment in there about it.
PR at - let me know if that's what you had in mind!
My intuition is that it makes more sense to fix the example (call a sanitization library) or to change the example completely (demonstrate something else that is safer). It looks really bad to have a security warning on the homepage of the react site. Makes it seem like our framework encourages unsafe operations, rather than a safe-by-default way of doing things.
Should switch the demo to use a different library like markdown-js that escapes everything and doesn't support HTML:
markdown-js looks good. First attempt: ,output Code licensed if someone wants to turn this into a coherent example; I've signed the CLA.
That's a good suggestion too :) - what are your thoughts? I'm happy to change the example to use like people have suggested above. nice usage example :+1:
Uh yea, that sounds fine to me. This behavior is definitely non-standard markdown but it's an example so not a big deal. We should probably do the same for the tutorial while we're here. And it's on cdnjs so that's all pretty easy:
Just going to use marked instead, which I'm already familiar with and has an option to sanitize input.
Code change:
--- markdown: redcarpet name: React <ins> description: A JavaScript library for building user interfaces </ins> redcarpet: extensions: - fenced_code_blocks

Related discussion:
text: 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.