jiebi/CodeConvo huggingface dataset:
Change:
user-select: none; color: var(--color-text); <ins> /* Hide radio buttons for Firefox too */ position:  relative; </ins> /* Electron drag area */ -webkit-app-region: no-drag; }

Discussion:
Website is actually irrelevant, but required. the devtools the settings button. the layout being broken (causing horizontal scrollbar). Screenshot ! Every time No response No response No response No response No response No response
Can you provide some more information? Browser (and version), operating system (and version), DevTools extension version, etc. I can't reproduce this.
Firefox 89, Windows 10, latest extension. It's really not that far-fetched.
I'm not sure why there's hostility in your responses (both to this issue and ). This is a free software product and I'm trying to help you. Providing basic info like browser and operating system version along with a bug report is generally useful, regardless of how far fetched you think the configuration is :smile:
Not sure if this is confirmed by anyone else, but I can reproduce this on Firefox. I'll paste my device information so you can try that out in order to repro. How it looks: ! Machine: Windows 10 Home Browser: Firefox version 89.0.1 (64-bit) Let me know if you need more details, I'll be more than happy to take this up. Update: It also happens on chrome dev tools when you resize your dev tools to some specific width.
If I enable scroll bars on OS X, I can also reproduce this in Firefox. Should be able to fix it then. (Did not have access to a Windows machine to test with.) Edit 1: It looks like this is caused by the tab bar containing too many tabs now (General, Debugging, Components, Profiler, and "x" button). Should be an easy fix. Edit 2: I think the reason for the difference between Firefox and Chrome is that the (supposedly hidden) buttons used for the Tab bar accessibility isn't 0 width for Firefox.
Sorry mate, but I don't understand the question then. You asked for browser & OS, and I gave that exact answer. That's really, honestly, genuinely, everything needed to a repro. I've seen this on every pc running Windows 10 + Firefox so far, which is why it's not that far-fetched. I don't see how that's hostile. And actually, we're trying help each other, aren't we Also how am I responding hostile in ? I'm suggesting a fix. I'm Dutch, so I'm just being direct, not hostile at all. It's my culture, please respect that
Change:
} /** <ins> * @param {SyntheticEvent} e change event to handle */ function _handleLinkedCheckChange(e) { /*jshint validthis:true */ this.props.checkedLink.requestChange(e.target.checked); } /** </ins> * Provide a linked `value` attribute for controlled forms. You should not use * this outside of the ReactDOM controlled form components. */

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:
"rootDir": "", "scriptPreprocessor": "jest/preprocessor.js", "setupEnvScriptFile": "jest/environment.js", <del> "modulePathIgnorePatterns": ["/build/", "/node_modules/", "/.module-cache/"], "testPathIgnorePatterns": ["/build/", "/node_modules/"], "unmockedModulePathPatterns": [""] </del> <ins> "modulePathIgnorePatterns": [ "/build/", "/node_modules/", "/.module-cache/" ], "testPathIgnorePatterns": [ "/build/", "/node_modules/" ], "unmockedModulePathPatterns": [ "" ] </ins> } }

