jiebi/CodeConvo huggingface dataset:
Change:
ReactPerf.printDOM(measurements); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isRunning state', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('start has no effect when already running', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('stop has no effect when already stopped', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); </ins> });

Discussion:
I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR
Change:
*/ 'use strict'; <del> var Circle = require('react-art/lib/Circle.art'); </del> <ins> var Circle = require('react-art/Circle'); </ins> var React = require('react'); var ReactART = require('react-art'); var Group = ReactART.Group;

Discussion:
It seems like those were intended to be public APIs () but they’re not published on npm because folder is not in the whitelist.
Change:
// promisified version of ReactDOM.render() function asyncReactDOMRender(reactElement, domElement) { <del> return new Promise(resolve => ReactDOM.render(reactElement, domElement, resolve), ); </del> <ins> return new Promise(resolve => { ReactDOM.render(reactElement, domElement); // We can't use the callback for resolution because that will not catch // errors. They're thrown. resolve(); }); </ins> } // performs fn asynchronously and expects count errors logged to console.error. // will fail the test if the count of errors logged is not equal to count.

Discussion:
I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.
Change:
validateDangerousTag(tag); this._tag = tag; this._renderedChildren = null; <ins> this._previousStyle = null; </ins> this._previousStyleCopy = null; this._rootNodeID = null; }

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:
}), ).toThrow('is not a function'); }); <ins> it('warns when setState is called from insertion effect setup', () => { function App(props) { const [, setX] = useState(0); useInsertionEffect(() => { setX(1); if (props.throw) { throw Error('No'); } }, [props.throw]); return null; } const root = ReactNoop.createRoot(); expect(() => act(() => { root.render(<App />); }), ).toErrorDev(['Warning: useInsertionEffect must not schedule updates.']); expect(() => { act(() => { root.render(<App throw={true} />); }); }).toThrow('No'); // Should not warn for regular effects after throw. function NotInsertion() { const [, setX] = useState(0); useEffect(() => { setX(1); }, []); return null; } act(() => { root.render(<NotInsertion />); }); }); it('warns when setState is called from insertion effect cleanup', () => { function App(props) { const [, setX] = useState(0); useInsertionEffect(() => { if (props.throw) { throw Error('No'); } return () => { setX(1); }; }, [props.throw, props.foo]); return null; } const root = ReactNoop.createRoot(); act(() => { root.render(<App foo="hello" />); }); expect(() => { act(() => { root.render(<App foo="goodbye" />); }); }).toErrorDev(['Warning: useInsertionEffect must not schedule updates.']); expect(() => { act(() => { root.render(<App throw={true} />); }); }).toThrow('No'); // Should not warn for regular effects after throw. function NotInsertion() { const [, setX] = useState(0); useEffect(() => { setX(1); }, []); return null; } act(() => { root.render(<NotInsertion />); }); }); </ins> }); describe('useLayoutEffect', () => {

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:
transaction, this._mountDepth + 1 ); <del> child._mountImage = mountImage; </del> child._mountIndex = index; mountImages.push(mountImage); index++;

Discussion:
We're currently not cleaning up strings from _mountImage after a component gets mounted. That memory could be freed. But the act of freeing the memory could be more expensive than it's worth. Needs proper benchmarks and a workaround.
I noticed this a little while ago. I'm not sure why we need to store it on the child instance in the first place -- PR incoming.
Change:
/** * @param {ReactComponent} input Form component <ins> * @return {*} current checked status of the input either from checked prop *             or link. */ getChecked: function(input) { if (input.props.checkedLink) { _assertCheckedLink(input); return input.props.checkedLink.value; } return input.props.checked; }, /** * @param {ReactComponent} input Form component </ins> * @return {function} change callback either from onChange prop or link. */ getOnChange: function(input) { if (input.props.valueLink) { <del> _assertLink(input); </del> <ins> _assertValueLink(input); </ins> return _handleLinkedValueChange; <ins> } else if (input.props.checkedLink) { _assertCheckedLink(input); return _handleLinkedCheckChange; </ins> } return input.props.onChange; }

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:
props = ReactDOMOption.getNativeProps(this, props); break; case 'select': <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> ReactDOMSelect.mountWrapper(this, props, nativeParent); props = ReactDOMSelect.getNativeProps(this, props); break; case 'textarea': <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> ReactDOMTextarea.mountWrapper(this, props, nativeParent); props = ReactDOMTextarea.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:
transition: function(animationType, finishCallback) { var node = React.findDOMNode(this); <ins> if (!node) { if (finishCallback) { finishCallback(); } return; } </ins> var className = this.props.name + '-' + animationType; var activeClassName = className + '-active'; var noEventTimeout = null;

Discussion:
I came across this, when using . When loading a route initially where the route handler is actually inside a and then removing it from the transition group leads to an . The weird thing is that it only happens on initial load of a nested route, not when the same view is being pulled up via the menu. I'm not sure if this is an issue related or if it belongs to . But the thing is that the component either returns a react element, or it returns . It seems like an edge case maybe, because it only happens in this specific initial render setup. It could be fixed, by adding a guard to the method of :
This was probably fixed by .
I don't think this is solved. It's easy to reproduce with React 0.12.2: just have the child return from . It's rather frustrating because some other developer may change the animated component to return when data is not ready, and not realize that this breaks the case when that component is inside the transition group.
Yup ran into this as well. If you pass a component to ReactCSSTransitionGroup that renders null you get this exception. Using React 0.12.1
Can you please reopen?
i've get the same exception, too. Hope this will be fixed soon.
is there anything stopping you people from implementing the suggested fix? :)
I'm encountering a similar issue.
I guess a PR would be welcome?
yeah, there is is!
I'm still seeing this issue. And can verify that it only happens when I return null. React with addons v0.13.3
Yes, the fix is in 0.14.
Ahh.. well that would explain things. How can I get my hands on 0.14?
Sorry – not released yet, but hopefully in the next few weeks. 0.14-beta is on npm (see the React blog).
Change:
var event = SyntheticEvent.getPooled( eventTypes.change, targetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ); event.type = 'change'; EventPropagators.accumulateTwoPhaseDispatches(event);

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:
"url": "https://github.com/facebook/react/issues" }, "homepage": "https://github.com/facebook/react/tree/master/npm-react-dom", <del> "dependencies": { </del> <ins> "peerDependencies": { </ins> "react": "^0.15.0-alpha" } }

