jiebi/CodeConvo huggingface dataset:
Code change:
The last two assertions in this new test don't pass because of the duck-typing check in . Not quite sure what you had in mind here. Not every object whose is a component class is a valid descriptor… right?
This is an intermediate step. Currently the duck typing is flawed regardless. Descriptors will probably get an inheritance chain so that instanceof ReactDescriptor works as a safer check. Only descriptors should pass. We could probably check for props too. It is expected that component classes themselves fail the test. Therefore it should also be renamed. On Feb 24, 2014, at 7:42 AM, Ben Alpert wrote:
Right -- with the current code, returns true when passed a component class, which is wrong.
That's right. We should add that unit test. Out of curiosity, how did you find this? On Feb 24, 2014, at 1:51 PM, Ben Alpert wrote:
I was adding a warning for passing a component class to renderComponent because of this Stack Overflow question:
I think this is fixed. Not sure if we have a solid unit test to cover this.

Related discussion:
text: <ins> /** * Copyright 2013-2014 Facebook, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. * * @jsx React.DOM * @emails react-core */ "use strict"; var React; var ReactDescriptor; describe('ReactDescriptor', function() { beforeEach(function() { React = require('React'); ReactDescriptor = require('ReactDescriptor'); }); it('should identify valid descriptors correctly', function() { var Component = React.createClass({ render: function() { return <div />; } }); expect(ReactDescriptor.isValidDescriptor(<div />)).toEqual(true); expect(ReactDescriptor.isValidDescriptor(<Component />)).toEqual(true); expect(ReactDescriptor.isValidDescriptor(null)).toEqual(false); expect(ReactDescriptor.isValidDescriptor(true)).toEqual(false); expect(ReactDescriptor.isValidDescriptor({})).toEqual(false); expect(ReactDescriptor.isValidDescriptor("string")).toEqual(false); expect(ReactDescriptor.isValidDescriptor(React.DOM.div)).toEqual(false); expect(ReactDescriptor.isValidDescriptor(Component)).toEqual(false); }); }); </ins>
Code change:
React adds a scroll listener that tracks and caches the scroll position (I assume for some undocumented internal purpose). Additionally, the scroll listener forces a synchronous layout (see screenshot). This seems wasteful, especially considering that the values tracked are never exposed in the API. What is the scroll listener used for? Can it be removed? !
ViewportMetrics is used to normalize pageX and pageY on mouse events: . Perhaps ironically, it was created to prevent synchronous layouts during mouse event handlers.
I wish these values (as well as the event) were somehow exposed.
:+1:
BTW you can obviously have this if you use a Webpack-like bundler:
Well, is only used for IE8 and possibly other very old browsers (), so we should be able to just disable it for all other browsers and everyone is happy right? (Could still be optimized slightly for IE8... if anyone cares) Also, That makes no sense at all to me, does not take an argument, yet we get the scroll position and provide it as an argument. Instead, gets the scroll position internally and uses that? So we call twice, but only use the result once (also, this should be broken for events inside iframes, for IE8). Also2, I'm pretty sure any browsers that supports touch, also supports . cc
I agree that we shouldn't be tracking it in other browsers if we don't need it. I don't know if there's a way to predict whether we'll have .pageX and .pageY before mouse events actually come in.
:)
Another idea being just let resize/scroll set a flag, when a mouse event is created, if the flag is set, update viewport metrics. That way we only update it when needed, but could potentially cause a reflow if there are other events before it (very unlikely though I imagine).
This issue causes React based longer lists unusable on mobile.
Is there any progress on this issue? I’m not sure if this is the root-cause for pages rendered with react scrolling extremely slow with firefox mobile on android (e.g. this react website ).
Is that your site? If so, you can try commenting out the logic in refreshScrollValues to see if it makes a difference. If it does, I'm happy to prioritize and try to get it in.
No, that is not my site, it is an example react & fluxible page (see: ), but we have exactly the same issues with scrolling on firefox mobile. I’ve applied the changes in manually and it doesn’t solves the problem, so this issue might be unrelated to my problem. I will investigate further. Thanks for considering to prioritize this. Much appreciated.

Related discussion:
text: *    React Core     .  General Purpose Event Plugin System */ <ins> var hasEventPageXY; </ins> var alreadyListeningTo = {}; var isMonitoringScrollValue = false; var reactTopListenersCounter = 0;
Code change:
I am working on a project that has strict accessibility requirements. The table I am putting some data in has to implement headers and ids attributes to meet accessibility. See W3 techniques here Unfortunately the "headers" attribute is being stripped out because it's not supported by React (it's not on the supported attributes list). Can you please add support for the missing standard attribute called "headers"?
+1
As a workaround I believe on a you can grab the DOMNode with a ref and add what you need.

Related discussion:
text: form: MUST_USE_ATTRIBUTE, formNoValidate: HAS_BOOLEAN_VALUE, frameBorder: MUST_USE_ATTRIBUTE, <ins> headers: null, </ins> height: MUST_USE_ATTRIBUTE, hidden: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE, href: null,
Code change:
If we claim to support IE8, and users are testing their code locally in IE8, they might get thrown into compatibility mode by default. This will cause their webapp to blow up, and they will be confused because IE8 is a supported browser. For background, check out this thread: Users can get out of compatibility mode by adding this tag: Since the current failure is cryptic, and it's easy to detect when IE8 is in compatibility mode (), we should probably add a warning to give a hint to the user that even though they're using IE8, they're actually in compatibility mode (effectively IE7) and should add the meta tag or use one of the other various workarounds.

