jiebi/CodeConvo huggingface dataset:
Change:
'use strict'; var CSSProperty = require('CSSProperty'); <ins> var warning = require('warning'); </ins> var isUnitlessNumber = CSSProperty.isUnitlessNumber; <ins> var styleWarnings = {}; </ins> /** * Convert a value into the proper css writable value. The style name `name`

Discussion:
It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.
Change:
}, "preferGlobal": true, "commonerConfig": { <del> "version": 6 </del> <ins> "version": 7 </ins> }, "scripts": { "test": "jest",

Discussion:
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.
Change:
crossOrigin: null, data: null, // For `<object />` acts as `src`. dateTime: MUST_USE_ATTRIBUTE, <ins> default: HAS_BOOLEAN_VALUE, </ins> defer: HAS_BOOLEAN_VALUE, dir: null, disabled: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE,

Discussion:
I'm trying to use Video element but some attributes doesn't work. from i'm trying to do: but it only renders to:
kind and srcLang were recently in They'll be a part of a future release (likely 0.14.1). I didn't see default then though so I guess we still need to add that.
Related to
Change:
var dest = 'build/npm-react/'; var modSrc = 'build/modules/'; var lib = dest + 'lib/'; <ins> var dist = dest + 'dist/'; var distFiles = [ 'react.js', 'react.min.js', 'JSXTransformer.js', 'react-with-addons.js', 'react-with-addons.min.js' ]; </ins> function buildRelease() { // delete build/react-core for fresh start

Discussion:
It's nice to have prebuilt binaries available through the current package managers. Right now there's a prebuilt package for , but it'd be nice to also have them on npm / component / What do you think is the best way to create and maintain these packages? cc/
See also .
cc -- Not a blocker for 0.11, but it would be nice if could be merged.
By "binaries" do you actually mean prebuilt versions of React that you can just include on a web page? React doesn't really have binary components.
Yep, that's what I mean.
I'm using in a project and I would love to be able to include react that way. The last conversation about this ended in
We don't have plans to do this right now.
Change:
<del> 'use strict'; var _extends = Object.assign || function(target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; }; /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @providesModule Circle.art * @typechecks * * Example usage: * <Circle *   radius={10} *   stroke="green" *   strokeWidth={3} *   fill="blue" * /> * */ var PropTypes = require('prop-types'); var React = require('react'); var ReactART = require('..'); var createReactClass = require('create-react-class'); var Path = ReactART.Path; var Shape = ReactART.Shape; /** * Circle is a React component for drawing circles. Like other ReactART * components, it must be used in a <Surface>. */ var Circle = createReactClass({ displayName: 'Circle', propTypes: { radius: PropTypes.number.isRequired, }, render: function render() { var radius = this.props.radius; var path = Path() .moveTo(0, -radius) .arc(0, radius * 2, radius) .arc(0, radius * -2, radius) .close(); return React.createElement(Shape, _extends({}, this.props, {d: path})); }, }); module.exports = Circle; </del>

