jiebi/CodeConvo huggingface dataset:
Change:
var divStyle = { color: 'white', backgroundImage: 'url(' + imgUrl + ')', <del> WebkitTransition: 'all' // note the capital 'W' here </del> <ins> WebkitTransition: 'all', // note the capital 'W' here msTransition: 'all' // 'ms' is the only lowercase vendor prefix </ins> }; React.renderComponent(<div style={divStyle}>Hello World!</div>, mountNode); ``` <del> Style keys are camelCased in order to be consistent with accessing the properties on DOM nodes from JS (e.g. `node.style.backgroundImage`). Vendor prefixes should begin with a capital letter. This is why `WebkitTransition` has an uppercase "W". </del> <ins> Style keys are camelCased in order to be consistent with accessing the properties on DOM nodes from JS (e.g. `node.style.backgroundImage`). Vendor prefixes [other than `ms`](http://www.andismith.com/blog/2012/02/modernizr-prefixed/) should begin with a capital letter. This is why `WebkitTransition` has an uppercase "W". </ins>

Discussion:
We happen to "support" hyphenated keys to the style object on initial render (because we attempt to hyphenate camelcased keys) but those styles will never be updated on subsequent renders because we never attempt to unhyphenate. So we should warn when we see a hyphenated style.
Some browsers support assigning with hyphenated keys, but probably not all do.
AFAIK only Webkit does. (And I guess by association, Blink)
Perhaps another one for you!
OK
Sorry for the long delay, been busy. I'll try to do this today.
No problem, whenever you have time.
Curious: why do we not want to hyphenate names on subsequent updates, and instead show a warning? Because there should be “one way to do that”?
Yes, this matches our existing practice of requiring camel-cased attributes in general, which makes it easier to make warpper components that modify props in some way because you only need to look in one place to find the original value. In addition, you don't need to worry about what happens if someone were to specify both and in the same style block. (One last advantage: if the warnings happen only in the dev version, then there's no runtime cost in the production build.)
Do you think it's worth adding for the sake of providing a suggestive warning? (e.g. )
There you go! I also updated the docs about prefix, since it's not clear right now.
A warning would be very helpful, this just sucked up a lot of my time. If anyone is interested, chrome seems to handle hyphenated CSS props OK but FF doesn't
Change:
Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <React.Profiler id="first" onRender={callback}> <AdvanceTime byAmount={20} /> </React.Profiler> <React.Profiler id="second" onRender={callback}> <AdvanceTime byAmount={5} /> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);