Related discussion:
text: var assign = require('Object.assign'); var findDOMNode = require('findDOMNode'); var onlyChild = require('onlyChild'); <ins> var warning = require('warning'); </ins> ReactDefaultInjection.inject();
Code change:
If we claim to support IE8, and users are testing their code locally in IE8, they might get thrown into compatibility mode by default. This will cause their webapp to blow up, and they will be confused because IE8 is a supported browser. For background, check out this thread: Users can get out of compatibility mode by adding this tag: Since the current failure is cryptic, and it's easy to detect when IE8 is in compatibility mode (), we should probably add a warning to give a hint to the user that even though they're using IE8, they're actually in compatibility mode (effectively IE7) and should add the meta tag or use one of the other various workarounds.

Related discussion:
text: } } <ins> // If we're in IE8, check to see if we are in combatibility mode and provide // information on preventing compatibility mode var ieCompatibilityMode = document.documentMode && document.documentMode < 8; warning( !ieCompatibilityMode, 'Internet Explorer is running in compatibility mode, please add the following ' + 'tag to your HTML to prevent this from happening: ' + '<meta http-equiv="X-UA-Compatible" content="IE=edge" />' ); </ins> var expectedFeatures = [ // shims Array.isArray,
Code change:
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.

Related discussion:
text: var MARKDOWN_COMPONENT = ` <del> var converter = new Showdown.converter(); </del> var MarkdownEditor = React.createClass({ getInitialState: function() { return {value: 'Type some *markdown* here!'};
Code change:
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.

Related discussion:
text: <div className="content" dangerouslySetInnerHTML={{ <del> __html: converter.makeHtml(this.state.value) </del> <ins> __html: marked(this.state.value, {sanitize: true}) </ins> }} /> </div>
Code change:
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.

Related discussion:
text: <script type="text/javascript" src="/react/js/react.js"></script> <script type="text/javascript" src="/react/js/JSXTransformer.js"></script> <script type="text/javascript" src="/react/js/live_editor.js"></script> <del> <script type="text/javascript" src="/react/js/showdown.js"></script> </del> </head> <body>
Code change:
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.

Related discussion:
text: Markdown is a simple way to format your text inline. For example, surrounding text with asterisks will make it emphasized. <del> First, add the third-party **Showdown** library to your application. This is a JavaScript library which takes Markdown text and converts it to raw HTML. This requires a script tag in your head (which we have already included in the React playground): </del> <ins> First, add the third-party library **marked** to your application. This is a JavaScript library which takes Markdown text and converts it to raw HTML. This requires a script tag in your head (which we have already included in the React playground): </ins> ```html{7} <!-- index.html -->
Code change:
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.

Related discussion:
text: <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/JSXTransformer-{{site.react_version}}.js"></script> <script src="https://code.jquery.com/jquery-1.10.0.min.js"></script> <del> <script src="https://cdnjs.cloudflare.com/ajax/libs/showdown/0.3.1/showdown.min.js"></script> </del> <ins> <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/0.3.2/marked.min.js"></script> </ins> </head> ``` Next, let's convert the comment text to Markdown and output it: <del> ```javascript{2,10} </del> <ins> ```javascript{9} </ins> // tutorial6.js <del> var converter = new Showdown.converter(); </del> var Comment = React.createClass({ render: function() { return (
Code change:
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.

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

Related discussion:
text: }); ``` <del> This is a special API that intentionally makes it difficult to insert raw HTML, but for Showdown we'll take advantage of this backdoor. </del> <ins> This is a special API that intentionally makes it difficult to insert raw HTML, but for marked we'll take advantage of this backdoor. </ins> <del> **Remember:** by using this feature you're relying on Showdown to be secure. </del> <ins> **Remember:** by using this feature you're relying on marked to be secure. In this case, we pass `sanitize: true` which tells marked to escape any HTML markup in the source instead of passing it through unchanged. </ins> ### Hook up the data model
Code change:
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.

Related discussion:
text: <h3>A Component Using External Plugins</h3> <p> React is flexible and provides hooks that allow you to interface with <del> other libraries and frameworks. This example uses Showdown, an external </del> <ins> other libraries and frameworks. This example uses **marked**, an external </ins> Markdown library, to convert the textarea's value in real-time. </p> <div id="markdownExample"></div> </div> </div> <del> <script type="text/javascript" src="js/examples/hello.js"></script> <script type="text/javascript" src="js/examples/timer.js"></script> <script type="text/javascript" src="js/examples/todo.js"></script> <script type="text/javascript" src="js/examples/markdown.js"></script> </del> <ins> <script type="text/javascript" src="/react/js/marked.min.js"></script> <script type="text/javascript" src="/react/js/examples/hello.js"></script> <script type="text/javascript" src="/react/js/examples/timer.js"></script> <script type="text/javascript" src="/react/js/examples/todo.js"></script> <script type="text/javascript" src="/react/js/examples/markdown.js"></script> </ins> </section> <hr class="home-divider" /> <section class="home-bottom-section">