jiebi/CodeConvo huggingface dataset:
Change:
expect(stubStyle.lineHeight).toBe(''); }); <ins> it('should warn when mutating style', function() { spyOn(console, 'error'); var style = {border: '1px solid black'}; var App = React.createClass({ getInitialState: function() { return {style: style}; }, render: function() { return <div style={this.state.style}>asd</div>; } }); var stub = ReactTestUtils.renderIntoDocument(<App />); style.position = 'absolute'; stub.setState({style: style}); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toEqual( 'Warning: `div` was passed a style object that has previously been ' + 'mutated. Mutating `style` will be deprecated. Consider cloning it ' + 'beforehand. Check the `render` of `App`. Previous style: ' + '{"border":"1px solid black"}. Mutated style: ' + '{"border":"1px solid black","position":"absolute"}.' ); style = {background: 'red'}; stub = ReactTestUtils.renderIntoDocument(<App />); style.background = 'green'; stub.setState({style: {background: 'green'}}); // already warned once for the same component and owner expect(console.error.argsForCall.length).toBe(1); style = {background: 'red'}; var div = document.createElement('div'); React.render(<span style={style}></span>, div); style.background = 'blue'; React.render(<span style={style}></span>, div); expect(console.error.argsForCall.length).toBe(2); }); </ins> it("should update styles if initially null", function() { var styles = null; var container = document.createElement('div');

Discussion:
Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.
Change:
<del> /** * Copyright 2013-present, 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'; describe('ReactDOMButton', function() { var React; var ReactDOM; var ReactTestUtils; var onClick = jest.genMockFn(); function expectClickThru(button) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(button)); expect(onClick.mock.calls.length).toBe(1); } function expectNoClickThru(button) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(button)); expect(onClick.mock.calls.length).toBe(0); } function mounted(button) { button = ReactTestUtils.renderIntoDocument(button); return button; } beforeEach(function() { React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('should forward clicks when it starts out not disabled', function() { expectClickThru(mounted(<button onClick={onClick} />)); }); it('should not forward clicks when it starts out disabled', function() { expectNoClickThru( mounted(<button disabled={true} onClick={onClick} />) ); }); it('should forward clicks when it becomes not disabled', function() { var container = document.createElement('div'); var btn = ReactDOM.render( <button disabled={true} onClick={onClick} />, container ); btn = ReactDOM.render( <button onClick={onClick} />, container ); expectClickThru(btn); }); it('should not forward clicks when it becomes disabled', function() { var container = document.createElement('div'); var btn = ReactDOM.render( <button onClick={onClick} />, container ); btn = ReactDOM.render( <button disabled={true} onClick={onClick} />, container ); expectNoClickThru(btn); }); it('should work correctly if the listener is changed', function() { var container = document.createElement('div'); var btn = ReactDOM.render( <button disabled={true} onClick={function() {}} />, container ); btn = ReactDOM.render( <button disabled={false} onClick={onClick} />, container ); expectClickThru(btn); }); }); </del>

Discussion:
The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.
Change:
} if (typeof instance.getSnapshotBeforeUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Snapshot;

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? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
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!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is
Change:
}); }); <del> // Only call profile updates for paths that have re-rendered // Since "inner" is beneath a pure component, it isn't called expect(callback).toHaveBeenCalledTimes(2); expect(callback.mock.calls[0][0]).toBe('middle'); expect(callback.mock.calls[1][0]).toBe('outer'); </del> <ins> // Only call onRender for paths that have re-rendered. // Since the Updater's props didn't change, // React does not re-render its children. expect(callback).toHaveBeenCalledTimes(1); expect(callback.mock.calls[0][0]).toBe('outer'); </ins> }); it('decreases actual time but not base time when sCU prevents an update', () => {

Discussion:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks
Change:
render: function() { return ( <div> <del> <ReactCSSTransitionGroup transitionName="carousel" transitionEnterTimeout={300} transitionLeaveTimeout={300}> </del> <ins> <ReactCSSTransitionGroup transitionName="carousel" transitionEnterTimeout={300} transitionLeaveTimeout={300}> </ins> <img src={this.props.imageSrc} key={this.props.imageSrc} /> </ReactCSSTransitionGroup> </div>

Discussion:
When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..
Change:
expect(result.props.className).toEqual('clicked'); }); <ins> it('can setState in componentWillMount when shallow rendering', function() { var SimpleComponent = React.createClass({ componentWillMount() { this.setState({groovy: 'doovy'}); }, render() { return <div>{this.state.groovy}</div>; }, }); var shallowRenderer = ReactTestUtils.createRenderer(); var result = shallowRenderer.render(<SimpleComponent />); expect(result).toEqual(<div>doovy</div>); }); </ins> it('can pass context when shallowly rendering', function() { var SimpleComponent = React.createClass({ contextTypes: {

Discussion:
Calling on in a component being Shallow Rendered will result in the error being thrown. I set up a test case:
Who would be best to answer this one?
Seems like a valid bug report — thanks and the test case is rad. I may not be able to look at this for a while, unfortunately.
no worries let me know if you need any more info from me. This was on React 14 beta btw (not sure if that matters)
I have the same issue. A simpler example that throws the error:
Any way of getting around this issue? I am currently running into it.
Sorry about the slow response from us (FB) here. I'm the principal author of the shallow render feature, but React core isn't my main gig and I've been swamped with product work. I don't have an offhand answer for you, but I've just put time on my calendar to look into this next week. Jim, Ben, Paul — if by chance one of you happened to take care of this before then, I wouldn't be mad :)
An update on my end. I think that my problem actually went away when I deduped my npm dependencies to remove an extra react version that was causing issues. If this error pops up again I'll let you know. Thanks for the response! On Fri, Aug 28, 2015, 9:38 PM Scott Feeney wrote:
Hmm I am still able to reproduce this issue in my test case after running npm dedupe
Just to clarify, my previous comment wasn't supposed to mean that the issue has gone away. I think I was seeing a separate issue caused by multiple react versions that I misidentified as this issue (I hope that makes sense).
I am getting this error, too. I'm using react v0.14.0-rc1. Looking at the code : Apparently .
Note that shallow rendered components override to return a instead of whatever it normally returns. That still shouldn't be undefined and should have a attribute, though.
I'm experiencing this issue too - your suggestion gets me past the initial error & on to in
Pretty sure this breaks many other things outside of , but I noticed moving to be directly above in fixed this for me.
We are also affected by this issue.

I think shallow rendering is a really cool feature for testing, but unfortunately I can't use it for some of our components due to this bug.
I created pull request with a fix that works for me. Can someone else verify?
Any workaround for this issue?
:+1: Having same issue
Just ran into this too :/
Any update on this? I see that 0.14.3 was released, but these kind of tests are still failing.
I think I have to add a test to my pull request before it can be merged, but I did not get around to do it yet.
Closing in favor of which should merge soon.
Change:
{ "name": "react-devtools-inline", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "description": "Embed react-devtools within a website", "license": "MIT", "main": "./dist/backend.js",

Discussion:
development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0
Change:
} } } <ins> export function setIsRunningInsertionEffect(isRunning: boolean): void { if (__DEV__) { isRunningInsertionEffect = isRunning; } } </ins>

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:
}, }} className="gatsby-highlight"> <del> <LiveEditor onChange={this._onChange} /> </del> <ins> <LiveEditor onChange={this._onChange} ignoreTabKey={true} /> </ins> </div> </div> {error &&

Discussion:
The current default behavior is that keyboard users will get to the code sections of the live editor and get stuck. Can someone configure ignoreTabKey which makes the editor ignore tab key presses so that keyboard users can tab past the editor without getting stuck? Chrome on Windows atm and cannot edit it to submit a fix. Sorry about that :(
Thanks for bringing this to our attention
Change:
expect(getDisplayName(FauxComponent, 'Fallback')).toEqual('Fallback'); }); }); describe('getDisplayNameForReactElement', () => { it('should return correct display name for an element with function type', () => { function FauxComponent() {}

Discussion:
This function will throw this error if one of the arguments is type of . The error is swallowed but it does interfere with debugging. When I run with the "pause on caught exceptions" I get trapped here all the time. Can we change into ??? Every time No response 13.2- TypeError: Cannot convert a Symbol value to a string No response No response No response
Change:
<ins> /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @flow */ const {useEffect} = require('react'); function useCustom() { useEffect(() => { // ... }, []); } module.exports = {useCustom}; </ins>  No newline at end of file

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> import Fixture from '../../Fixture'; import FixtureSet from '../../FixtureSet'; import TestCase from '../../TestCase'; const React = window.React; class ProgressFixture extends React.Component { state = {value: 0, max: 1, enabled: false, backwards: false}; startTest = () => { this.setState({enabled: true}, () => { this.progressIntervalId = setInterval(() => { if (this.state.backwards) { if (this.state.value > 0) { this.setState({value: this.state.value - this.state.max / 100}); } else { if (this.state.max === 10000) { this.resetTest(); } else { this.setState({max: this.state.max * 100, backwards: false}); } } } else { if (this.state.value < this.state.max) { this.setState({value: this.state.value + this.state.max / 100}); } else { this.setState({backwards: true}); } } }, 10); }); }; resetTest = () => { clearInterval(this.progressIntervalId); this.setState({value: 0, max: 1, enabled: false, backwards: false}); }; render() { return ( <FixtureSet title="Progress"> <TestCase title="Fill and reset progress bar"> <TestCase.Steps> <li>Press enable button</li> </TestCase.Steps> <TestCase.ExpectedResult> When enabled, bar value should increase from 0% to 100% and backwards during three step loop: 0-1, 0-100, 0-10000. Reset button stops loop, sets value to 0 and max to 1. </TestCase.ExpectedResult> <Fixture> <div className="control-box"> <fieldset> <legend>Controlled</legend> <progress value={this.state.value} max={this.state.max}></progress> <button onClick={ this.state.enabled ? this.resetTest : this.startTest }> {this.state.enabled ? 'Reset' : 'Enable'} </button> <br /> <span className="hint"> {' '} max: {JSON.stringify(this.state.max)} </span> <span className="hint"> {' '} value:{' '} {JSON.stringify( Math.round((this.state.value + Number.EPSILON) * 100) / 100 )} </span> </fieldset> </div> </Fixture> </TestCase> </FixtureSet> ); } } export default ProgressFixture; </ins>

Discussion:
Maybe I missed it but I don't see this case in DOM fixtures: Seems important because it's easy to accidentally gloss over it if we stop syncing attributes and have to edit a bunch of jsdom tests.
Hello I would be interested in working on this. Thanks
Maybe it will really cool feature
Change:
"applications": { "gecko": { "id": "@react-devtools", <del> "strict_min_version": "54.0" </del> <ins> "strict_min_version": "55.0" </ins> } },

Discussion:
We currently build DevTools to target Chrome 49 and Firefox 54. These are super old browser versions and they did not have full ES6 support, so the generated build is more bloated than it needs to be. DevTools uses most modern language features. Off the top of my head, the following features are used (basically everything but async and generator functions): The above min browser versions come from Assuming I'm not forgetting things, it looks like we'd need to target Chrome 60+ (released 2017-07-25) and Firefox 55+ (released 2017-04-18). This seems like a reasonable set of browsers to target. Interestingly enough, according to , but I think certain details (like spread in object literals) weren't included in the original spec and/or weren't until later. Note that we can't remove the IE 11 target from the backend yet due to Hermes (React Native) ES6 support but that should be doable by the end of the year given current engineering targets. But we could update the frontend target, as well as the targets for the extensions and the package. It would be good to increase the browser versions we target to at least the version numbers mentioned above, rebuild the DevTools, and compare bundle sizes and generated code.
Change:
"node": ">=0.10.0" }, "dependencies": { <ins> "create-react-class": "^15.5.2", </ins> "fbjs": "^0.8.9", "loose-envify": "^1.1.0", "object-assign": "^4.1.0",

Discussion:
Looks like something about the 'create-react-class' removal was not correctly cherry-picked into 15.6. Steps to reproduce: a new CRA project the version of React in to You'll get this error:
Change:
var event = SyntheticInputEvent.getPooled( eventTypes.beforeInput, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ); event.data = chars;

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:
function makeSimulator(eventType) { return function(domComponentOrNode, eventData) { var node; <ins> invariant( !React.isValidElement(domComponentOrNode), 'TestUtils.Simulate expects a component instance and not a ReactElement.' + 'TestUtils.Simulate will not work if you are using shallow rendering.' ); </ins> if (ReactTestUtils.isDOMComponent(domComponentOrNode)) { node = findDOMNode(domComponentOrNode); } else if (domComponentOrNode.tagName) {

Discussion:
I'm doing a simple shallow render on a component which has a button () with an handler. I can correctly assert most of its properties, but I can't get asserting whether the button has been clicked (by using and a passed in as handler) to work. TestUtils doesn't throw any Invariant Violation or whatever other error, the spy just never gets called. When I manually call it through it works. Is this expected behavior?
I'm not up to date with what the interaction is supposed to be with the shallow renderer these days so cc … But when you use the shallow renderer you aren't working on a real rendered tree. especially doesn't look like it should work - remember that props are not rendered output. will be a React Element, not a component instance. So as your test case seems to be written, yes this is expected.
That's expected. We should probably give a better error message – changing this issue title to reflect that.
Is there anything I can do to help with this? I haven't contributed to React yet, but we're investing heavily into in-company knowledge. If you can point me to where to assert this, I'd love to help.
Also, where do I submit PR's for React's website? I could clarify this in the documentation...
The docs/ directory has markdown files that turn into the website. Each page should also have an "Edit on GitHub" button at the top that links you straight to it. In the file, you could add an invariant that makes sure React.isValidElement returns false on the passed-in node.
Change:
* ${license} */ <del> ${source}`; </del> <ins> (function(){${source}})();`; </ins> }, /***************** UMD_PROFILING *****************/

Discussion:
React version: 16.13.1 Even though React's code (and other packages like ReactDOM) are wrapped in a IIFE, the code applies an entire script strict mode by placing a 'use strict' before any other statement: MDN mentions the "trap" of concatenating conflicting scripts strict mode when using the entire script strict mode, see . a file with React's code at the top and concat an expression that causes a 'use strict' violation this file as a script tag Link to code example: (Scroll to bottom of file to see the concatenated expressions) 'use strict' mode is enforced on all the concatenated code, even if it was not defined as 'strict'. As a result, 'strict' violations at the other concatenated libraries will now throw errors (instead of silencing them), causing the script to stop execution. Global 'use strict' should not be used and should be replaced with function scope strict mode (which already exist in some cases of React IIFE bundles code wrappers, like ). - Always wrap UMD bundles in IIFEs - options for the build script stating - explained (vs )
Thanks for the super quick handling!