Discussion:
My project uses react, react-dom, and react-bootstrap. react-bootstrap requires react to be a peer dependency. react-dom includes react as a child dependency. So I must install react as a top-level dependency in order for react-bootstrap to work. Now I have two copies of react. When I try to use the Modal component in react-bootstrap, I get the error "Uncaught Error: Invariant Violation: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's method, or you have multiple copies of React loaded". I can fix this by deleting the directory nodemodules/react-dom/nodemodules/react. Maybe react-dom should be changed so react is a peer dependency instead of a child dependency.
As far as I understand it; yeah it should be a peer dependency (cc ?). But dependencies are not child dependencies that's simply a result of how NPM2 unfortunately resolves version issues, so peer dependency is preferable, but a regular dependency is not wrong, you just have to be careful to avoid multiple installations.
I don't know what I did to cause react to be installed below react-dom. I had this: nodemodules/react-dom/nodemodules/react and also: node_modules/react. I can't find a way to reproduce that now.
It can happen quite stealthily when updating/etc in NPM2. I ran into the same issue recently. I'll reopen this for now because it really seems to me that it should be a peer dependency.
Any reason why it is a direct dependency in the first place? Was not the intend of npm's peerDependencies to cover this exact problem? (Avoid duplications of modules built around other module, like react and react-dom), just saying that seems there isn't a reason for react-dom to include react as a direct dependency
It probably should be a peerDep. I don't remember why I put it as a regular dep there… (I did addons-* with React as a peerDep).
Change:
line-height: 20px; } a { color: $linkColor; text-decoration: none;

Discussion:
It doesn't match the rest of our text. I think a in the right place in the stylesheet should fix this. !
Pretty sure this is already correct…
It's not. Proxima Nova on the body vs. the default sans system font (San Francisco in the screenshot) in the
The font is indeed different. With font-family inherited: <img width="248" alt="screen shot 2016-09-13 at 00 27 38" src=""Without (current): <img width="244" alt="screen shot 2016-09-13 at 00 27 48" src=""
touché - I had unchecked the browser-styles box in my inspector at some point and so it showed it inheriting the html style… oops. (the Proxima Nova "R" and SF "R" look similar enough that it fooled me too). We could probably just make in as opposed to targeting just this one - we already have that for headers.
Adjusted the PR to include just that
Closed with
Change:
"manifest_version": 2, "name": "React Developer Tools", "description": "Adds React debugging tools to the Firefox Developer Tools.", <del> "version": "4.27.7", </del> <ins> "version": "4.27.8", </ins> "applications": { "gecko": { "id": "@react-devtools",

Discussion:
local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.
Change:
} } <ins> // If we're in IE8, check to see if we are in combatibility mode and provide // information on preventing compatibility mode var ieCompatibilityMode = document.documentMode && document.documentMode < 8; warning( !ieCompatibilityMode, 'Internet Explorer is running in compatibility mode, please add the following ' + 'tag to your HTML to prevent this from happening: ' + '<meta http-equiv="X-UA-Compatible" content="IE=edge" />' ); </ins> var expectedFeatures = [ // shims Array.isArray,

Discussion:
If we claim to support IE8, and users are testing their code locally in IE8, they might get thrown into compatibility mode by default. This will cause their webapp to blow up, and they will be confused because IE8 is a supported browser. For background, check out this thread: Users can get out of compatibility mode by adding this tag: Since the current failure is cryptic, and it's easy to detect when IE8 is in compatibility mode (), we should probably add a warning to give a hint to the user that even though they're using IE8, they're actually in compatibility mode (effectively IE7) and should add the meta tag or use one of the other various workarounds.
Change:
"lint": "node ./scripts/tasks/eslint.js", "lint-build": "node ./scripts/rollup/validate/index.js", "postinstall": "node node_modules/fbjs-scripts/node/check-dev-engines.js package.json", <ins> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source.js --runInBand", </ins> "test": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source.js", "test-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.source.js", "test-prod-build": "yarn test-build-prod",

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? Throw exception, don't run tests. SyntaxError: missing ) after argument list 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: one of the commands: yarn debug-test yarn debug-test-persistent yarn debug-test-build-devtools chrome://inspect and press “Inspect”. What is the expected behavior? Possibility debug tests. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.2.0 and higher. Chrome 77.0.3865.120 Windows 10. Older version React hasn't this feature.
fixed in
Change:
'updateTextContentByID', function(id, content) { var node = ReactMount.getNode(id); <del> node[textContentAccessor] = content; </del> <ins> DOMChildrenOperations.updateTextContent(node, content); </ins> } ),

