jiebi/CodeConvo huggingface dataset:
Change:
// Compute `paths` and cache it. Guarding against cycles. cache.set(segment.id, null); <del> if (segment.nextSegments.length === 0) { </del> <ins> if (codePath.thrownSegments.includes(segment)) { paths = 0; } else if (segment.nextSegments.length === 0) { </ins> paths = 1; } else { paths = 0;

Discussion:
I believe this should be a valid case, because throw.
Hmm, I just realized throw should not be used for valid business case (GraphQL endpoint was updated). Render nothing (and request app update) is the correct approach.
I think we shouldn't warn on this.
Change:
<span className="child2" /> ]); <del> shallowRenderer.render(<SomeComponent aNew="prop" />, {}); </del> <ins> shallowRenderer.render(<SomeComponent aNew="prop" />); </ins> var updatedResult = shallowRenderer.getRenderOutput(); expect(updatedResult.type).toBe('a');

Discussion:
I am trying to render a component using the preliminary shadow renderer support in TestUtils. A simple reproducible test case of my issue is this When I run this in my Jest test, I get: It looks like this error is thrown whenever the component being rendered has . I thought perhaps the context was required (although I haven't had any problems omitting it in my actual app), but even when using I get the same exception.
I think this is a known issue with shallow rendering. cc
thanks for the report. Context isn't meant to be supported with shallow rendering (i.e., we haven't tested it), but it looks like you may be able to work around this problem by passing an object as the second argument to : it looks like an additional argument was to the shallow rendering API in . What was the thinking here? Can we default this to an empty object?
Thanks, the workaround works great. And I see you posted a fix as well so looking forward to that.
Change:
continue; } <ins> var isReserved = name in RESERVED_SPEC_KEYS; invariant( !isReserved, 'ReactCompositeComponent: You are attempting to define a reserved ' + 'property, `%s`, that shouldn't be on the "statics" key. Define it ' + 'as an instance property instead; it will still be accessible on the ' + 'constructor.', name ); </ins> var isInherited = name in Constructor; <del> var result = property; if (isInherited) { var existingProperty = Constructor[name]; var existingType = typeof existingProperty; var propertyType = typeof property; invariant( existingType === 'function' && propertyType === 'function', 'ReactCompositeComponent: You are attempting to define ' + '`%s` on your component more than once, but that is only supported ' + 'for functions, which are chained together. This conflict may be ' + 'due to a mixin.', name ); result = createChainedFunction(existingProperty, property); } Constructor[name] = result; </del> <ins> invariant( !isInherited, 'ReactCompositeComponent: You are attempting to define ' + '`%s` on your component more than once. This conflict may be ' + 'due to a mixin.', name ); Constructor[name] = property; </ins> } }

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:
expect(container.firstChild.getAttribute('value')).toBe('foo'); expect(container.firstChild.value).toBe('foo'); }); <ins> it('should not remove attributes for custom component tag', () => { const container = document.createElement('div'); ReactDOM.render(<my-icon size="5px" />, container); expect(container.firstChild.getAttribute('size')).toBe('5px'); }); </ins> }); });

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. 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: Sorry, it's a CodePen. This example uses a framework called OnsenUI that internally uses web components. In the OnsenUI framework there is an icon web component that transforms every size prop value into a string which is not attached to the DOM. I know that the example has more dependencies than React, BUT there is also a simple div (as simple as this ) which is also affected by this issue. What is the expected behavior? The size prop should be to the DOM when it is not a number on HTML tags that aren't inputs and selects. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? The affected versions are = 16.3 It works ok in versions <= 16.2 Browsers: All
The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. What are the HTML tags that have a attribute except inputs and selects? With web components I am not seeing the issue: <img width="227" alt="screen shot 2018-04-26 at 7 51 53 pm" src="https://user-"
the attribute is an HTML attribute, not something that React provides. According to the HTML spec, is only allowed on and elements
I don't know why I wrote "rest of HTML tags", my bad . The example you provided works ok, but if I add something that doesn't seems like a valid size then it doesn't work. For example: Value | Works -------|------- 100 | Yes 10px | No 10e1 | Yes -1 | No Something changed in 16.3.

