jiebi/CodeConvo huggingface dataset:
Change:
// 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);

Discussion:
I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.
Change:
#### Events <del> React attaches event handlers to components using a camelCase naming convention. We attach an onKeyUp handler to the text field, check if the user has entered text and pressed the enter key and then clear the form fields. </del> <ins> React attaches event handlers to components using a camelCase naming convention. We attach an `onSubmit` handler to the form that clears the form fields when the form is submitted with valid input. We always return `false` from the event handler to prevent the browser's default action of submitting the form. (If you prefer, you can instead take the event as an argument and call `preventDefault()` on it &ndash; read more about [event handling](event-handling.html).) </ins> `React.autoBind()` is a simple way to ensure that a method is always bound to its component. Inside the method, `this` will be bound to the component instance.

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> 'use strict'; var grunt = require('grunt'); module.exports = function() { var done = this.async(); grunt.util.spawn({ cmd: 'node_modules/eslint-tester/node_modules/mocha/bin/mocha', args: ['eslint-rules/__tests__'], opts: {stdio: 'inherit'}, // allows colors to passthrough }, function(err, result, code) { if (err) { grunt.log.error('Custom linter rules are broken'); } else { grunt.log.ok('Custom linter rules are okay'); } done(code === 0); }); }; </del>

Discussion:
using npm mocha is not necessarily at (thanks to hoisting). (eg it's actually at for me)
We've found out that it's possible to use eslint-tester with jest, so we should just do that.
Change:
}); it('accepts custom comparison function', async () => { <del> const {Suspense} = React; </del> function Counter({count}) { return <Text text={count} />; }

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:
getInitialStateWasCalled = true; return {}; } <ins> getDefaultProps() { getDefaultPropsWasCalled = true; return {}; } </ins> render() { return <span className="foo" />; } } test(<Foo />, 'SPAN', 'foo'); expect(getInitialStateWasCalled).toBe(false); <del> expect(console.error.calls.length).toBe(3); </del> <ins> expect(getDefaultPropsWasCalled).toBe(false); expect(console.error.calls.length).toBe(4); </ins> expect(console.error.calls[0].args[0]).toContain( 'getInitialState was defined on Foo, a plain JavaScript class.' ); expect(console.error.calls[1].args[0]).toContain( <del> 'propTypes was defined as an instance property on Foo.' </del> <ins> 'getDefaultProps was defined on Foo, a plain JavaScript class.' </ins> ); expect(console.error.calls[2].args[0]).toContain( <ins> 'propTypes was defined as an instance property on Foo.' ); expect(console.error.calls[3].args[0]).toContain( </ins> 'contextTypes was defined as an instance property on Foo.' ); });

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:
case 'form': case 'video': case 'audio': <del> this._wrapperState = { listeners: null, }; transaction.getReactMountReady().enqueue(trapBubbledEventsLocal, this); </del> <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> break; case 'button': props = ReactDOMButton.getNativeProps(this, props, nativeParent); break; case 'input': <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> ReactDOMInput.mountWrapper(this, props, nativeParent); props = ReactDOMInput.getNativeProps(this, props); break;

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