Discussion:
On re-render, we innerText. This causes inconsistencies in rendering whitespace. See demo: We should make sure this doesn't happen.
We switched to use but it broke some contentEditable stuff internal to FB. knows more.
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer
looks like this was brought up in
Right, we should also do the right thing in IE8.
jQuery empties then adds a text node. Relevant commits: ()
okay interesting. I'll do this for ie8
I have a patch almost ready.
I'm curious if is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML.
hmm interesting. We definitely want to preserve whitespace though. (because of and and )
Change:
var ExecutionEnvironment = require('ExecutionEnvironment'); <ins> /** * EVENT_NAME_MAP is used to determine which event fired when a * transition/animation ends, based on the style property used to * define that event. */ </ins> var EVENT_NAME_MAP = { transitionend: { 'transition': 'transitionend',

Discussion:
ReactCSSTransitionGroup doesn't work properly on (at least) Android 4.2. I've narrowed it down to the code in which is finding and properties on the test element's object and so only registering and handlers, despite the fact that Android fires events. So the end of the transition isn't properly detected. I will do some more investigation and see if there's a safer way to do this detection on Android (I seem to recall seeing something similar before).
See this patch for the Dojo toolkit: - basically on some Android versions is not . Could this be fixed by changing the order the properties are checked, so that is checked for before ?
This is still an issue on Android 4.3 (or at least on Samsung Galaxy S3 with Android 4.3). However changing the webkitTransition and transition order as suggested by it fixes the issue.
Is TransitionEvent defined or undefined on that browser? When the unprefixed version exists it's better to use that in general because it's more forwards-compatible.
Change:
'es6-destructuring', 'es7-spread-property' ], <ins> 'es3': [ 'reserved-words' ], </ins> 'react': [ 'react' ]

Discussion:
When I run: The following error is thrown: I'm trying to use a library called in an isomorphic app, which needs server-side rendering. The module works fine client-side, but the JSX/ES6 isn't playing nice on the server even though the server's already set up to render React components and other JSX code. As stated , it seems there's a transformation supported in (via its flag) which isn't supported in . I say "seems" because I have a hard time believing can't do the same thing. What am I missing?