Discussion:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks
Change:
<del> /** * Copyright 2013-2015, 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 cx */ /** * This function is used to mark string literals representing CSS class names * so that they can be transformed statically. This allows for modularization * and minification of CSS class names. * * In static_upstream, this function is actually implemented, but it should * eventually be replaced with something more descriptive, and the transform * that is used in the main stack should be ported for use elsewhere. * * @param string|object className to modularize, or an object of key/values. *                      In the object case, the values are conditions that *                      determine if the className keys should be included. * @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ 'use strict'; var warning = require('warning'); var warned = false; function cx(classNames) { if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className]; }).join(' '); } else { return Array.prototype.join.call(arguments, ' '); } } module.exports = cx; </del>

Discussion:
Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors
Change:
props.defaultChecked = null; props.defaultValue = null; <del> props.checked = this.props.checked != null ? this.props.checked : this.state.checked; </del> var value = LinkedValueUtils.getValue(this); props.value = value != null ? value : this.state.value; <ins> var checked = LinkedValueUtils.getChecked(this); props.checked = checked != null ? checked : this.state.checked; </ins> props.onChange = this._handleChange; return input(props, this.props.children);

Discussion:
When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?
Change:
function detectEvents() { var testEl = document.createElement('div'); var style = testEl.style; <ins> // On some platforms, in particular some releases of Android 4.x, // the un-prefixed "animation" and "transition" properties are defined on the // style object but the events that fire will still be prefixed, so we need // to check if the un-prefixed events are useable, and if not remove them // from the map if (!('AnimationEvent' in window)) { delete EVENT_NAME_MAP.animationend.animation; } if (!('TransitionEvent' in window)) { delete EVENT_NAME_MAP.transitionend.transition; } </ins> for (var baseEventName in EVENT_NAME_MAP) { var baseEvents = EVENT_NAME_MAP[baseEventName]; for (var styleName in baseEvents) {

Discussion:
ReactCSSTransitionGroup doesn't work properly on (at least) Android 4.2. I've narrowed it down to the code in which is finding and properties on the test element's object and so only registering and handlers, despite the fact that Android fires events. So the end of the transition isn't properly detected. I will do some more investigation and see if there's a safer way to do this detection on Android (I seem to recall seeing something similar before).
See this patch for the Dojo toolkit: - basically on some Android versions is not . Could this be fixed by changing the order the properties are checked, so that is checked for before ?
This is still an issue on Android 4.3 (or at least on Samsung Galaxy S3 with Android 4.3). However changing the webkitTransition and transition order as suggested by it fixes the issue.
Is TransitionEvent defined or undefined on that browser? When the unprefixed version exists it's better to use that in general because it's more forwards-compatible.
Change:
var TestComponent; var TestComponentWithPropTypes; <ins> var TestComponentWithReverseSpec; </ins> var mixinPropValidator; var componentPropValidator;

Discussion:
Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.
Change:
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.

Discussion:
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!
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. * * @emails react-core */ 'use strict'; describe('DisabledInputUtils', function() { var React; var ReactDOM; var ReactTestUtils; var elements = ['button', 'input', 'select', 'textarea']; function expectClickThru(element) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(element)); expect(onClick.mock.calls.length).toBe(1); } function expectNoClickThru(element) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(element)); expect(onClick.mock.calls.length).toBe(0); } function mounted(element) { element = ReactTestUtils.renderIntoDocument(element); return element; } var onClick = jest.genMockFn(); elements.forEach(function(tagName) { describe(tagName, function() { beforeEach(function() { React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('should forward clicks when it starts out not disabled', function() { var element = React.createElement(tagName, { onClick: onClick, }); expectClickThru(mounted(element)); }); it('should not forward clicks when it starts out disabled', function() { var element = React.createElement(tagName, { onClick: onClick, disabled: true, }); expectNoClickThru(mounted(element)); }); it('should forward clicks when it becomes not disabled', function() { var container = document.createElement('div'); var element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: true }), container ); element = ReactDOM.render( React.createElement(tagName, { onClick: onClick }), container ); expectClickThru(element); }); it('should not forward clicks when it becomes disabled', function() { var container = document.createElement('div'); var element = ReactDOM.render( React.createElement(tagName, { onClick: onClick }), container ); element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: true }), container ); expectNoClickThru(element); }); it('should work correctly if the listener is changed', function() { var container = document.createElement('div'); var element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: true }), container ); element = ReactDOM.render( React.createElement(tagName, { onClick: onClick, disabled: false }), container ); expectClickThru(element); }); }); }); }); </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:
); }); <ins> it('should work with a null getInitialState() return value', function() { var Component = React.createClass({ getInitialState: function() { return null; }, render: function() { return <span />; } }); expect(() => <Component />).not.toThrow(); }); it('should work with object getInitialState() return values', function() { var Component = React.createClass({ getInitialState: function() { return { occupation: 'clown' }; }, render: function() { return <span />; } }); var instance = <Component />; ReactTestUtils.renderIntoDocument(instance); expect(instance.state.occupation).toEqual('clown'); }); it('should throw with non-object getInitialState() return values', function() { [['an array'], 'a string', 1234].forEach(function(state) { var Component = React.createClass({ getInitialState: function() { return state; }, render: function() { return <span />; } }); var instance = <Component />; expect(function() { ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: Component.getInitialState(): ' + 'must return an object or null' ); }); }); </ins> it('should detect valid CompositeComponent classes', function() { var Component = React.createClass({ render: function() {

Discussion:
See Return a string from and call . You get this amazing error message:
We should probably add an that whatever is returned from is in fact an object.
Invariant all the things :)
This also seems to apply when using an array, not the string only. Which makes it a pretty real-world bug IMHO (compared to the weird string scenario). Or is there a reason you don't want states to be arrays?
This will happen whenever state is anything but an Object (I think there is a check in there for arrays). Since we use merge it needs to be an object, arrays are no good either.
Change:
// to a SimpleMemoComponent to allow fast path updates. workInProgress.tag = SimpleMemoComponent; workInProgress.type = type; <ins> if (__DEV__) { validateFunctionComponentInDev(workInProgress, type); } </ins> return updateSimpleMemoComponent( current, workInProgress,

Discussion:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0
Change:
function getUnboundedScrollPosition(scrollable) { if (scrollable === window) { return { <del> x: document.documentElement.scrollLeft || document.body.scrollLeft, y: document.documentElement.scrollTop  || document.body.scrollTop </del> <ins> x: window.pageXOffset || document.documentElement.scrollLeft, y: window.pageYOffset || document.documentElement.scrollTop </ins> }; } return {

Discussion:
Do you want to request a feature or report a bug? Improvement What is the current behavior?  does not currently support the property. () is nice to have when you want to write key-specific handling—rather than input-specific (dependent on layout and modifier keys) handling. What is the expected behavior? already exposes a property. It should have a property as well. Currently, if you want to use the 's , you must access it through 's . Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Affects React 16 and earlier (I assume).
I created the PR for this.
the above PR is stale and closed; should I pick this up? planning to replicate the same and follow the PR suggestions; any tips or idea?
Can you give me an idea of how widely supported it is?
According to it is supported in all major desktop browsers. Are there any plans to implement this? I am not sure whether I should mark it with until this issue is resolved or don't use it at all.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Change:
onChange={this.handleCodeChange} className="playgroundStage" codeText={this.state.code} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXTabClassName =

Discussion:
is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !
Change:
var React; var ReactDOM; var ReactDOMServer; <del> var ReactDOMFeatureFlags; </del> var ReactTestUtils; <ins> var ReactDOMFeatureFlags = require('ReactDOMFeatureFlags'); </ins> describe('ReactComponent', () => { function normalizeCodeLocInfo(str) { return str && str.replace(/(at .+?:d+)/g, '(at **)');

Discussion:
When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.