Discussion:
Flattening children to an array is 20 times faster than flattening to an object. For long list of elements, this shows up on the initial render flame graphs as pretty hot.
Change:
); } }); <ins> PageTwoContent = React.createFactory(PageTwoContent); </ins> /** Application popup page component. */ var PagePopUpContent = 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.
Change:
break; } case 'unknown': { <del> // If we don't know how this extension was built, we can't reliably detect if there // are other installations of DevTools present. // In this case, assume there are no duplicate exensions and show a warning about // potential conflicts. console.error(UNRECOGNIZED_EXTENSION_ERROR); chrome.devtools.inspectedWindow.eval( `console.error("${UNRECOGNIZED_EXTENSION_ERROR}")`, ); </del> <ins> // TODO: Support duplicate extension detection in other browsers if (IS_CHROME) { // If we don't know how this extension was built, we can't reliably detect if there // are other installations of DevTools present. // In this case, assume there are no duplicate exensions and show a warning about // potential conflicts. console.error(UNRECOGNIZED_EXTENSION_ERROR); chrome.devtools.inspectedWindow.eval( `console.error("${UNRECOGNIZED_EXTENSION_ERROR}")`, ); } </ins> callback(false); break; }

Discussion:
React DevTools v4.20.0 in Firefox in Firefox Firefox DevTools error in console ! Every time
Change:
render: function() { // Clone `this.props` so we don't mutate the input. var props = merge(this.props); <del> var value = LinkedValueUtils.getValue(this); </del> invariant( props.dangerouslySetInnerHTML == null,

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

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? Calling in in prior versions would return . Now it returns . I believe this was untested behavior before, but the new tests that were may check the wrong value: Changing this line to test for will exhibit the behavior. The fix would be to defer setting the flag to until after all mixins and the method were called on the component. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? and anything using is broken. Working correctly in 15.4.x with .
I fixed this locally by splitting the IsMountedMixin into two: Then installing the Post after the spec has been mixed in: For the life of me I can't find the right repo to PR this against though.
This should be fixed with . Can you please verify?
I don't see that version published yet.
It's not set to (still an RC) but it exists: Will turn into 15.6.0 tomorrow.
Ah indeed. It's probably our internal registry being slow. I'll try it out soon.
Confirmed working correctly in .
Great. Thanks for sending the fix!
Change:
}, "dependencies": { "base62": "~0.1.1", <del> "commoner": "~0.6.8", </del> <ins> "commoner": "~0.7.0", </ins> "esprima": "git://github.com/facebook/esprima#fb-harmony", <del> "recast": "~0.3.3", </del> <ins> "recast": "~0.4.5", </ins> "source-map": "~0.1.22" }, "devDependencies": {

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:
export function flushSync<A, R>(fn: A => R, a: A): R { const prevExecutionContext = executionContext; <del> if ((prevExecutionContext & (RenderContext | CommitContext)) !== NoContext) { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } return fn(a); } </del> executionContext |= BatchedContext; const previousPriority = getCurrentUpdatePriority();

Discussion:
flushSync early returns if it detects it's in the commit (or render) phase, since it can't synchronously flush when React is already working. However, it should still change the priority of updates scheduled by the callback to be synchronous. This mostly already works because the commit phase itself has a sync event priority context, but the passive effect phase doesn't. Need more tests for this.
Change:
var ReactComponent = require('ReactComponent'); var ReactDOM = require('ReactDOM'); var ReactMount = require('ReactMount'); <ins> var ReactProps = require('ReactProps'); </ins> var ReactServerRendering = require('ReactServerRendering'); var ReactDefaultInjection = require('ReactDefaultInjection');

Discussion:
! The only alternative is using chains which aren't very readable at their own.
I think you're making it more complicated than it needs to be. If it uses some prop like : However, note that this doesn't guarantee requests come in order. So a better solution would be: This is a good article that goes into more detail and has more useful examples: In longer term, we'll recommend Suspense for data fetching which will look more like and no effects. But in the meantime the code above works fine.
What if I need to close over ? (Or based on your example): Also where do the errors go that are thrown in that async function invocation? I'd need to it? Or try/catch the body of the async so the promise always resolves? Why not make useEffect take an async function if we'd have to wrap them all the time anyways?
I guess one can always just :
now I should use instead of into a React Component with Hooks. Scenario "initial unique call to a server": To accomplished this, DependencyList ( second argument of useEffect) in useEffect should every time an empty array otherwise the application will send every state change a fetch call to the server. it' means , this it the best practise to getData ` Full Code here <details
Please ask on StackOverflow and feel free to link to your question from here. We don’t use issues for support because answers get lost on GitHub.
supports being async so I think useEffect should accept a promise and automatically resolve it to avoid having to them.
It is an intentional design decision. The async/await model is a pitfall for effects in general (and has always been a pitfall in classes!) due to race conditions. In the longer term, Suspense will be the recommended data fetching solution, and you can do / there. But Suspense for data fetching is not ready yet.
As I explained above, is a bad idea because you don't know whether is still relevant. For example, if the user starts fetching one profile page but then switches to another profile. Then you're at the mercy of which request arrives first, and can show incorrect data. This kind of code would handle it correctly: I'm going to lock this issue as resolved to prevent further confusion. Here's a good article that answers your other questions (e.g. about loading states):
Change:
<ins> /** * Copyright 2014-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. * * @emails react-core */ 'use strict'; require('mock-modules') .dontMock('shallowEqual'); var shallowEqual; describe('shallowEqual', function() { beforeEach(function() { shallowEqual = require('shallowEqual'); }); it('returns false if either argument is null', function() { expect(shallowEqual(null, {})).toBe(false); expect(shallowEqual({}, null)).toBe(false); }); it('returns true if both arguments are null or undefined', function() { expect(shallowEqual(null, null)).toBe(true); expect(shallowEqual(undefined, undefined)).toBe(true); }); it('returns true if arguments are shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2, c: 3} ) ).toBe(true); }); it('returns false if first argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2} ) ).toBe(false); }); it('returns false if second argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2}, {a: 1, b: 2, c: 3} ) ).toBe(false); }); it('returns false if arguments are not shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: {}}, {a: 1, b: 2, c: {}} ) ).toBe(false); }); }); </ins>

Discussion:
Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1