Discussion:
Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed.

Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond
Change:
): null | Fiber { if (current === null) { let type = Component.type; <del> if (isSimpleFunctionComponent(type) && Component.compare === null) { </del> <ins> if ( isSimpleFunctionComponent(type) && Component.compare === null && // SimpleMemoComponent codepath doesn't resolve outer props either. Component.defaultProps === undefined ) { </ins> // If this is a plain function component without default props, // and with only the default shallow comparison, we upgrade it // to a SimpleMemoComponent to allow fast path updates.

Discussion:
With this: If I render again after it resolves, it won't get the default prop value. This is a bug.
Change:
); ``` <del> A nice feature of mixins is that if a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. </del> <ins> A nice feature of mixins is that if a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. Methods defined on mixins run in the order mixins were listed, followed by a method call on the component. </ins>

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:
} var visitorList = visitors.getVisitorsBySet(visitorSets); <ins> if (options.sourceFilename) { options.filename = options.sourceFilename; } </ins> return transform(visitorList, input, options); }

Discussion:
Hey guys, I know there are a lot of issues here so I'll try to make this quick and clear. The issue is that when you generate a sourcemap using the node module by calling , it will always output in the property of the sourcemap that is generated, there is no way to specify the actual source file. I thought that perhaps the option would allow you to change this, but unfortunately it does not -- no matter what you set to, the property always returns as an array with in it only. A small snippet of code to quickly verify this:
Thanks guys for the quick fix! :beers:
Change:
Notice the use of `bind(this, arg1, arg2, ...)`: we're simply passing more arguments to `handleClick`. This is not a new React concept; it's just JavaScript. <del> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. </del> <ins> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. [Flux](https://facebook.github.io/flux/) pattern is one of the possible ways to arrange this. </ins>

Discussion:
'For communication between two components that don't have a parent-child relationship, you can set up your own global event system.' So far I've really enjoyed React. It's conducive to modularize your components. However, as you modularize your components, it gets harder to communicate. A global event system doesn't scale and essentially couples components that shouldn't be coupled. A simple example, a faceted navigation sidebar containing two subviews. Some filters and a search bar, and a list of things: SibebarView | -- Filters -- Search Input -- Filter Button | -- List View In essence, an event stream from your search input should update the list. By the advice above, it seems like you'd say create a singleton EventEmitter which the search input : As you can see, this is a very specific event which the SidebarView has to know about. Also let's say you have a global search input. Over time it seems like you have to be increasingly specific about event names. I have a feeling Flux is supposed alleviate this problem somehow, but if so is there any way we can give some more detail here and/or point people in the right direction? Seems like a common use case.
Flux is indeed one way of solving this problem. I created a PR to mention it.
thanks! for others' reference:
one step further might be nice to throw in a quick if-you-understand-a-little-about-flux example.
Change:
react: 'react', // TODO: Once this package is published, remove the external // 'react-debug-tools': 'react-debug-tools', <del> 'react-devtools-feature-flags': resolveFeatureFlags('inline'), </del> 'react-dom': 'react-dom', 'react-is': 'react-is', scheduler: 'scheduler', }, <ins> resolve: { alias: { 'react-devtools-feature-flags': resolveFeatureFlags('inline'), }, }, </ins> optimization: { minimize: false, },

Discussion:
Published has the following piece of code in : :roll_eyes:
FYI
Huh. That's no good.
This is because I accidentally put the module map in an map rather than a map. Oops.
Fix published in 4.11.1
Thanks!
Change:
localClearTimeout(timeoutId); }; } else { <ins> if (__DEV__) { if (typeof requestAnimationFrameForReact !== 'function') { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } let localRequestAnimationFrame = typeof requestAnimationFrameForReact === 'function' ? requestAnimationFrameForReact : function(callback: Function) { invariant( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); }; </ins> let headOfPendingCallbacksLinkedList: CallbackConfigType | null = null; let tailOfPendingCallbacksLinkedList: CallbackConfigType | null = null;

Discussion:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in
Change:
); } }); <ins> JQueryMobileButton = React.createFactory(JQueryMobileButton); </ins> /** jQuery Mobile page content component. */ var JQueryMobileContent = React.createClass({

Discussion:
When I run the in examples jquery-mobile in the chromium browser, I get: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of (anonymous function)
I can confirm. Works fine with React version “0.12.2", but "0.13.0-alpha.2" gives: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of undefined ReactClass.createClass.Constructor (anonymous function) The jquery-mobile example is using component constructors in a way which makes the new version explode. gaearon lays is out here:
We'll make sure all the examples are working before we release 0.13 final but until then there's a non-trivial change they'll be broken at any point in time. Check out the latest stable branch for the working examples.
Change:
useState(); } `, <ins> ` // Valid because exceptions abort rendering function RegressionTest() { if (page == null) { throw new Error('oh no!'); } useState(); } `, </ins> ], invalid: [ {

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:
<sup>1</sup> Note that at this time, an _experimental_ build is required because DevTools depends on the `createRoot` API. <ins> To install all necessary dependencies, run the following command from the root of the repository: ```sh yarn install ``` </ins> #### Build from source To build dependencies from source, run the following command from the root of the repository: ```sh

Discussion:
When trying to build the [(]) locally: react yarn build-for-devtools from the root repo node version: v16.16.0.
This is the result of :
Yarn is the package manager of choice in this repository. Did you run from the root first?
I did not do that as I dont usually work with yarn. I will try now. Please reject my bug and thanks for your time. I feel a bit stupid.
Im trying it now, and it looks like its working. It would be great if someone adds this to the readme of the extension repo.
Sorry to hear. We definitely want to avoid that. You're absolutely right. I'm on it.
Please note also that they ask to do: . The command has , which doesnt work for windows and should be replaced by . This is the command:
Change:
expect(stubStyle.display).toEqual(''); }); <del> it('should skip child object attribute on web components', function() { </del> <ins> it('should skip reserved props on web components', function() { </ins> var container = document.createElement('div'); <del> // Test initial render to null ReactDOM.render(<my-component children={['foo']} />, container); </del> <ins> ReactDOM.render( <my-component children={['foo']} suppressContentEditableWarning={true} />, container ); </ins> expect(container.firstChild.hasAttribute('children')).toBe(false); <ins> expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); </ins> <del> // Test updates to null ReactDOM.render(<my-component children={['foo']} />, container); </del> <ins> ReactDOM.render( <my-component children={['bar']} suppressContentEditableWarning={false} />, container ); </ins> expect(container.firstChild.hasAttribute('children')).toBe(false); <ins> expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); }); it('should skip dangerouslySetInnerHTML on web components', function() { var container = document.createElement('div'); ReactDOM.render( <my-component dangerouslySetInnerHTML={{__html: 'hi'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); ReactDOM.render( <my-component dangerouslySetInnerHTML={{__html: 'bye'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); }); it('should skip reserved props on SVG components', function() { var container = document.createElement('div'); ReactDOM.render( <svg children={['foo']} suppressContentEditableWarning={true} />, container ); expect(container.firstChild.hasAttribute('children')).toBe(false); expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); ReactDOM.render( <svg children={['bar']} suppressContentEditableWarning={false} />, container ); expect(container.firstChild.hasAttribute('children')).toBe(false); expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); }); it('should skip dangerouslySetInnerHTML on SVG components', function() { var container = document.createElement('div'); ReactDOM.render( <svg dangerouslySetInnerHTML={{__html: 'hi'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); ReactDOM.render( <svg dangerouslySetInnerHTML={{__html: 'bye'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); </ins> }); it('should remove attributes', function() {

Discussion:
See for a basic example. I'm assuming there's some step in the new SVG code that we just need to remove the key if we consume it as a React prop.
Going to leave this open to ensure we block even though wrote fix before I finished submitting (do you ever sleep Dan!?)
I sleep incrementally. FWIW the fix is in
Change:
if (shouldUpdate) { if (typeof this._instance.componentWillUpdate === 'function') { <del> if (__DEV__) { if (warnAboutDeprecatedLifecycles) { const componentName = getName(element.type, this._instance); if (!didWarnAboutLegacyWillUpdate[componentName]) { lowPriorityWarning( false, '%s: componentWillUpdate() is deprecated and will be ' + 'removed in the next major version. Read about the motivations ' + 'behind this change: ' + 'https://fb.me/react-async-component-lifecycle-hooks' + 'nn' + 'As a temporary workaround, you can rename to ' + 'UNSAFE_componentWillUpdate instead.', componentName, ); didWarnAboutLegacyWillUpdate[componentName] = true; } } } </del> // In order to support react-lifecycles-compat polyfilled components, // Unsafe lifecycles should not be invoked for any component with the new gDSFP. if (typeof type.getDerivedStateFromProps !== 'function') {

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:
unmountComponent: function() { this.unmountChildren(); ReactBrowserEventEmitter.deleteAllListeners(this._rootNodeID); <del> ReactMount.purgeID(this._rootNodeID); </del> <ins> ReactComponentBrowserEnvironment.unmountIDFromEnvironment(this._rootNodeID); </ins> this._rootNodeID = null; }

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:
args: $ReadOnlyArray<any>, ): void { const message = format(...args); <del> // Note that by calling these functions we may be creating the ID for the first time. // If the Fiber is then never mounted, we are responsible for cleaning up after ourselves. // This is important because getOrGenerateFiberID() stores a Fiber in a couple of local Maps. // If the Fiber never mounts and we don't clean up after this code, we could leak. // Fortunately we would only leak Fibers that have errors/warnings associated with them, // which is hopefully only a small set and only in DEV mode– but this is still not great. // We should clean up Fibers like this when flushing; see recordPendingErrorsAndWarnings(). const fiberID = getOrGenerateFiberID(fiber); </del> if (__DEBUG__) { debug('onErrorOrWarning', fiber, null, `${type}: "${message}"`); } // Mark this Fiber as needed its warning/error count updated during the next flush. <del> fibersWithChangedErrorOrWarningCounts.add(fiberID); </del> <ins> fibersWithChangedErrorOrWarningCounts.add(fiber); </ins> <del> // Update the error/warning messages and counts for the Fiber. const fiberMap = type === 'error' ? fiberToErrorsMap : fiberToWarningsMap; const messageMap = fiberMap.get(fiberID); </del> <ins> // Track the warning/error for later. const fiberMap = type === 'error' ? pendingFiberToErrorsMap : pendingFiberToWarningsMap; const messageMap = fiberMap.get(fiber); </ins> if (messageMap != null) { const count = messageMap.get(message) || 0; messageMap.set(message, count + 1); } else { <del> fiberMap.set(fiberID, new Map([[message, 1]])); </del> <ins> fiberMap.set(fiber, new Map([[message, 1]])); </ins> } <del> // If this Fiber is currently being inspected, mark it as needing an udpate as well. updateMostRecentlyInspectedElementIfNecessary(fiberID); </del> // Passive effects may trigger errors or warnings too; // In this case, we should wait until the rest of the passive effects have run, // but we shouldn't wait until the next commit because that might be a long time.

Discussion:
the block to inspect "Component" in DevTools : "Could not inspect element with id 5" Originally reported in https://user- Every time
Here's another Chrome extension build with the fix from :
Everything fixed. Awesome :+1:
FYI just published as 4.13.4
Change:
React.unmountComponentAtNode(container); expect(innerUnmounted).toBe(true); <del> // <Component />, <Inner />, and both <div /> elements and their wrappers // each call unmountIDFromEnvironment which calls purgeID, for a total of 6. </del> <ins> // The text and both <div /> elements and their wrappers each call // unmountIDFromEnvironment which calls purgeID, for a total of 3. </ins> // TODO: Test the effect of this. E.g. does the node cache get repopulated // after a getDOMNode call? <del> expect(ReactMount.purgeID.callCount).toBe(6); </del> <ins> expect(ReactMount.purgeID.callCount).toBe(3); </ins> }); it('should warn when shouldComponentUpdate() returns undefined', function() {

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,