jiebi/CodeConvo huggingface dataset:
Change:
topError:           eventTypes.error, topFocus:           eventTypes.focus, topInput:           eventTypes.input, <ins> topInvalid:         eventTypes.invalid, </ins> topKeyDown:         eventTypes.keyDown, topKeyPress:        eventTypes.keyPress, topKeyUp:           eventTypes.keyUp,

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:
<ins> ## 4.4.0 * No changes, this was an automated release together with React 18. </ins> ## 4.3.0 * Support ESLint 8. ([@MichaelDeBoey](https://github.com/MichaelDeBoey) in [#22248](https://github.com/facebook/react/pull/22248))

Discussion:
Currently the CHANGELOG shows 4.3.0 as the latest version of , but at least on , there is not a 4.4.0. React version: n/a Changelog to version on Link to code example: n/a No 4.4.0 explanation in 0 explanation in
I think 4.4.0 was essentially a no-op release to correspond with React 18 release (though cc to confirm). Looking at what's changed in the package between the 4.3.0 release and Monday's 4.4.0 "release" I see: I believe this is the same thing as happened with the ESLint 4.2.0 release and React 17. I believe the "fix" here would be to just add a 4.4.0 release to the CHANGELOG that notes this.
Thanks so much That definitely seems like the right fix!
Change:
2. If you've added code that should be tested, add tests! 3. If you've changed APIs, update the documentation. 4. Ensure the test suite passes (`npm test`). <del> 5. Make sure your code lints (`npm run lint`). 6. Format your code with [prettier](https://github.com/prettier/prettier) (`npm run prettier`). </del> <ins> 5. Format your code with [prettier](https://github.com/prettier/prettier) (`npm run prettier`). 6. Make sure your code lints (`npm run lint`). </ins> 7. Run the [Flow](https://flowtype.org/) typechecks (`npm run flow`). 8. If you added or removed any tests, run `./scripts/fiber/record-tests` before submitting the pull request, and commit the resulting changes. 9. If you haven't already, complete the CLA.

Discussion:
Do you want to request a feature or report a bug? This is more of a documentation discussion What is the current behavior? Currently, the contributing guide lists the lint step before running prettier. For example, says: 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: ). What is the expected behavior? I think it would make more sense to run prettier first, since it can automatically get rid of certain lint errors (like single-quotes or comma-dangle). A first-time contributor following the steps in order might waste time fixing things manually at the lint step before proceeding to the formatting step. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? N/A
Happy to take PR fixing it.
Thanks to reminding, I make a PR for it.
Seems like this was fixed.
Change:
$RefreshReg$(_c2, "Bar"); `; <ins> exports[`ReactFreshBabelPlugin uses custom identifiers for $RefreshReg$ and $RefreshSig$ 1`] = ` var _s = import.meta.refreshSig(); export default function Bar() { _s(); useContext(X); return <Foo />; } _s(Bar, "useContext{}"); _c = Bar; ; var _c; import.meta.refreshReg(_c, "Bar"); `; </ins> exports[`ReactFreshBabelPlugin uses original function declaration if it get reassigned 1`] = ` function Hello() { return <h1>Hi</h1>;

Discussion:
Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.
Change:
// eslint-disable-next-line no-fallthrough case 'mouseenter': case 'mouseleave': <ins> case 'pointerenter': case 'pointerleave': </ins> return ContinuousEventPriority; case 'message': { // We might be in the Scheduler callback.

Discussion:
Currently the simple event plugin defines a priority for the event but not all events go through the SimpleEventPlugin. That's just one of several EventPlugins. The remaining ones now get the wrong priority associated with them. E.g. I think all of these should be discrete: change compositionend compositionstart compositionupdate selectionchange textinput These show up too but I don't know if they're even bridged. dblclick pointerenter pointerleave Flare defines its own priorities.
Change:
captured: keyOf({onInputCapture: true}), }, }, <ins> invalid: { phasedRegistrationNames: { bubbled: keyOf({onInvalid: true}), captured: keyOf({onInvalidCapture: true}), }, }, </ins> keyDown: { phasedRegistrationNames: { bubbled: keyOf({onKeyDown: true}),

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:
<ins> /** * Copyright 2013-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. * * @jsx React.DOM * @emails react-core */ "use strict"; var React; var ReactDescriptor; describe('ReactDescriptor', function() { beforeEach(function() { React = require('React'); ReactDescriptor = require('ReactDescriptor'); }); it('should identify valid descriptors correctly', function() { var Component = React.createClass({ render: function() { return <div />; } }); expect(ReactDescriptor.isValidDescriptor(<div />)).toEqual(true); expect(ReactDescriptor.isValidDescriptor(<Component />)).toEqual(true); expect(ReactDescriptor.isValidDescriptor(null)).toEqual(false); expect(ReactDescriptor.isValidDescriptor(true)).toEqual(false); expect(ReactDescriptor.isValidDescriptor({})).toEqual(false); expect(ReactDescriptor.isValidDescriptor("string")).toEqual(false); expect(ReactDescriptor.isValidDescriptor(React.DOM.div)).toEqual(false); expect(ReactDescriptor.isValidDescriptor(Component)).toEqual(false); }); }); </ins>

Discussion:
The last two assertions in this new test don't pass because of the duck-typing check in . Not quite sure what you had in mind here. Not every object whose is a component class is a valid descriptor… right?
This is an intermediate step. Currently the duck typing is flawed regardless. Descriptors will probably get an inheritance chain so that instanceof ReactDescriptor works as a safer check. Only descriptors should pass. We could probably check for props too. It is expected that component classes themselves fail the test. Therefore it should also be renamed. On Feb 24, 2014, at 7:42 AM, Ben Alpert wrote:
Right -- with the current code, returns true when passed a component class, which is wrong.
That's right. We should add that unit test. Out of curiosity, how did you find this? On Feb 24, 2014, at 1:51 PM, Ben Alpert wrote:
I was adding a warning for passing a component class to renderComponent because of this Stack Overflow question:
I think this is fixed. Not sure if we have a solid unit test to cover this.
Change:
const {type} = this._element; if (typeof type.getDerivedStateFromProps === 'function') { <del> if (__DEV__) { const instance = this._instance; // If getDerivedStateFromProps() is defined, "unsafe" lifecycles won't be called. // Warn about these lifecycles if they are present. // Don't warn about react-lifecycles-compat polyfilled methods though. let foundWillMountName = null; let foundWillReceivePropsName = null; let foundWillUpdateName = null; if ( typeof instance.componentWillMount === 'function' && instance.componentWillMount.__suppressDeprecationWarning !== true ) { foundWillMountName = 'componentWillMount'; } else if (typeof instance.UNSAFE_componentWillMount === 'function') { foundWillMountName = 'UNSAFE_componentWillMount'; } if ( typeof instance.componentWillReceiveProps === 'function' && instance.componentWillReceiveProps.__suppressDeprecationWarning !== true ) { foundWillReceivePropsName = 'componentWillReceiveProps'; } else if ( typeof instance.UNSAFE_componentWillReceiveProps === 'function' ) { foundWillReceivePropsName = 'UNSAFE_componentWillReceiveProps'; } if (typeof instance.componentWillUpdate === 'function') { foundWillUpdateName = 'componentWillUpdate'; } else if (typeof instance.UNSAFE_componentWillUpdate === 'function') { foundWillUpdateName = 'UNSAFE_componentWillUpdate'; } if ( foundWillMountName !== null || foundWillReceivePropsName !== null || foundWillUpdateName !== null ) { const componentName = getName(type, instance) || 'Component'; if (!didWarnAboutLegacyLifecyclesAndDerivedState[componentName]) { warning( false, 'Unsafe legacy lifecycles will not be called for components using ' + 'the new getDerivedStateFromProps() API.nn' + '%s uses getDerivedStateFromProps() but also contains the following legacy lifecycles:' + '%s%s%snn' + 'The above lifecycles should be removed. Learn more about this warning here:n' + 'https://fb.me/react-async-component-lifecycle-hooks', componentName, foundWillMountName !== null ? `n  ${foundWillMountName}` : '', foundWillReceivePropsName !== null ? `n  ${foundWillReceivePropsName}` : '', foundWillUpdateName !== null ? `n  ${foundWillUpdateName}` : '', ); didWarnAboutLegacyLifecyclesAndDerivedState[componentName] = true; } } } </del> const partialState = type.getDerivedStateFromProps.call( null, props, this._instance.state, ); <del> if (__DEV__) { if (partialState === undefined) { const componentName = getName(type, this._instance); if (!didWarnAboutUndefinedDerivedState[componentName]) { warning( false, '%s.getDerivedStateFromProps(): A valid state object (or null) must be returned. ' + 'You have returned undefined.', componentName, ); didWarnAboutUndefinedDerivedState[componentName] = componentName; } } } </del> if (partialState != null) { const oldState = this._newState || this._instance.state; const newState = Object.assign({}, oldState, partialState);

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:
if (!isAnimationFrameScheduled) { // Schedule another animation callback so we retry later. isAnimationFrameScheduled = true; <del> requestAnimationFrameForReact(animationTick); </del> <ins> localRequestAnimationFrame(animationTick); </ins> } } };

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? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in
Change:
let React; let ReactFeatureFlags; let ReactNoop; <ins> let Suspense; </ins> describe('memo', () => { beforeEach(() => {

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:
topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ) { var eventType; var fallbackData;

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:
}); it('supports non-pure class components', async () => { <del> const {Suspense} = React; </del> class CounterInner extends React.Component { static defaultProps = {suffix: '!'}; render() {

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:
if (type === null || type === undefined || typeof type === 'string') { return; } <del> const name = getComponentName(type); </del> let propTypes; if (typeof type === 'function') { propTypes = type.propTypes;

Discussion:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 17.0.0-rc.1 elements out of components, use them conditionally. if the components are dynamically imported. <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: -- : : : : : <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --The chunk is imported eagerly, even though the component isn't immediately rendered. ! This doesn't happen in prod mode, or with React 16, or with components that are not -ed eagerly. This affects react-router, as it uses this pattern: AFAICT it doesn't break anything, but it is unexpected/confusing. components that are not rendered should not be dynamically imported.
Shorter test case: This is enough to trigger the dynamic import in dev mode.
Behavior changed between 16.13.1 and the first release after . ! !
This is triggered by in . I think this doesn't really make sense to call but we'd need to see why this change to was made. <img width="398" alt="Screenshot 2020-09-03 at 13 56 14" src="https://user-"<img width="367" alt="Screenshot 2020-09-03 at 13 56 18" src="https://user-"
The suspense protocol is just a function that may throw. That allows for low overhead abstractions to be wrapped. This change was to allow the init function to encapsulate the actual suspense mechanism and that data structure. Unfortunately there’s no way to query the status of something in the suspense protocol without triggering the fetch. Same as you can’t do: Without triggering a fetch. The solution might be to move validation of lazy until it’s rendered instead of in createElement. Also, sigh PropTypes.

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.
Change:
); } } <ins> }, checked: function(props, propName, componentName) { if (__DEV__) { if (props[propName] && !props.onChange && !props.readOnly && !props.disabled) { console.warn( 'You provided a `checked` prop to a form field without an ' + '`onChange` handler. This will render a read-only field. If ' + 'the field should be mutable use `defaultChecked`. Otherwise, ' + 'set either `onChange` or `readOnly`.' ); } } </ins> } } },

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:
var npmReactDOMTasks = require('./grunt/tasks/npm-react-dom'); grunt.registerTask('npm-react-dom:pack', npmReactDOMTasks.packRelease); <del> var gemReactSourceTasks = require('./grunt/tasks/gem-react-source'); grunt.registerTask('gem-react-source:release', gemReactSourceTasks.buildRelease); grunt.registerTask('gem-react-source:pack', gemReactSourceTasks.packRelease); </del> grunt.registerTask('version-check', require('./grunt/tasks/version-check')); grunt.registerTask('build:basic', [

Discussion:
I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)