jiebi/CodeConvo huggingface dataset:
Change:
Having the constructor passing super a props object that differs (in object equality and/or shallow compare) from the original is... illegal, because: We should have a warning for that, because it's reasonable for someone to assume they could extend a component and modify the props, without considering the ramifications, and the bug won't show up in their initial render test but will show up when the component updates.
Can a shallow comparison of and suffice, or is a deep equality check between the two objects needed?
I think shallow is fine. Deep equality is too difficult/expensive because of cycles. Note that we should only do the check in dev mode, so surround your logic with a block

Discussion:
Component.displayName || Component.name || 'Component' ); } <ins> var propsMutated = inst.props !== publicProps; var componentName = Component.displayName || Component.name || 'Component'; warning( typeof inst.props === 'undefined' || !propsMutated, '%s(...): When calling super() in `%s`, make sure to pass ' + 'up the same props that your component's constructor was passed.', componentName, componentName ); </ins> } // These should be set up in the constructor, but as a convenience for

}); <ins> it('should warn when mutated props are passed', function() { var container = document.createElement('div'); class Foo extends React.Component { constructor(props) { var _props = { idx: props.idx + '!' }; super(_props); } render() { return <span />; } } expect(console.error.calls.length).toBe(0); ReactDOM.render(<Foo idx="qwe" />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Foo(...): When calling super() in `Foo`, make sure to pass ' + 'up the same props that your component's constructor was passed.' ); }); </ins> });
Change:
Follow-up for : The react-addons-* packages should have a entry in their files.

Discussion:
CSSTransitionGroup: { module: 'ReactCSSTransitionGroup', name: 'css-transition-group', <ins> docs: 'animation', </ins> }, LinkedStateMixin: { module: 'LinkedStateMixin', name: 'linked-state-mixin', <ins> docs: 'two-way-binding-helpers', </ins> }, Perf: { module: 'ReactDefaultPerf', name: 'perf', <ins> docs: 'perf', </ins> }, PureRenderMixin: { module: 'ReactComponentWithPureRenderMixin', name: 'pure-render-mixin', <ins> docs: 'pure-render-mixin', </ins> }, TestUtils: { module: 'ReactTestUtils', name: 'test-utils', <ins> docs: 'test-utils', </ins> }, TransitionGroup: { module: 'ReactTransitionGroup', name: 'transition-group', <ins> docs: 'animation', </ins> }, cloneWithProps: { module: 'cloneWithProps', name: 'clone-with-props', <ins> docs: 'clone-with-props', </ins> }, createFragment: { module: 'ReactFragment', method: 'create', name: 'create-fragment', <ins> docs: 'create-fragment', </ins> }, shallowCompare: { module: 'shallowCompare',

updates: { module: 'update', name: 'update', <ins> docs: 'update', </ins> }, };

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> ); });

