jiebi/CodeConvo huggingface dataset:
Change:
'use strict'; var ReactBrowserComponentMixin = require('ReactBrowserComponentMixin'); <ins> var ReactChildren = require('ReactChildren'); </ins> var ReactClass = require('ReactClass'); var ReactDOMSelect = require('ReactDOMSelect'); var ReactElement = require('ReactElement');

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:
internalInstance._currentElement ); } <del> transaction.getReactMountReady().enqueue(attachRefs, internalInstance); </del> <ins> if (internalInstance._currentElement.ref != null) { transaction.getReactMountReady().enqueue(attachRefs, internalInstance); } </ins> return markup; },

Discussion:
We currently use the transaction queue too much and build up a giant array on mount. Here's one simple example of where we add things to the queue unnecessarily:
I don't know of anything else easy here.
Change:
.HookName { color: var(--color-component-name); <ins> } .ToggleError { color: var(--color-error-text); </ins> }  No newline at end of file

Discussion:
The named hooks cache returns The first (mixed array of string and null) indicates an overall success, even if some names couldn't be inferred. The second indicates an error (e.g. couldn't locate or load source map). In the event of the 2nd response type, the UI currently does nothing (falls back to default) but we should show an error badge (maybe a disabled but red icon with a tooltip saying there was an error) since it's a confusing user experience to just do nothing.
Change:
var value = LinkedValueUtils.getValue(props); if (value != null) { <del> updateOptions(this, props, value); </del> <ins> updateOptions(this, Boolean(props.multiple), value); </ins> } } }

