jiebi/CodeConvo huggingface dataset:
Code change:
Idea (that I'm pretty sure I saw elsewhere, react-native maybe?)… We should transform our calls to a conditional wrapping the call. We have to check the condition anyway and this would reduce the no-op function calls. In otherwords becomes Hell, we could replace the with and get rid of the function call entirely, though it really doesn't matter much since we're going to throw (plus we'd duplicate the default string). This might end up be a meaningless optimization…
I believe this is done intentionally (by hand) in some hotspots, so it would seem not. I guess one could argue if it might not make more sense to simply always use the inline style and drop the argument rather than adding another transform?
That's a tough sentence to parse. Are you saying we should always write the "optimized" form? If so I would say "no", the first is way easier to read as a human being.
do you consider something like since jsx has to be transformed anyways? invariant feels more like a contract to me and codes could be more readable if we separate the warning and real implementation, any thoughts?
We have complex invariants that aren't strictly about arguments so while that might be an option for some cases, it doesn't cover us.

Related discussion:
text: }, "preferGlobal": true, "commonerConfig": { <del> "version": 6 </del> <ins> "version": 7 </ins> }, "scripts": { "test": "jest",
Code change:
The attribute allows for restrictions to be placed on iframes, regardless of domain. It's useful if you're dealing with IE versions less than 10 that don't have the attribute. More info: (v=vs.85).aspx

Related discussion:
text: itemRef: MUST_USE_ATTRIBUTE, // property is supported for OpenGraph in meta tags. property: null, <ins> // IE-only attribute that specifies security restrictions on an iframe // as an alternative to the sandbox attribute on IE<10 security: MUST_USE_ATTRIBUTE, </ins> // IE-only attribute that controls focus behavior unselectable: MUST_USE_ATTRIBUTE, },
Code change:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

Related discussion:
text: var grunt = require('grunt'); var UglifyJS = require('uglify-js'); var uglifyify = require('uglifyify'); <del> var _ = require('lodash'); </del> <ins> var derequire = require('derequire'); </ins> var SIMPLE_TEMPLATE = '/**n
Code change:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

Related discussion:
text: outfile: './build/JSXTransformer.js', debug: false, standalone: 'JSXTransformer', <del> after: [es3ify.transform, simpleBannerify] </del> <ins> transforms: [], after: [es3ify.transform, derequire, simpleBannerify] </ins> }; var addons = {
Code change:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

Related discussion:
text: "node": ">=0.10.0" }, "dependencies": { <del> "envify": "^2.0.0" </del> <ins> "envify": "^3.0.0" </ins> }, "browserify": { "transform": ["envify"]
Code change:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed. Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond

Related discussion:
text: "rootDir": "", "scriptPreprocessor": "jest/preprocessor.js", "setupEnvScriptFile": "jest/environment.js", <del> "modulePathIgnorePatterns": ["/build/", "/node_modules/", "/.module-cache/"], "testPathIgnorePatterns": ["/build/", "/node_modules/"], "unmockedModulePathPatterns": [""] </del> <ins> "modulePathIgnorePatterns": [ "/build/", "/node_modules/", "/.module-cache/" ], "testPathIgnorePatterns": [ "/build/", "/node_modules/" ], "unmockedModulePathPatterns": [ "" ] </ins> } }
Code change:
Do you want to request a feature or report a bug? Bug. What is the current behavior? Right now, React provides a cross-browser workaround for the event. , so React hacks around this by evaluating the selection after both and , which is smart! However, if you haven't an handler to your component, the part of the selection listening hack for Firefox won't ever fire. Which means if you happen to be doing something in that changes the selection, it won't be caught by as expected, such that the next time fires, the handler will be triggered (via the part of the hack), since React thinks the selection has changed. Example: You place your cursor at the end of a sentence. fires thanks to . updates the selection. You the last character: you handle deleting the character, and preventing default. doesn't fire, because on change hasn't taken place yet, as expected. updates the selection. You another character: you handle deleting another character. fires thanks to , but its internal state is comparing it to the selection before it was updated by , so it is out of date. Not expected. If you add a noop handler for , this problem goes away, since will always fire after rendering thanks to , and then it will never fire incorrectly due to . An example is in , actually doesn't do anything. Except without, the handling wouldn't stay in sync in Firefox. What is the expected behavior? Ideally I'd think that the event hack would still fire even without having to have the developer add a noop to their component? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 15 in Firefox.
Thanks for the detailed report Sorry I didn't get to this until now. This should be an easy fix – just adding onKeyUp below onKeyDown here:

Related discussion:
text: topLevelTypes.topContextMenu, topLevelTypes.topFocus, topLevelTypes.topKeyDown, <ins> topLevelTypes.topKeyUp, </ins> topLevelTypes.topMouseDown, topLevelTypes.topMouseUp, topLevelTypes.topSelectionChange,
Code change:
There appears to be a typo on line 116 of "codebase-". Specifically, I see one "" symbol. This results in all text after line 116 appearing as one large block of code. See the screenshot below, with the markdown code on the left and the stylized code rendered on the right: <img width="1389" alt="screen shot 2017-01-09 at 2 38 51 pm" src=""Based on the content of the subsequent text after line 116, I would expect it to appear as the following: <img width="1436" alt="screen shot 2017-01-09 at 2 42 08 pm" src=""If this is indeed something that should be fixed, I'd like to fix it, and can submit a PR immediately.
I think you're right, please do submit a PR.
(For future reference, feel free to send PRs for small fixes like this without creating an issue.)

Related discussion:
text: It is a good idea to avoid spamming the console with duplicate warnings: <del> ````js </del> <ins> ```js </ins> var warning = require('warning'); var didWarnAboutMath = false;
Code change:
Do you want to request a feature or report a bug? bug What is the current behavior? Selecting of the same value for the twice in a row results in triggering of change event twice for the same value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Open and click twice on any option. As the result you'll see in console that change event is triggered each time (even if the changed value is equal to the previous one). For comparison you may check the native html implementation: What is the expected behavior? The change event should not trigger again for the same value. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? macOS Sierra 10.12.5, Safari 10.1.1
cc
Thanks for the report It looks like this . We'll look into this and see if we can include a fix in the 15.6 release.
If you extend the given example with 4 radio elements (), fires only once per radio. In other words, the event is not fired if a value for a name changes. Might as well rename to () so it is clear when the callback is fired. But it seems to be a different problem than what is describing. Tested on Google Chrome Version 59.0.3071.86 (Official Build) (64-bit).
Same as mentioned above, uncontrolled radio inputs in my project just stopped working as was expected, they stopped calling the onChange function if a radio button was checked before.
This particular issue was filed before 15.6 release so I don't think what you're describing is related to it. Can you confirm your bug is the same as
yes i think this particular issue is not related indeed. I am almost certain the is the same bug I have the example here: sorry about the confusion
Thanks to and comments in I managed to understand that my reported issue is only affecting uncontrolled radio inputs. Here is a working example of controlled radios working as expected:
While solutions works, I would love to see this fixed in React 15.6 release. Any news on this, it's been a few months. Thanks!
I'm unable to reproduce the issue reported with the latest React 15 release: The issue where it only fires a single change event per input seems to still be a problem, which we will investigate separately. Thanks!

Related discussion:
text: In a traditional JavaScript application, you need to look at what data changed and imperatively make changes to the DOM to keep it up-to-date. Even AngularJS, <del> which provides a declarative interface via directives and data binding requires a linking function to manually update DOM nodes. </del> <ins> which provides a declarative interface via directives and data binding [requires a linking function to manually update DOM nodes](http://docs.angularjs.org/guide/directive#reasonsbehindthecompilelinkseparation). </ins> React takes a different approach.
Code change:
Do you want to request a feature or report a bug? bug What is the current behavior? Selecting of the same value for the twice in a row results in triggering of change event twice for the same value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Open and click twice on any option. As the result you'll see in console that change event is triggered each time (even if the changed value is equal to the previous one). For comparison you may check the native html implementation: What is the expected behavior? The change event should not trigger again for the same value. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? macOS Sierra 10.12.5, Safari 10.1.1
cc
Thanks for the report It looks like this . We'll look into this and see if we can include a fix in the 15.6 release.
If you extend the given example with 4 radio elements (), fires only once per radio. In other words, the event is not fired if a value for a name changes. Might as well rename to () so it is clear when the callback is fired. But it seems to be a different problem than what is describing. Tested on Google Chrome Version 59.0.3071.86 (Official Build) (64-bit).
Same as mentioned above, uncontrolled radio inputs in my project just stopped working as was expected, they stopped calling the onChange function if a radio button was checked before.
This particular issue was filed before 15.6 release so I don't think what you're describing is related to it. Can you confirm your bug is the same as
yes i think this particular issue is not related indeed. I am almost certain the is the same bug I have the example here: sorry about the confusion
Thanks to and comments in I managed to understand that my reported issue is only affecting uncontrolled radio inputs. Here is a working example of controlled radios working as expected:
While solutions works, I would love to see this fixed in React 15.6 release. Any news on this, it's been a few months. Thanks!
I'm unable to reproduce the issue reported with the latest React 15 release: The issue where it only fires a single change event per input seems to still be a problem, which we will investigate separately. Thanks!

Related discussion:
text: - Facebook has dynamic charts that render to `<canvas>` instead of HTML. - Instagram is a "single page" web app built entirely with React and `Backbone.Router`. Designers regularly contribute React code with JSX. <del> - We've built an internal prototype that runs React apps in a web worker. </del> <ins> - We've built internal prototypes that run React apps in a web worker and use React to drive **native iOS views** via an Objective-C bridge. </ins> - You can run React [on the server](http://github.com/petehunt/react-server-rendering) for SEO, performance, code sharing and overall flexibility.