{ <del> "name": "react-addons", </del> <ins> "name": "react-addons-template", </ins> "version": "0.15.0-alpha", "main": "index.js", <ins> "repository": "facebook/react", "keywords": [ "react", "react-addon" ], </ins> "license": "BSD-3-Clause", "peerDependencies": { "react": "^0.15.0-alpha"

"version": "0.15.0-alpha", "description": "React package for working with the DOM.", "main": "index.js", <del> "repository": { "type": "git", "url": "git+https://github.com/facebook/react.git" }, </del> <ins> "repository": "facebook/react", </ins> "keywords": [ "react" ],
Change:
Not sure if this is intentional, but if I run this: The resulting inner div has its set to . the resulting DOM string is: but if I remove the key the result is: If is used as the key, the result is the latter above.
This is intentional. is an intentional value whereas is the lack of a specified value.
If that's the case then IMHO we should escape it properly, as it is now and are treated equally by React (this should be trivial by translating it to or whatever. Although personally I'm not sure when it ever makes sense to have as a key, how about a warning too?

Discussion:
<hr class="home-divider" /> <section class="home-bottom-section"> <div class="buttons-unit"> <del> <a href="/getting-started.html" class="button">Get Started</a> <a href="/download.html" class="button">Download React v{{site.react_version}}</a> </del> <ins> <a href="docs/getting-started.html" class="button">Get Started</a> <a href="downloads.html" class="button">Download React v{{site.react_version}}</a> </ins> </div> </section>
Change:
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.

Discussion:
layout: docs next: tutorial.html --- <ins> ## JSFiddle The easiest way to start hacking on React is using the following JSFiddle Hello Worlds * **[React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)** * [React JSFiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) ## Starter Kit </ins> Download the starter kit to get started. <div class="buttons-unit downloads">

</a> </div> <del> ## Hello, world! </del> In the root directory of the starter kit, create a `helloworld.html` with the following contents. ```html
Change:
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.

Discussion:
// events and have it go through ReactEventTopLevelCallback. Since it // doesn't, we manually listen for the propertychange event and so we // have to enqueue and process the abstract event manually. <del> EventPluginHub.enqueueAbstractEvents(abstractEvent); EventPluginHub.processAbstractEventQueue(); </del> <ins> EventPluginHub.enqueueEvents(abstractEvent); EventPluginHub.processEventQueue(); </ins> } } };
Change:
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.

Discussion:
## JSRomandie Meetup <del> [Renault John Lecoultre](https://twitter.com/renajohn/) did a React introduction talk at a JS meetup called [JS Romandie](https://twitter.com/jsromandie) last week. </del> <ins> [Renault John Lecoultre](https://twitter.com/renajohn/) from [BugBuster](http://www.bugbuster.com) did a React introduction talk at a JS meetup called [JS Romandie](https://twitter.com/jsromandie) last week. </ins> <script async class="speakerdeck-embed" data-id="888a9d50c01b01300df36658d0894ac1" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
Change:
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.

Discussion:
// Check that the version we're exporting is the same one we expect in the // package. This is not an ideal way to do this, but makes sure that we keep // them in sync. <ins> var reactVersionExp = /bReact.versions*=s*['"]([^'"]+)['"];/; </ins> grunt.registerTask('version-check', function() { <del> var version = require('./build/modules/React').version; </del> <ins> var version = reactVersionExp.exec( grunt.file.read('./build/modules/React.js') )[1]; </ins> var expectedVersion = grunt.config.data.pkg.version; if (version !== expectedVersion) { grunt.log.error('Versions do not match. Expected %s, saw %s', expectedVersion, version);
Change:
Case: ,js,output I have a with a value depending on the state. When I select the 'baz' item in the combobox, and don't do anything in the onChange handler, the combobox suddenly displays the first element (even though the state is still the same). So, the state of the combobox is inconsistent with the state of its 'value' property. This seems to happen in at least Chrome and Safari.

Discussion:
var value = LinkedValueUtils.getValue(props); if (value != null) { <del> updateOptions(this, props, value); </del> <ins> updateOptions(this, Boolean(props.multiple), value); </ins> } } }

ReactTestUtils.renderIntoDocument(<select value={null}><option value="test"/></select>); expect(console.error.argsForCall.length).toBe(1); }); <ins> it('should refresh state on change', function() { var stub = <select value="giraffe" onChange={noop}> <option value="monkey">A monkey!</option> <option value="giraffe">A giraffe!</option> <option value="gorilla">A gorilla!</option> </select>; stub = ReactTestUtils.renderIntoDocument(stub); var node = ReactDOM.findDOMNode(stub); ReactTestUtils.Simulate.change(node); expect(node.value).toBe('giraffe'); }); </ins> });
Change:
is currently only supported as element, not as attribute in . Since it is unknown to react it's thrown away on render.
I'd like to take this!
It's yours Let me know if you have any questions.
Cool! :+1:
Can we get this into a PR pretty please? :o)
Umm this was merged 3 years ago already...
my apologies. I came across this from a Google search after using cite in blockquote in React 16.8.6 was throwing an error for me at build time. I'll have to dig deeper into the cause.

Discussion:
charSet: null, challenge: null, checked: MUST_USE_PROPERTY | HAS_BOOLEAN_VALUE, <ins> cite: null, </ins> classID: null, className: null, cols: HAS_POSITIVE_NUMERIC_VALUE,
Change:
Looks like is broken on a fresh checkout. Just doing a and locally results in running jasmine1, but running the same commands on a fresh checkout attempts to run jasmine2 and results in 300+ failing unit tests.