Discussion:
Case: ,js,output I have a with a value depending on the state. When I select the 'baz' item in the combobox, and don't do anything in the onChange handler, the combobox suddenly displays the first element (even though the state is still the same). So, the state of the combobox is inconsistent with the state of its 'value' property. This seems to happen in at least Chrome and Safari.
Change:
grunt.registerTask('coverage:parse', require('./grunt/tasks/coverage-parse')); <del> grunt.registerTask('test:eslint-rules', require('./grunt/tasks/test-eslint-rules')); </del> grunt.registerTask('test:webdriver:phantomjs', [ 'connect', 'webdriver-phantomjs',

Discussion:
using npm mocha is not necessarily at (thanks to hoisting). (eg it's actually at for me)
We've found out that it's possible to use eslint-tester with jest, so we should just do that.
Change:
<del> /** * 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. * * @providesModule ReactRAFBatchingStrategy * @typechecks static-only */ /* global requestAnimationFrame:true */ 'use strict'; var ExecutionEnvironment = require('ExecutionEnvironment'); var ReactUpdates = require('ReactUpdates'); var requestAnimationFrame = require('requestAnimationFrame'); function tick() { ReactUpdates.flushBatchedUpdates(); requestAnimationFrame(tick); } var ReactRAFBatchingStrategy = { isBatchingUpdates: true, /** * Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ batchedUpdates: function(callback, a, b, c, d) { callback(a, b, c, d); } }; if (ExecutionEnvironment.canUseDOM) { requestAnimationFrame(tick); } module.exports = ReactRAFBatchingStrategy; </del>

Discussion:
I didn't realise this was in the addons bundle, would be good to get it to the docs. Would be good to also include an example of using or something similar.
rAF batching isn't supported and won't go in the docs, but batchedUpdates should.
is rAF batching discouraged, or just not suitable for shipping with core? Would it be reasonable to link to an up-to-date npm project on the batchedUpdates page?
We don't use it at Facebook and it's not clear that it solves real problems, so we don't want to maintain it or have to fix bugs related to it. should give enough control over batching.
There are also known issues with rAF batching (mostly around controlled components).
Should we deprecate and eventually remove the RAF batching?
It's never been supported in any fashion.
(i.e., it's already deprecated?)
shouldn't this file be deleted in that case?
That's not exposed as a public API in any of our builds, but sure, we can delete it – PR incoming.
Killed in
We should document ReactDOM.unstable_batchedUpdates.
Since when did we start documenting features? Haven't we always left them intentionally undocumented? We also have unstablerenderSubtree and unstable_handleError and others, but I thought the decision was to not document them until they become stable. We document them as part of the release process. It was a different situation when it was an addon, the issue made sense at that time.
Sure.
Change:
expect(data.commitData).toHaveLength(1); expect(data.operations).toHaveLength(1); }); <ins> it('should not throw while initializing context values for Fibers within a not-yet-mounted subtree', () => { const promise = new Promise(resolve => {}); const SuspendingView = () => { throw promise; }; const App = () => { return ( <React.Suspense fallback="Fallback"> <SuspendingView /> </React.Suspense> ); }; const container = document.createElement('div'); utils.act(() => legacyRender(<App />, container)); utils.act(() => store.profilerStore.startProfiling()); }); </ins> });

Discussion:
not public I have two code bases in a yarn workspaces linked monorepo. One is using react-three-fiber (the lib), and the other one is really thin wrapper around it with some simple UI, just couple of buttons. Both are using multiple (3) zustand stores. Every time react-devtools-extensions 21.0- Could not find ID for Fiber "App"
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example:
I have experienced the same issue in Firefox, also with the use of react-three-fiber and zustand. If it helps isolate the issue, I only experience it for development builds but do not experience it for production builds. Repository: Browser: Firefox 95.0.2 (64-bit), Windows 10 Sample video: https://user- The error message in the pane:
Thanks for the repro,
I, too, have had this issue and spent a bit of time reducing the surface area to a really small combo of react + canvas. Hopefully, this breaks in a way that is helpful. DevTools version Error message Error call stack Error component stack GitHub query string !
Possibly fixed by . Possible requires an additional change made to this method to replace with (and we can just skip Fibers with a null ID).
Repro from by repo repo in your browser of choice. to the dev tools, and you should see the error
Fix released on Jan 24 as version 4.23.0: Give it a couple of days to propagate to all of the browsers. (Chrome usually takes the longest.)
Change:
), ]; break; <ins> case 'input': case 'select': case 'textarea': inst._wrapperState.listeners = [ ReactBrowserEventEmitter.trapBubbledEvent( EventConstants.topLevelTypes.topInvalid, 'invalid', node ), ]; break; </ins> } }

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:
"README.md", "main.js", "bin/jsx", <del> "build/React.js", </del> <ins> "build/react.js", </ins> "vendor/fbtransform/", "vendor/woodchipper.js" ],

Discussion:
I'm trying to programatically invoke the JSX transformer (using the version of in the npm registry) by running something like Which then throws this error: If I comment out the lines in that require/use the module loads fine and the transformer runs correctly.
Bah, I changed build filenames last minute and didn't properly test the module after :( Thanks for finding this! I guess we should write some tests for the node module too, not just our phantomjs tests. (Very) Short term, you should be able to change to and that will fix the problem. - I guess it's time to figure out what we want to do with npm versions vs library versions. Should we just bump them both for the time being?
Nope, that alone won't do it, we're not even packaging. I totally screwed up the node module :( Fix soon!
Yeah, doesn't look like there's even a directory there. :)
Change:
]); }); <ins> it('should chain functions regardless of spec property order', function() { var listener = mocks.getMockFunction(); var instance = <TestComponentWithReverseSpec listener={listener} />; instance = ReactTestUtils.renderIntoDocument(instance); expect(listener.mock.calls).toEqual([ ['MixinA didMount'], ['MixinBWithReverseSpec didMount'], ['MixinC didMount'], ['Component didMount'] ]); }); </ins> it('should validate prop types via mixins', function() { expect(TestComponent.type.propTypes).toBeDefined(); expect(TestComponent.type.propTypes.value)

Discussion:
Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.
Change:
// register renderers that have already injected themselves. hook.renderers.forEach(renderer => { <del> registerRenderer(renderer); </del> <ins> registerRenderer(renderer, hook); </ins> }); // Activate and remove from required all present backends, registered within the hook

Discussion:
the codepen linked above. sure to open the Debug View, so codepen doesn't add any additional iframes (). : Warning in the Console tab: . Error in the Components tab: . After dismissing the error, all components seem to be accounted for (you might need to adjust the "Hide components where..." option). In my actual application the error pops up for every change in the tree, making the devtools virtually unusable. Note: This only seems to happen if the iframe is some time after the initial React tree was mounted in the parent window. When I remove the so the iframe is synchronously, I no longer see any warnings. Related issues: Every time No response 27.7 (5/7/2023) in Google Chrome Version 112.0.5615.165 (Official Build) (64-bit) Cannot add node "3" because a node with that id is already in the Store. No response No response
Hey thanks for reporting this. Can confirm this issue, but I am getting different error on my side and only when refreshing the page. Extension works as expected for me when I open the page for the first time. I will put up a fix for this.
can you please also validate this on your side? You can download a build from our CircleCI pipeline here - Chrome extension should be in archive, you can then install it via dialog in
Yes! I'm no longer seeing the warning/errors when I use the build you linked. Thanks for the fix :)
Great, thanks for helping resolving this. This will be included in v4.27.8 release, which I will publish this week.
Change:
// Compute `paths` and cache it. Guarding against cycles. cache.set(segment.id, null); <del> if (segment.prevSegments.length === 0) { </del> <ins> if (codePath.thrownSegments.includes(segment)) { paths = 0; } else if (segment.prevSegments.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:
if (!backend) { throw new Error(`Could not find backend for version "${version}"`); } const {Agent, Bridge, initBackend, setupNativeStyleEditor} = backend; const bridge = new Bridge({ listen(fn) {

Discussion:
the codepen linked above. sure to open the Debug View, so codepen doesn't add any additional iframes (). : Warning in the Console tab: . Error in the Components tab: . After dismissing the error, all components seem to be accounted for (you might need to adjust the "Hide components where..." option). In my actual application the error pops up for every change in the tree, making the devtools virtually unusable. Note: This only seems to happen if the iframe is some time after the initial React tree was mounted in the parent window. When I remove the so the iframe is synchronously, I no longer see any warnings. Related issues: Every time No response 27.7 (5/7/2023) in Google Chrome Version 112.0.5615.165 (Official Build) (64-bit) Cannot add node "3" because a node with that id is already in the Store. No response No response
Hey thanks for reporting this. Can confirm this issue, but I am getting different error on my side and only when refreshing the page. Extension works as expected for me when I open the page for the first time. I will put up a fix for this.
can you please also validate this on your side? You can download a build from our CircleCI pipeline here - Chrome extension should be in archive, you can then install it via dialog in
Yes! I'm no longer seeing the warning/errors when I use the build you linked. Thanks for the fix :)
Great, thanks for helping resolving this. This will be included in v4.27.8 release, which I will publish this week.
Change:
var DOMProperty = require('DOMProperty'); var DOMPropertyOperations = require('DOMPropertyOperations'); var ReactBrowserEventEmitter = require('ReactBrowserEventEmitter'); <ins> var ReactComponentBrowserEnvironment = require('ReactComponentBrowserEnvironment'); </ins> var ReactMount = require('ReactMount'); var ReactMultiChild = require('ReactMultiChild'); var ReactPerf = require('ReactPerf');

Discussion:
Logging and reveals: Which doesn't make sense (to me at least).
Can you log the too and something to distinguish the two renderComponent calls?
Updated, that makes more sense,
Change:
```javascript{3-5} render: function() { return ( <del> <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}> </ins> <h1>Dissolvenza al Montaggio Iniziale</h1> </ReactCSSTransitionGroup> );

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:
// Flush the immediate callbacks that were scheduled during this batch. // Note that this will happen even if batchedUpdates is higher up // the stack. <del> flushSyncCallbackQueue(); </del> <ins> if ((executionContext & (RenderContext | CommitContext)) === NoContext) { flushSyncCallbackQueue(); } else { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } } </ins> } }

Discussion:
flushSync early returns if it detects it's in the commit (or render) phase, since it can't synchronously flush when React is already working. However, it should still change the priority of updates scheduled by the callback to be synchronous. This mostly already works because the commit phase itself has a sync event priority context, but the passive effect phase doesn't. Need more tests for this.
Change:
downloadUrl = URL.createObjectURL(blob); <del> const element = document.createElement('a'); </del> element.setAttribute('href', downloadUrl); element.setAttribute('download', filename); <del> element.style.display = 'none'; ((document.body: any): HTMLBodyElement).appendChild(element); </del> element.click(); <del> ((document.body: any): HTMLBodyElement).removeChild(element); </del> } export function truncateText(text: string, maxLength: number): string {

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 :)
Change:
}, /** <ins> * Setup this component to trap non-bubbling events locally * * @private * @param {ReactReconcileTransaction|ReactServerRenderingTransaction} transaction */ _setupTrapBubbledEventsLocal: function(transaction) { this._wrapperState = { listeners: null, }; transaction.getReactMountReady().enqueue(trapBubbledEventsLocal, this); }, /** </ins> * Creates markup for the open tag and all attributes. * * This method has side effects because events get registered.

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:
}); it('should keep both sets of DOM nodes around', function() { <del> var container = document.createElement('div'); </del> var a = React.renderComponent( <ReactTransitionGroup transitionName="yolo"> <span key="one" id="one" />

Discussion:
Consider this example: If is false or undefined, will be and will throw
Want to take a go at fixing this? I think it would be a good opportunity to learn a bit more about a constrained subset of internals.
yea - i'll give it a shot :)