jiebi/CodeConvo huggingface dataset:
Change:
Let's make the form interactive. When the user submits the form, we should clear it, submit a request to the server, and refresh the list of comments. To start, let's listen for the form's submit event and clear it. <del> ```javascript{3-12,15,20} </del> <ins> ```javascript{3-13,16,21} </ins> // tutorial16.js var CommentForm = React.createClass({ handleSubmit: React.autoBind(function() { var author = this.refs.author.getDOMNode().value.trim(); var text = this.refs.text.getDOMNode().value.trim(); if (!text || !author) { <del> return; </del> <ins> return false; </ins> } // TODO: send request to the server this.refs.author.getDOMNode().value = ''; this.refs.text.getDOMNode().value = ''; <ins> return false; </ins> }), render: function() { return (

Discussion:
Do you want to request a feature or report a bug? bug What is the current behavior? When using the latest Dev tools (v4.0.5) on my project, when I inspect react-redux elements that use connect() devtools crashes. I can't map from my crash to the actual source but the code is react devtools: up one level of stack is react: and up one level is react-redux: () 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'll have to try and make a small repro, but I hope there's something obvious given the info above. It's not clear to me if react-redux is doing something or if its devtools. This behavior existed in v3 and i was hoping it'd get magically fixed with v4 but it remains. What is the expected behavior? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? This is in an electron app w/ react-redux v7.1.0 and react v16.8.3 (have to use this due to the version of react native i'm on)
Unfortunately this is a bug with React that was fixed via PR and released with v16.8.4. Thank you for the detailed bug report though! Originally reported here:
Change:
{ <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"

Discussion:
Follow-up for : The react-addons-* packages should have a entry in their files.
Change:
restorePendingUpdaters, addTransitionStartCallbackToPendingTransition, addTransitionCompleteCallbackToPendingTransition, <ins> setIsRunningInsertionEffect, </ins> } from './ReactFiberWorkLoop.old'; import { NoFlags as NoHookEffect,

Discussion:
Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?
Change:
expectHookNamesToEqual(hookNames, ['foo', 'bar', 'baz']); }); <del> it('should return null for hooks without names like useEffect', async () => { </del> <ins> it('should skip loading source files for unnamed hooks like useEffect', async () => { </ins> const Component = require('./__source__/__untransformed__/ComponentWithUseEffect') .Component; <ins> // Since this component contains only unnamed hooks, the source code should not even be loaded. fetchMock.mockIf(/.+$/, request => { throw Error(`Unexpected file request for "${request.url}"`); }); </ins> const hookNames = await getHookNamesForComponent(Component); expectHookNamesToEqual(hookNames, []); // No hooks with names }); <ins> it('should skip loading source files for unnamed hooks like useEffect (alternate)', async () => { const Component = require('./__source__/__untransformed__/ComponentWithExternalUseEffect') .Component; fetchMock.mockIf(/.+$/, request => { // Since th custom hook contains only unnamed hooks, the source code should not be loaded. if (request.url.endsWith('useCustom.js')) { throw Error(`Unexpected file request for "${request.url}"`); } return Promise.resolve(requireText(request.url, 'utf8')); }); const hookNames = await getHookNamesForComponent(Component); expectHookNamesToEqual(hookNames, ['count', null]); // No hooks with names }); </ins> it('should parse names for custom hooks', async () => { const Component = require('./__source__/__untransformed__/ComponentWithNamedCustomHooks') .Component;

Discussion:
Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.
Change:
<ins> # Reporting Security Issues If you believe you have found a security vulnerability in React, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem. Please refer to the following page for our responsible disclosure policy, reward guidelines, and those things that should not be reported: https://www.facebook.com/whitehat </ins>

Discussion:
Feature requested GitHub has just released the Security Policy feature, by writing the file a new tab with security informations should appear in the repository. You can check the It will really improve people trusting in open source security standards
Added in the above commit
Change:
}); <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> });

Discussion:
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
Change:
}; /** <del> * (For old IE.) Starts tracking propertychange events on the passed-in element </del> <ins> * (For IE <=11) Starts tracking propertychange events on the passed-in element </ins> * and override the value property so that we can distinguish user events from * value changes in JS. */

Discussion:
Check: Tested in IE10. Likely related to .
We're having issues with this too and had to put in a workaround to deal with it. is this on your roadmap?
Having the same issue with on using IE 11.0.
I have the same issue as when adding a placeholder a textarea, with no value, the onChange event is fired.
I hava the same issue. A input with a placeholder and no value, the onChange event is fired.