Discussion:
It seems like those were intended to be public APIs () but they’re not published on npm because folder is not in the whitelist.
Change:
path.pushContainer( 'body', t.expressionStatement( <del> t.callExpression(t.identifier('$RefreshReg$'), [ </del> <ins> t.callExpression(refreshReg, [ </ins> handle, t.stringLiteral(persistentID), ]),

Discussion:
Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.
Change:
<ins> --- layout: default sectionid: blog --- <section class="content wrap documentationContent"> {% include nav_blog.html %} <div class="inner-content"> {% for page in site.posts %} {% include blog_post.html %} {% endfor %} </div> </section> </ins>

Discussion:
I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.
Change:
case topLevelTypes.topEnded: case topLevelTypes.topError: case topLevelTypes.topInput: <ins> case topLevelTypes.topInvalid: </ins> case topLevelTypes.topLoad: case topLevelTypes.topLoadedData: case topLevelTypes.topLoadedMetadata:

Discussion:
Ref:
I'm taking a look at this as a first bug - from the docs and some testing, the event seems to be fired at the form element level rather than the form itself. That is to say: will not log on submit, but: will log on submit. Does this match the expected behaviour, and if so do we want the handler to be on the individual React.DOM form elements (i.e. so it is called when that element is invalid), or do we want it to bubble up to the parent (i.e. so it is called whenever at least one element in that form is invalid)?
We should match the DOM and fire it on the element (not the form). We already have support for these events which don't bubble. Most of our events are at the document level and then delegated but the ones which don't bubble need to be to specific elements on creation. Here's how we're doing it for forms and the submit & reset events: Thanks for taking this on! Feel free to get a PR up before it's completely ready if you have questions / need help.
Thanks Paul, good to know I was looking in the right place! Will update when I have had time to create a PR or if I need any help :) Cheers Tom
Hey, I've put together a PR at - it would be great to get your feedback on it. A couple of specific questions I had: should I handle automated testing of this? There's a lot of test code to look at and I'm unfamiliar with the React codebase, so I'm unsure if/how this should be tested. the splitting out of the logic make sense? Or do you think it would be better to have a separate statement for this bit, preceeding the other in , matching all the elements which need this setup, and then keep the other as is (minus the first ) Any feedback appreciated, this does seem to work but I'm totally new to the React code so not sure if the way I've gone about it is suitable or not! Cheers, Tom
Awesome!
Change:
'use strict'; <del> var React = require('./build/React'); </del> <ins> var React = require('./build/react'); </ins> var visitors = require('./vendor/fbtransform/visitors').transformVisitors; var transform = require('./vendor/fbtransform/lib/transform').transform;

Discussion:
I'm trying to programatically invoke the JSX transformer (using the version of in the npm registry) by running something like Which then throws this error: If I comment out the lines in that require/use the module loads fine and the transformer runs correctly.
Bah, I changed build filenames last minute and didn't properly test the module after :( Thanks for finding this! I guess we should write some tests for the node module too, not just our phantomjs tests. (Very) Short term, you should be able to change to and that will fix the problem. - I guess it's time to figure out what we want to do with npm versions vs library versions. Should we just bump them both for the time being?
Nope, that alone won't do it, we're not even packaging. I totally screwed up the node module :( Fix soon!
Yeah, doesn't look like there's even a directory there. :)
Change:
instance = ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: x' </del> <ins> 'Tried to merge two objects with the same key: `x`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.' </ins> ); });

Discussion:
Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.
Change:
// `textContent` (unnecessary since we update value). // The initial value can be a boolean or object so that's why it's // forced to be a string. <del> initialValue: '' + (value != null ? value : defaultValue), value: defaultValue </del> <ins> initialValue: '' + (value != null ? value : defaultValue) </ins> }; },

Discussion:
creates invalid html markup and appears to be unnecessary for proper functionality of the . Admittedly my test here was very minimal, but removing from the object using rendered valid html and the component still worked properly in the browser and passed all it's tests. Other than perhaps supporting server-side rendering, is there a purpose to rendering into the real dom?
Good catch :+1: The reason is set is because is , i.e, it's treated as a property rather than an attribute at run-time (which is correct). But like you say, it should not generate markup for the attribute (because it's wrong). I'm not 100% sure what the preferred fix is here, add another "directive" ex: ?
I don't think it's invalid markup. just isn't used (unless you use , which we don't do for ). I was surprised that just deleting value would work, but I guess we're applying updates to value of the actual node manually, not relying on render. This seems like a good enough approach to me. We already render the initial value as a text child so we don't use this for server rendering. another directive could make sense if we get scoped properties in there since this is only true for <textareabut not for other inputs. But until then... Want to submit a PR (cc
By invalid I meant the generated markup will not validate via the W3C html validator, throwing the error "Attribute value not allowed on element textarea at this point." Yes, I will submit a PR.
Change:
if (type && type.defaultProps) { var defaultProps = type.defaultProps; for (propName in defaultProps) { <del> if (typeof props[propName] === 'undefined') { </del> <ins> if (props[propName] === undefined) { </ins> props[propName] = defaultProps[propName]; } }

Discussion:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.
Change:
pkgData.name = pkgName; grunt.file.mkdir(destDir); <ins> var link = info.docs ? info.docs : 'addons'; link = `https://facebook.github.io/react/docs/${link}.html`; </ins> fs.writeFileSync(path.join(destDir, 'index.js'), generateSource(info)); fs.writeFileSync(path.join(destDir, 'package.json'), JSON.stringify(pkgData, null, 2)); fs.writeFileSync(path.join(destDir, 'LICENSE'), license); fs.writeFileSync(path.join(destDir, 'PATENTS'), patents); fs.writeFileSync( path.join(destDir, 'README.md'), <del> '# ' + pkgName + 'nn' + 'This package provides the React ' + k + ' add-on. See ' + 'http://facebook.github.io/react/docs/addons.html for more information.n' </del> <ins> ` # ${pkgName} This package provides the React ${k} add-on. See <${link}> for more information.`.slice(1) </ins> ); });

Discussion:
Follow-up for : The react-addons-* packages should have a entry in their files.
Change:
* * @param {string} name CSS property name such as `topMargin`. * @param {*} value CSS property value such as `10px`. <ins> * @param {ReactDOMComponent} component </ins> * @return {string} Normalized style value with dimensions applied. */ <del> function dangerousStyleValue(name, value) { </del> <ins> function dangerousStyleValue(name, value, component) { </ins> // Note that we've removed escapeTextForBrowser() calls here since the // whole string will be escaped when the attribute is injected into // the markup. If you provide unsafe user data here they can inject

Discussion:
It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.
Change:
render: function() { return ( <div> <del> <ReactCSSTransitionGroup transitionName="carousel"> </del> <ins> <ReactCSSTransitionGroup transitionName="carousel" transitionEnterTimeout={300} transitionLeaveTimeout={300}> </ins> <img src={this.props.imageSrc} key={this.props.imageSrc} /> </ReactCSSTransitionGroup> </div>

Discussion:
When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..
Change:
scryRenderedDOMComponentsWithTag: function(root, tagName) { return ReactTestUtils.findAllInRenderedTree(root, function(inst) { return ReactTestUtils.isDOMComponent(inst) && <del> inst.tagName === tagName.toUpperCase(); </del> <ins> inst.tagName.toUpperCase() === tagName.toUpperCase(); </ins> }); },

Discussion:
After migrating from 0.13 to 0.14-beta1, some of our unit tests are reporting false positive failures. It seems as though is no longer able to find elements inside components.
Isn't findRenderedDOMComponentWithTag's first argument supposed to be the name of the react component tree that you've defined (MyElement)?
Oops. That was a typo in my code sample. I've corrected it.
The problem was that was passed as a lowerCase string to . Converting it to upperCase before hand doesn't hurt anyway. What do you guys think?
Change:
<ins> /** * Copyright 2013-present, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule DisabledInputUtils */ 'use strict'; var disableableMouseListenerNames = { onClick: true, onDoubleClick: true, onMouseDown: true, onMouseMove: true, onMouseUp: true, onClickCapture: true, onDoubleClickCapture: true, onMouseDownCapture: true, onMouseMoveCapture: true, onMouseUpCapture: true, }; /** * Implements a native component that does not receive mouse events * when `disabled` is set. */ var DisabledInputUtils = { getNativeProps: function(inst, props) { if (!props.disabled) { return props; } // Copy the props, except the mouse listeners var nativeProps = {}; for (var key in props) { if (!disableableMouseListenerNames[key] && props.hasOwnProperty(key)) { nativeProps[key] = props[key]; } } return nativeProps; }, }; module.exports = DisabledInputUtils; </ins>

Discussion:
The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.
Change:
isIdleScheduled = false; var callback = scheduledRICCallback; scheduledRICCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(frameDeadlineObject); } };

Discussion:
We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.