Discussion:
"scriptPreprocessor": "scripts/jest/preprocessor.js", "setupEnvScriptFile": "scripts/jest/environment.js", "setupTestFrameworkScriptFile": "scripts/jest/test-framework-setup.js", <ins> "testRunner": "jasmine1", </ins> "testFileExtensions": [ "coffee", "js",
Change:
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.

Discussion:
var adler32 = require('adler32'); var TAG_END = //?>/; <ins> var COMMENT_START = /^<!--/; </ins> var ReactMarkupChecksum = { CHECKSUM_ATTR_NAME: 'data-react-checksum',

addChecksumToMarkup: function(markup) { var checksum = adler32(markup); <del> // Add checksum (handle both parent tags and self-closing tags) return markup.replace( TAG_END, ' ' + ReactMarkupChecksum.CHECKSUM_ATTR_NAME + '="' + checksum + '"$&' ); </del> <ins> // Add checksum (handle both parent tags, comments and self-closing tags) if (markup.test(COMMENT_START)) { return markup; } else { return markup.replace( TAG_END, ' ' + ReactMarkupChecksum.CHECKSUM_ATTR_NAME + '="' + checksum + '"$&' ); } </ins> }, /**

); }); <ins> it('should generate comment markup for component returns null', function() { var NullComponent = React.createClass({ render: function() { return null; }, }); var response = ReactServerRendering.renderToString(<NullComponent />); expect(response).toBe('<!-- react-empty: 1 -->'); }); </ins> it('should not register event listeners', function() { var EventPluginHub = require('EventPluginHub'); var cb = jest.genMockFn();
Change:
Now that react-python is being completely deprecated and will probably cease to function soon with new versions of react ( ) the docs should probably no longer link to it from the Use React and JSX in Python Applications page.
For those following along, I assume is referring to It's an old blog post (with a date), not part of the living docs. We generally don't go back in time and update old posts because things are constantly changing over time and it's hard enough to just keep the main documentation up-to-date. If someone wants to add a red note box that says "Update: PyReact is now deprecated", I think I would be ok with that and we would likely accept such a PR. cc because he feels the strongest about updating historical posts. Anyway, I'm going to close this out to take it off our radar, because we don't generally track/update historical posts.
Meh, If somebody did want to add a note like that, that would be fine. But I don't think we need to change the content of the post. And linking to the actual project is probably good because it has a nice big deprecated notice in the readme.
Ah, I actually hadn't noticed that it's a blog post. It's the thing that comes up when you google "react python" (or anything similar) and is formatted the same as the rest of React's documentation. But yeah, it seems like a shame to have to keep every old blog post up to date. (I suppose after JSXTransformer becomes completely nonfunctional it might be worth making PyReact's deprecation notice a bit stronger, but at this point it's really just nitpicking)

Discussion:
integrity sha512-zIURGIS1E1Q4pcrMjp+nnEh+16G56eG/MUllJH8yEvw7asDo7Ac9uhC9KIH5jzpITueEZolfYglnCGIuSBz39g== axios@^1.6.1: <del> version "1.7.1" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.1.tgz#522145622a09dfaf49359837db9649ff245a35b9" integrity sha512-+LV37nQcd1EpFalkXksWNBiA17NZ5m5/WspmHGmZmdx1qBOg/VNq/c4eRJiA9VQQHBOs+N0ZhhdU10h2TyNK7Q== </del> <ins> version "1.7.4" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.4.tgz#4c8ded1b43683c8dd362973c393f3ede24052aa2" integrity sha512-DukmaFRnY6AzAALSH4J2M3k6PkaC+MfaAGdEERRWcC9q3/TWQwLpHR8ZRLKTdQ3aBDL64EdluRDjJqKw+BPZEw== </ins> dependencies: follow-redirects "^1.15.6" form-data "^4.0.0"
Change:
The does not accept a node engine of version 6.x I don't think that there is some regressions caused by Node v6, so it should be okay?
there is in npm package.
My bad, -- I meant the , you cannot without getting an error with Node v6.0.0.

Discussion:
"uglifyify": "^3.0.1" }, "devEngines": { <del> "node": "4.x || 5.x", </del> <ins> "node": "4.x || 5.x || 6.x", </ins> "npm": "2.x || 3.x" }, "commonerConfig": {
Change:
I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR

Discussion:
} } }, <ins> isProfiling() { return isProfiling; }, </ins> beginProfiling() { if (__DEV__) { if (isProfiling) {

ReactDebugTool.endProfiling(); } <ins> function isRunning() { return ReactDebugTool.isProfiling(); } </ins> var ReactPerfAnalysis = { getLastMeasurements: getFlushHistory, getExclusive,

printOperations, start, stop, <ins> isRunning, </ins> // Deprecated: printDOM, getMeasurementsSummaryMap,

ReactDebugTool.onTestEvent(); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isProfiling state', () => { expect(ReactDebugTool.isProfiling()).toBe(false); ReactDebugTool.beginProfiling(); expect(ReactDebugTool.isProfiling()).toBe(true); ReactDebugTool.endProfiling(); expect(ReactDebugTool.isProfiling()).toBe(false); }); </ins> });

ReactPerf.printDOM(measurements); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isRunning state', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('start has no effect when already running', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('stop has no effect when already stopped', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); </ins> });
Change:
It doesn't match the rest of our text. I think a in the right place in the stylesheet should fix this. !
Pretty sure this is already correct…
It's not. Proxima Nova on the body vs. the default sans system font (San Francisco in the screenshot) in the
The font is indeed different. With font-family inherited: <img width="248" alt="screen shot 2016-09-13 at 00 27 38" src=""Without (current): <img width="244" alt="screen shot 2016-09-13 at 00 27 48" src=""
touché - I had unchecked the browser-styles box in my inspector at some point and so it showed it inheriting the html style… oops. (the Proxima Nova "R" and SF "R" look similar enough that it fooled me too). We could probably just make in as opposed to targeting just this one - we already have that for headers.
Adjusted the PR to include just that
Closed with

Discussion:
line-height: 20px; } a { color: $linkColor; text-decoration: none;

.center { text-align: center; } <ins> input { font-family: inherit; } </ins>