Version 16.3 <img width="853" alt="captura de pantalla 2018-04-26 a las 21 36 43" src="https://user-"Version 16.2 <img width="855" alt="captura de pantalla 2018-04-26 a las 21 37 10" src="https://user-" I suppose that it's fine to filter props when not passing the appropriate values when using HTML tags but I suppose that in web components the size attribute can be anything. Am I wrong? What do you think?
The web component code path shouldn't reject any attributes. If it does it's a bug.
The bug is . Before the we should add something like Please send a PR :-)
Ok, I will work on this tomorrow. I'm heading to bed. Thanks for your quick response.
Couldn't wait
Should be fixed in React 16.4.
Change:
* real browser event. */ if (typeof window !== 'undefined' && <del> typeof window.dispatchEvent === 'function' && typeof Event === 'function') { </del> <ins> typeof window.dispatchEvent === 'function') { </ins> var fakeNode = document.createElement('react'); ReactErrorUtils.invokeGuardedCallback = function(name, func, a, b) { var boundFunc = func.bind(null, a, b); fakeNode.addEventListener(name, boundFunc, false); <del> fakeNode.dispatchEvent(new Event(name)); </del> <ins> var evt = document.createEvent('Event'); evt.initEvent(name, false, false); fakeNode.dispatchEvent(evt); </ins> fakeNode.removeEventListener(name, boundFunc, false); }; }

Discussion:
I'm still quite new to React, but I guess this is a bug in the React framework introduced in 0.14. Seems like all listeners attached with JSX are broken in native Android browser for Android LTE 4.3, when compiling code with NODEENV development. Everything works fine with NODEENV production compilation. I've tracked it down to being related to ReactErrorUtils, that in development mode do guards on events. The source code: If I simply remove that part of code after compiling the React app, the listeners starts working again. I guess this is not intentional, but instead a bug? To reproduce problem in Android LTE 4.3 (code that works in e.g. Chrome Browser): Using the pre-compiled Getting Started lib
Hm. That's unfortunate. I guess we'll try to find a feature test for this and patch it.
Change:
// TODO: an explicit expect for no warning? ReactDOM.render(JSXRuntime.jsx(Parent, {}), container); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); if (__DEV__) { JSXDEVRuntime.jsxDEV(Lazy, {}); } else { JSXRuntime.jsx(Lazy, {}); } expect(didCall).toBe(false); }); </ins> });

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> /** * Copyright 2013-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'; /*jshint evil:true */ describe('ReactDOMOption', function() { var React; var ReactTestUtils; beforeEach(function() { React = require('React'); ReactTestUtils = require('ReactTestUtils'); }); it('should flatten children to a string', function() { var stub = <option>{1} {'foo'}</option>; stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(node.innerHTML).toBe('1 foo'); }); it('should ignore invalid children types', function() { var stub = <option>{1} <div /> {2}</option>; stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(node.innerHTML).toBe('1  2'); }); it('should warn when passing invalid children', function() { var stub = <option>{1} <div /></option>; spyOn(console, 'error'); stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(console.error.calls.length).toBe(1); expect(console.error.calls[0].args[0]).toContain( 'Only strings and numbers are supported as <option> children.' ); }); it('should ignore null/undefined/false children without warning', function() { var stub = <option>{1} {false}{true}{null}{undefined} {2}</option>; spyOn(console, 'error'); stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(console.error.calls.length).toBe(0); expect(node.innerHTML).toBe('1  2'); }); }); </ins>