See for example code. When setting and removing focus from an empty field with some text, the event is triggered for IE 11 (I have not tested older versions). It does not trigger for other browsers. My current work-around is to test the that was last passed to the input with what is returned by , and only act if they are different, but it would be nice if React would not send the change-event in the first place.
Sounds like a browser quark that we should normalize against, right? Is there anything other than value that we would need to check?
Yeah, this seems odd. Probably on the challenging side for a first bug, but it would be good to figure out why this is happening and how we can prevent it, while still making it possible to type the placeholder text in directly as says.
, not really related but I imagine both could be solved by a similar fix.
Also goes for IE10.
Change:
return; } <del> if (profilingData !== null) { </del> <ins> if (profilingData !== null && downloadRef.current !== null) { </ins> const profilingDataExport = prepareProfilingDataExport(profilingData); const date = new Date(); const dateString = date

Discussion:
Hi, long time user, first time issuer. I think I found a bug with the Profiler component. When I click on the button at the top nothing happens and there appears to be no new files in my Downloads folder. I think it might be silently failing and that's why I am not getting any response. Has anyone else ran into this issue? Another thing I would like to mention is that I haven't looked through all of the documentation material about the new Profiler. I only read , so if this issue is addressed elsewhere I apologize and also request the source to that solution. Thank you for your time! Versions: *
It seems that this is happening because of the call in the util function. I'll investigate this further.
I fixed the issue. I'll open a PR later today :)
Change:
// delete restores the original property definition delete activeElement.value; <del> activeElement.detachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.detachEvent) { activeElement.detachEvent('onpropertychange', handlePropertyChange); } else { activeElement.removeEventListener('propertychange', handlePropertyChange, false); } </ins> activeElement = null; activeElementID = null;

Discussion:
Check: Tested in IE10. Likely related to .
We're having issues with this too and had to put in a workaround to deal with it. is this on your roadmap?
Having the same issue with on using IE 11.0.
I have the same issue as when adding a placeholder a textarea, with no value, the onChange event is fired.
I hava the same issue. A input with a placeholder and no value, the onChange event is fired.

See for example code. When setting and removing focus from an empty field with some text, the event is triggered for IE 11 (I have not tested older versions). It does not trigger for other browsers. My current work-around is to test the that was last passed to the input with what is returned by , and only act if they are different, but it would be nice if React would not send the change-event in the first place.
Sounds like a browser quark that we should normalize against, right? Is there anything other than value that we would need to check?
Yeah, this seems odd. Probably on the challenging side for a first bug, but it would be good to figure out why this is happening and how we can prevent it, while still making it possible to type the placeholder text in directly as says.
, not really related but I imagine both could be solved by a similar fix.
Also goes for IE10.
Change:
await test( './__source__/__compiled__/external/ComponentWithMultipleHooksPerLine', ); // external source map <del> await test( './__source__/__compiled__/bundle', 'ComponentWithMultipleHooksPerLine', ); // bundle source map </del> <ins> // await test( //   './__source__/__compiled__/bundle', //   'ComponentWithMultipleHooksPerLine', // ); // bundle source map </ins> }); // TODO Inline require (e.g. require("react").useState()) isn't supported yet.

Discussion:
Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.
Change:
expect(Component.pqr()).toBe(Component.type); }); <ins> it('should throw if a reserved property is in statics', function() { expect(function() { React.createClass({ statics: { getDefaultProps: function() { return { foo: 0 }; } }, render: function() { return <span />; } }); }).toThrow( 'Invariant Violation: ReactCompositeComponent: You are attempting to ' + 'define a reserved property, `getDefaultProps`, that shouldn't be on ' + 'the "statics" key. Define it as an instance property instead; it ' + 'will still be accessible on the constructor.' ); }); </ins> it('should support statics in mixins', function() { var Mixin = { statics: {

Discussion:
This logs both and : This seems weird to me and inconsistent with the behavior for non-static functions. Can we change this to give an error too?
Change:
__source: true, }; <ins> var specialPropKeyWarningShown, specialPropRefWarningShown; </ins> /** * Factory method to create a new React element. This no longer adheres to * the class pattern, so do not use new to call it. Also, no instanceof check

Discussion:
The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.
Change:
--- id: getting-started-ja-JP title: 始めてみましょう <ins> permalink: getting-started-ja-JP.html </ins> next: tutorial-ja-JP.html redirect_from: "docs/index-ja-JP.html" ---

Discussion:
At gh-pages branch, there are and files. I think those file name must be and .
Thanks! I just pushed the change to the stable branch so this should be updated on the site and in the gh-pages branch as soon as it builds.
Thanks!
Change:
but does not invoke them.', -> spyOn console, 'error' getInitialStateWasCalled = false <ins> getDefaultPropsWasCalled = false </ins> class Foo extends React.Component constructor: -> @contextTypes = {}

Discussion:
I am working on a very simple component with default props. And I simply render it without any props (). But I got an empty object from console output. I am using react 0.13.1, chrome 41, OSX 10.10. Any idea what is going wrong?
Es6 classes need defaultProps as a static property. Navigation.defaultProps = {...}
Thanks. Maybe update this in documentation :) ? I will be happy to send in a PR
has some commentary on docs and es6. I agree that I’d like to see better docs on the class syntax. I’m just a guy who happened to see your issue really quickly :)
does reference this. It might be good to also put some documentation in to make it a bit easier to find. I'm going to close this out since it's invalid but I'd love to see a PR with more docs :)
I think you should have also seen a runtime warning for this?
not really, though
Thanks, looks like an oversight. Fix incoming…
Change:
return DevtoolsUI; } <ins> function setDisconnectedCallback(value: OnDisconnectedCallback) { disconnectedCallback = value; return DevtoolsUI; } </ins> let bridge: FrontendBridge | null = null; let store: Store | null = null; let root = null;

Discussion:
Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!
Change:
accumulateEnterLeaveDispatches(leave, enter, from, to); <ins> if (isOutEvent && from && nativeEventTarget !== fromNode) { return [leave]; } </ins> return [leave, enter]; }, };

Discussion:
Do you want to request a feature or report a bug? I want to report a bug. What is the current behavior? Event handlers on elements are fired twice, when hovering from one element onto the next. 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? Event handlers should only fire once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.8.4 ReactDOM 16.8.4 Chrome 76.0.3809.132 Firefox 69.0 (64-Bit) Edge 44..267.0
After testing it again and again, I found how to reproduce it: Step 1, render a new component inside a rendered component; Step 2, inside the new component, mouse enter a node from its sibling. Current result: onMouseEnter is called more than once. Demo: We may change the issue title because it's not related with . I've made a test and fixture for this: Hope the information can be helpful. I still have no idea how to fix it. If there's no one working on this, I would like to pick this up. There's a similar issue Do you have any advice?
Go for it,
Let's close this? I see the fix was merged in .
Change:
`require('React')` statement in your code files and if you access React as a global. <del> `react-to-react-dom` updates code for the split of the `react` and `react-dom` packages (e.g., `React.render` to `ReactDOM.render`). It looks for `require('react')` and replaces the appropriate property accesses using `require('react-dom')`. It does not support ES6 modules or other non-CommonJS systems. * `jscodeshift -t react/packages/react-codemod/transforms/react-to-react-dom.js <file>` * After running the automated codemod, you may want to run a regex-based find-and-replace to remove extra whitespace between the added requires, such as `codemod.py -m -d src --extensions js '(var Reacts*=s*require(.react.);)nn(s*var ReactDOM)' '1n2'` using https://github.com/facebook/codemod. </del> ### Explanation of the ES2015 class transform * Ignore components with calls to deprecated APIs. This is very defensive, if

Discussion:
I tried doing the following to pick up react-dom: However, it said that the only version available was Poking around on Github yielded a repo called that appears to be linked to Bower. I'm guessing this isn't the right library; what's the dependency installation story going to look like with Bower?
Never mind, just found that it shipped in the same package. However, the documentation is misleading on the :
Thanks, we should fix that.
Change:
var args = [ "bin/jsx", "--cache-dir", ".module-cache", <ins> "--relativize", </ins> config.sourceDir, config.outputDir ];

Discussion:
React version: 16.8.0 an app that toggles between rendering a text input and a date input. the of each to some arbitrary input, valid for either one toggling occurs that the value of the date input is not preserved upon toggle The date input's value is not preserved The date input's value should be preserved We discovered a simple workaround--add a unique property to each input, and the value will be respected.
It seems to be the default correct behaviour. You can read more about how works here. The reason it seems to work by adding the key prop is because the component gets re-rendered from scratch and therefore the "works". I think what you want to achieve is pretty date display when not in edit mode. Maybe something like this. Demo Prototype code
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
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:
} /** <ins> * Sets the text content of `node` to `text`. * * @param {DOMElement} node Node to change * @param {string} text New text content */ var updateTextContent; if (textContentAccessor === 'textContent') { updateTextContent = function(node, text) { node.textContent = text; }; } else { updateTextContent = function(node, text) { // In order to preserve newlines correctly, we can't use .innerText to set // the contents (see #1080), so we empty the element then append a text node while (node.firstChild) { node.removeChild(node.firstChild); } if (text) { var doc = node.ownerDocument || document; node.appendChild(doc.createTextNode(text)); } }; } /** </ins> * Operations for updating with DOM children. */ var DOMChildrenOperations = { dangerouslyReplaceNodeWithMarkup: Danger.dangerouslyReplaceNodeWithMarkup, <ins> updateTextContent: updateTextContent, </ins> /** * Updates a component's children by processing a series of updates. The * update configurations are each expected to have a `parentNode` property.

Discussion:
On re-render, we innerText. This causes inconsistencies in rendering whitespace. See demo: We should make sure this doesn't happen.
We switched to use but it broke some contentEditable stuff internal to FB. knows more.
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer
looks like this was brought up in
Right, we should also do the right thing in IE8.
jQuery empties then adds a text node. Relevant commits: ()
okay interesting. I'll do this for ie8
I have a patch almost ready.
I'm curious if is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML.
hmm interesting. We definitely want to preserve whitespace though. (because of and and )