jiebi/CodeConvo huggingface dataset:
Change:
newState = workInProgress.memoizedState; if ( <del> oldProps === newProps && </del> <ins> unresolvedOldProps === unresolvedNewProps && </ins> oldState === newState && !hasContextChanged() && !checkHasForceUpdateAfterProcessing()

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? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
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!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is
Change:
* in `next` in a reasonable order. */ mergeKeySets: function(prev, next) { <ins> prev = prev || {}; next = next || {}; </ins> var keySet = {}; var prevKeys = Object.keys(prev).concat([MERGE_KEY_SETS_TAIL_SENTINEL]); var nextKeys = Object.keys(next).concat([MERGE_KEY_SETS_TAIL_SENTINEL]);

Discussion:
Consider this example: If is false or undefined, will be and will throw
Want to take a go at fixing this? I think it would be a good opportunity to learn a bit more about a constrained subset of internals.
yea - i'll give it a shot :)
Change:
); var CodeMirrorEditor = React.createClass({ <ins> propTypes: { lineNumbers: React.PropTypes.bool, onChange: React.PropTypes.func }, getDefaultProps: function() { return { lineNumbers: false }; }, </ins> componentDidMount: function() { if (IS_MOBILE) return; this.editor = CodeMirror.fromTextArea(this.refs.editor.getDOMNode(), { mode: 'javascript', <del> lineNumbers: false, </del> <ins> lineNumbers: this.props.lineNumbers, </ins> lineWrapping: true, smartIndent: false,  // javascript mode does bad things with jsx indents matchBrackets: true,

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:
expect(summary).toEqual([]); }); <ins> it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => { ReactDOM.render(<Div>hey</Div>, container); }); spyOn(console, 'table'); ReactDefaultPerf.printOperations(measurements); expect(console.table.calls.length).toBe(1); expect(console.table.argsForCall[0][0]).toEqual([{ 'data-reactid': '', type: 'set innerHTML', args: '{"node":"<not serializable>","children":[],"html":null,"text":null}', }]); }); </ins> it('warns once when using getMeasurementsSummaryMap', function() { var measurements = measure(() => {}); spyOn(console, 'error');

Discussion:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.
Change:
<![endif]--> <script type="text/javascript" src="/react/js/codemirror.js"></script> <script type="text/javascript" src="/react/js/javascript.js"></script> <del> <script type="text/javascript" src="/react/js/react.min.js"></script> </del> <ins> <script type="text/javascript" src="/react/js/react.js"></script> </ins> <script type="text/javascript" src="/react/js/JSXTransformer.js"></script> <script type="text/javascript" src="/react/js/live_editor.js"></script> <script type="text/javascript" src="/react/js/showdown.js"></script>

Discussion:
Sometimes it's helpful for to have a playground for grokking React's features, and I like to use the live editor on the docs site to sketch out ideas and see how my code is called by the library. It'd be a huge help if the site's React source was served unminified so it's more apparent what's going on under the covers.
I think this would be helpful:
I think I'd be okay with this. Want to send a PR?
Change:
icon: null, id: MUST_USE_PROPERTY, inputMode: MUST_USE_ATTRIBUTE, <ins> integrity: null, </ins> is: MUST_USE_ATTRIBUTE, keyParams: MUST_USE_ATTRIBUTE, keyType: MUST_USE_ATTRIBUTE,

Discussion:
defines the "integrity" attribute. This attribute is not defined in HTMLDOMPropertyConfig so it is not included in HTML rendered on a server.
+1 here. Modern browsers have supported this feature. Bootstrap tell me to use the following from CDN: Here is the MDN introduction:
cc Contrary to popular belief, we do get these fairly frequently. Related to
Related in that there should be a good way of replacing whitelisting attributes, but it's not a custom attribute in the same sense as .
Yea "related", the underlying goal of that issue is to really get of the whitelist as much as possible, entirely would be good. I don't know that we called that out explicitly but they're mostly the same problem.
Yeah, my comment was directed at a conversation we had at our last team meeting when figuring out our priorities for the remainder of the year. Basically, there are a whole ton of attributes that we keep adding one-at-a-time, and I was/am pushing for us to solve and wipe them all out (past present and future) with a single swipe. But is a slightly non-trivial change with several dependencies and was thus demoted off the prioirty list :P.
Change:
const beforeState = this._newState; if (typeof this._instance.componentWillMount === 'function') { <del> if (__DEV__) { // Don't warn about react-lifecycles-compat polyfilled components if ( warnAboutDeprecatedLifecycles && this._instance.componentWillMount.__suppressDeprecationWarning !== true ) { const componentName = getName(element.type, this._instance); if (!didWarnAboutLegacyWillMount[componentName]) { lowPriorityWarning( false, '%s: componentWillMount() is deprecated and will be ' + 'removed in the next major version. Read about the motivations ' + 'behind this change: ' + 'https://fb.me/react-async-component-lifecycle-hooks' + 'nn' + 'As a temporary workaround, you can rename to ' + 'UNSAFE_componentWillMount instead.', componentName, ); didWarnAboutLegacyWillMount[componentName] = true; } } } </del> // In order to support react-lifecycles-compat polyfilled components, // Unsafe lifecycles should not be invoked for any component with the new gDSFP. if (typeof element.type.getDerivedStateFromProps !== 'function') {

Discussion:
For consideration. These warnings are already covered by renderers based on react-reconciler. Maybe we don't gain that much by mirroring them in the shallow renderer? Maybe it's not worth the complexity? Particularly with more complicated warnings like the ones being for and .
Change:
topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent) { </del> <ins> nativeEvent, nativeEventTarget) { </ins> var getTargetIDFunc, handleEventFunc; if (shouldUseChangeEvent(topLevelTarget)) {

Discussion:
I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.
Change:
* components with the class name matching `className`. * @return {array} an array of all the matches. */ <del> scryRenderedDOMComponentsWithClass: function(root, className) { </del> <ins> scryRenderedDOMComponentsWithClass: function(root, classNames) { if (!Array.isArray(classNames)) { classNames = classNames.split(/s+/); } </ins> return ReactTestUtils.findAllInRenderedTree(root, function(inst) { if (ReactTestUtils.isDOMComponent(inst)) { <del> var instClassName = ReactDOM.findDOMNode(inst).className; return ( instClassName && (('' + instClassName).split(/s+/)).indexOf(className) !== -1 ); </del> <ins> var classList = ReactDOM.findDOMNode(inst).className.split(/s+/); return classNames.every(function(className) { return classList.indexOf(className) !== -1; }); </ins> } return false; });

Discussion:
The function isn't quite working for me anymore after upgrading from 0.14-rc1 and 0.14. The error stack looks something like this:
Can you post a minimal repro case please?
The minimal repro for me is this: If I use an element -- I get the error reported above. If I use a element -- there is no error. I tried dropping this as a Jest test in the React source code -- but it passed. However, running this exact same test in my local project -- it fails. I've confirmed that all React libs are 0.14. Could there be some kind of build process that's causing the issue? The line that fails is this when is the element.
Sounds like what mentioned here:
Indeed. Looks like this is the same issue. I hope you can push that out fix in 0.14.1 soon as this is a blocking issue for my team for upgrading to 0.14. Thanks for the fast response.
We'll try. In the meantime, you could copy the definition from here since it doesn't rely on any React internals:
Change:
<ins> /** * Copyright 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. * * @providesModule camelizeStyleName * @typechecks */ "use strict"; var camelize = require('camelize'); var msPattern = /^-ms-/; /** * Camelcases a hyphenated CSS property name, for example: * *   > camelizeStyleName('background-color') *   < "backgroundColor" *   > camelizeStyleName('-moz-transition') *   < "MozTransition" *   > camelizeStyleName('-ms-transition') *   < "msTransition" * * As Andi Smith suggests * (http://www.andismith.com/blog/2012/02/modernizr-prefixed/), an `-ms` prefix * is converted to lowercase `ms`. * * @param {string} string * @return {string} */ function camelizeStyleName(string) { return camelize(string.replace(msPattern, 'ms-')); } module.exports = camelizeStyleName; </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:
var adler32 = require('adler32'); var TAG_END = //?>/; <ins> var COMMENT_START = /^<!--/; </ins> var ReactMarkupChecksum = { CHECKSUM_ATTR_NAME: 'data-react-checksum',

Discussion:
Run this: Get this: Not sure if this is a bug but I thought and friends are gone in , no? Also when testing with an old project using - which has a much complex scenario, returned following causing a blank page: Just wondering is the behavior for server rendering changing in ? Thanks.
is gone for client-side rendering, but still exists for server-side rendering. This is expected behavior. However, is NOT desired output. Can you provide an example component/render that generates this output?
This happens when a root composite component returns .
I spent all day trying to trace the root cause of the issue and ended up confirmed it's a false alarm, it was caused by lib which returns a null root component while rendering on the server. I'm currently working on different approaches to implement universal apps on both server and client, will report back if I hit any other issues with v15.
But, to be clear, this is a valid bug in React.
Update: just confirmed that is working fine with other apps in regard to server rendering once removed . One thing to note though I saw a lot of comments for text like this, just wondering is it necessary?
Right, but the use case that mentioned clearly demonstrates the bug. It's necessary for tracking separating the text elements in order to apply updates/diffs.
Understood, thanks for the explanation.
Change:
expect(stubStyle.fontFamily).toEqual(''); }); <ins> // TODO: (poshannessy) deprecate this pattern. </ins> it("should update styles when mutating style object", function() { <ins> // not actually used. Just to suppress the style mutation warning spyOn(console, 'error'); </ins> var styles = {display: 'none', fontFamily: 'Arial', lineHeight: 1.2}; var container = document.createElement('div'); React.render(<div style={styles} />, container);

Discussion:
Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.
Change:
outfile: './build/JSXTransformer.js', debug: false, standalone: 'JSXTransformer', <del> after: [es3ify.transform, simpleBannerify] </del> <ins> transforms: [], after: [es3ify.transform, derequire, simpleBannerify] </ins> }; var addons = {

Discussion:
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
Change:
); } }); <ins> App = React.createFactory(App); </ins> /** jQuery Mobile button component. */ var JQueryMobileButton = React.createClass({

Discussion:
When I run the in examples jquery-mobile in the chromium browser, I get: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of (anonymous function)
I can confirm. Works fine with React version “0.12.2", but "0.13.0-alpha.2" gives: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of undefined ReactClass.createClass.Constructor (anonymous function) The jquery-mobile example is using component constructors in a way which makes the new version explode. gaearon lays is out here:
We'll make sure all the examples are working before we release 0.13 final but until then there's a non-trivial change they'll be broken at any point in time. Check out the latest stable branch for the working examples.