Discussion:
If the contents of the element is constructed in special way, it breaks React on component update with "Unable to find element" error. Here's an example of method body: Here's working jsfiddle (with React 0.12.0): Adding to option props fixes the issue.
React separates the 's children with s. In HTML only text is allowed there and the browser handles it gracefully by removing the s. On the next render React tries to change those s, but can't find them. A workaround is to give a string to the :
Thanks for explaining this. In such case probably the best solution would be to extend error explanation with information about "option" elements (behind "table" etc).
Yea, we should probably do some checks in our ReactDOMOption wrapper and not allow anything but text as children.
Just hit this
This can be fixed by using ReactChildren.forEach in ReactDOMOption to flatten the children before passing it to the raw HTML component. Strings and numbers get concatted together; other elements should be skipped and log a warning for invalid children.
Change:
var range = document.selection.createRange().duplicate(); var start, end; <del> if (typeof offsets.end === 'undefined') { </del> <ins> if (offsets.end === undefined) { </ins> start = offsets.start; end = start; } else if (offsets.start > offsets.end) {

Discussion:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.
Change:
<del> /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @emails react-core * @jest-environment node */ 'use strict'; let createRenderer; let React; let ReactFeatureFlags; describe('ReactShallowRenderer', () => { beforeEach(() => { ReactFeatureFlags = require('shared/ReactFeatureFlags'); ReactFeatureFlags.warnAboutDeprecatedLifecycles = true; createRenderer = require('react-test-renderer/shallow').createRenderer; React = require('react'); }); afterEach(() => { jest.resetModules(); }); // TODO (RFC #6) Merge this back into ReactShallowRenderer-test once // the 'warnAboutDeprecatedLifecycles' feature flag has been removed. it('should warn if deprecated lifecycles exist', () => { class ComponentWithWarnings extends React.Component { componentWillReceiveProps() {} componentWillMount() {} componentWillUpdate() {} render() { return null; } } const shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<ComponentWithWarnings />), ).toLowPriorityWarnDev( 'Warning: ComponentWithWarnings: componentWillMount() is deprecated and will ' + 'be removed in the next major version.', ); expect(() => shallowRenderer.render(<ComponentWithWarnings />), ).toLowPriorityWarnDev([ 'Warning: ComponentWithWarnings: componentWillReceiveProps() is deprecated ' + 'and will be removed in the next major version.', 'Warning: ComponentWithWarnings: componentWillUpdate() is deprecated and will ' + 'be removed in the next major version.', ]); // Verify no duplicate warnings shallowRenderer.render(<ComponentWithWarnings />); }); describe('react-lifecycles-compat', () => { const polyfill = require('react-lifecycles-compat'); it('should not warn about deprecated cWM/cWRP for polyfilled components', () => { class PolyfilledComponent extends React.Component { state = {}; static getDerivedStateFromProps() { return null; } render() { return null; } } polyfill(PolyfilledComponent); const shallowRenderer = createRenderer(); shallowRenderer.render(<PolyfilledComponent />); }); }); }); </del>

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:
expect(handler).not.toHaveBeenCalled(); }); <ins> it('should not warn when simulating events with extra properties', function() { spyOn(console, 'error'); var CLIENT_X = 100; var Component = React.createClass({ handleClick: function(e) { expect(e.clientX).toBe(CLIENT_X); }, render: function() { return <div onClick={this.handleClick} />; }, }); var element = document.createElement('div'); var instance = ReactDOM.render(<Component />, element); ReactTestUtils.Simulate.click( ReactDOM.findDOMNode(instance), {clientX: CLIENT_X} ); expect(console.error.calls.length).toBe(0); }); </ins> it('can scry with stateless components involved', function() { var Stateless = () => <div><hr /></div>; var SomeComponent = React.createClass({

Discussion:
To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.
Change:
--light-color-expand-collapse-toggle: #777d88; --light-color-link: #0000ff; --light-color-modal-background: rgba(255, 255, 255, 0.75); <ins> --light-color-primitive-hook-badge-background: #e5e5e5; --light-color-primitive-hook-badge-text: #5f6673; </ins> --light-color-record-active: #fc3a4b; --light-color-record-hover: #3578e5; --light-color-record-inactive: #0088fa;

Discussion:
I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.
Change:
"description": "Basic example of using React with CommonJS", "main": "index.js", "devDependencies": { <del> "envify": "~1.2.1", "react": "~0.10.0", "reactify": "~0.13.1", "browserify": "~3.44.2" </del> <ins> "browserify": "^6.3.3", "envify": "^3.2.0", "react": "^0.12.0", "reactify": "^0.17.1" </ins> }, "scripts": { "build": "browserify --debug --transform reactify index.js > bundle.js"

Discussion:
Hi. In the examples included in the Getting started kit from the version of react defined in in the "basic-commonjs" example is set to 0.10.0. In order for the example to work as expected it should be 0.12.0 Also using Browserify and Reactify to compile fails because of a missing jsx header in I have not tested this in other examples
Change:
* `es3` restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg `this.static` will become `this['static']` for IE8 compatibility). * The transform for the call spread operator has also been enabled. <ins> ### JSXTransformer #### Breaking Changes * The return value of `transform` now contains `sourceMap` as a JS object already, not an instance of `SourceMapGenerator`. </ins> ### JSX #### Breaking Changes

Discussion:
There seems to have been an API change between React 0.12 and 0.13 that's not covered in the documentation. When using with the option, the source map is now returned as a plain JavaScript object. Previously it would return an instance of and you'd need to call to get the actual source map. Is this an intentional change that just got overlooked when writing the documentation?
That's just an oversight. We aligned JSXTransformer to use the same code as react-tools (as opposed to duplicating efforts with slight variation). This originally changed in react-tools last year - , and then I made JSXTransformer just use react-tools in . I didn't notice that we're doing a bit more post-processing in react-tools. We can add a bit to the changelog for this.
Change:
@include code-typography; } <del> div.CodeMirror-linenumber:after { content: '.'; </del> <ins> div.CodeMirror-linenumber { text-align: right; </ins> } .CodeMirror, div.CodeMirror-gutters, div.highlight {

Discussion:
is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !
Change:
onChange={handleFiles} tabIndex={-1} /> <ins> <a ref={downloadRef} className={styles.Input} /> </ins> <Button disabled={isProfiling} onClick={uploadData}

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 :)