jiebi/CodeConvo huggingface dataset:
Change:
var invariant = require('invariant'); var isEventSupported = require('isEventSupported'); var keyOf = require('keyOf'); <ins> var shallowEqual = require('shallowEqual'); </ins> var validateDOMNesting = require('validateDOMNesting'); var warning = require('warning');

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:
<!-- TODO: Document mixins here directly. --> <ins> ### displayName ```javascript string displayName ``` The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](react/docs/jsx-in-depth.html#react-composite-components). </ins> ## Lifecycle Methods Various methods are executed at specific points in a component's lifecycle.

Discussion:
I couldn't find a reference to the fact that jsx transform attaches to the component spec, this would be nice to document somewhere (more importantly, that not using jsx means debugging messages will be littered with ). I found this while using .
That would be very nice indeed. If you want to take a stab at it, the docs are in the repo in the markdown format. Would love to have you on the contributor list :)
Change:
); if (__DEV__) { const inst = workInProgress.stateNode; <del> if (inst.props !== nextProps) { </del> <ins> if (shouldUpdate && inst.props !== nextProps) { </ins> if (!didWarnAboutReassigningProps) { console.error( 'It looks like %s is reassigning its own `this.props` while rendering. ' +

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:
<ins> function Component({ value }) { const object = { get value() { return value; }, }; return <div>{object.value}</div>; } export const FIXTURE_ENTRYPOINT = { fn: foo, params: [{ value: 0 }], sequentialRenders: [{ value: 1 }, { value: 2 }], }; </ins>

Discussion:
[ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization) [X] babel-plugin-react-compiler (build issue installing or using the Babel plugin) [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin) [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script) In the above code, doubleValue uses get syntax, and after compilation, it loses the keyword and becomes an ordinary function. In this case the compiler should skip compilation until this syntax is supported. I know that some syntaxes are currently unsupported by the react compiler, can we know what syntaxes are currently unsupported and in process? Every time 0-rc--
Thanks for posting, this is a bug. We have not support for get/set syntax but looks like we missed a todo for this.
Let’s close when the associated PR lands
Oops my bad, I didn't read
Change:
'use strict'; <del> import ExecutionEnvironment from 'fbjs/lib/ExecutionEnvironment'; import warning from 'fbjs/lib/warning'; </del> // We capture a local reference to any global, in case it gets polyfilled after // this module is initially evaluated. // We want to be using a consistent implementation. <del> const localRequestAnimationFrame = requestAnimationFrame; </del> <ins> const localRequestAnimationFrame = typeof requestAnimationFrame === 'function' ? requestAnimationFrame : undefined; </ins> <del> if (__DEV__) { if ( ExecutionEnvironment.canUseDOM && typeof localRequestAnimationFrame !== 'function' ) { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } </del> <ins> // The callsites should check if the requestAnimationFrame imported from this module is a function, // fire a developer warning if it doesn't exist, and substitute it by a shim in that case // (e.g. that throws on call). </ins> export default localRequestAnimationFrame;

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:
var getDebugConfig = function() { return { "debug": true, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": true

Discussion:
I'd rather do it , if you don't mind.
I think we should do both. I think a forced clean should force clean all of the build artifacts (of which .module-cache is a part of).
can we distinguish between and ?
In what situation would you want to clean but not remove ?
I'm actually not aware of any other use cases for so maybe this is fine. But it still means we need to tell people to do if they encounter problems that might be fixed by doing so, whereas gives us a way to get the same effect with no verbal communication.
I'm going to do it. I think we should probably also do .
Closed by .
Change:
// Never dehydrate the "hooks" object at the top levels. return true; } <ins> if ( path[path.length - 2] === 'hookSource' && path[path.length - 1] === 'fileName' ) { // It's important to preserve the full file name (URL) for hook sources // in case the user has enabled the named hooks feature. // Otherwise the frontend may end up with a partial URL which it can't load. return true; } </ins> if ( path[path.length - 1] === 'subHooks' || path[path.length - 2] === 'subHooks'

Discussion:
This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).
Change:
installHook(window); export type StatusListener = (message: string) => void; <ins> export type OnDisconnectedCallback = () => void; </ins> let node: HTMLElement = ((null: any): HTMLElement); let nodeWaitingToConnectHTML: string = ''; let projectRoots: Array<string> = []; let statusListener: StatusListener = (message: string) => {}; <ins> let disconnectedCallback: OnDisconnectedCallback = () => {}; </ins> // TODO (Webpack 5) Hopefully we can remove this prop after the Webpack 5 migration. function hookNamesModuleLoaderFunction() {

Discussion:
Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!
Change:
return map; } <del> function isValidUrl(possibleURL: string): boolean { try { // eslint-disable-next-line no-new new URL(possibleURL); } catch (_) { return false; } return true; } </del> function loadSourceFiles( locationKeyToHookSourceData: Map<string, HookSourceData>, ): Promise<*> {

Discussion:
This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).
Change:
Component.displayName || Component.name || 'Component' ); } <ins> var propsMutated = inst.props !== publicProps; var componentName = Component.displayName || Component.name || 'Component'; warning( typeof inst.props === 'undefined' || !propsMutated, '%s(...): When calling super() in `%s`, make sure to pass ' + 'up the same props that your component's constructor was passed.', componentName, componentName ); </ins> } // These should be set up in the constructor, but as a convenience for

Discussion:
Having the constructor passing super a props object that differs (in object equality and/or shallow compare) from the original is... illegal, because: We should have a warning for that, because it's reasonable for someone to assume they could extend a component and modify the props, without considering the ramifications, and the bug won't show up in their initial render test but will show up when the component updates.
Can a shallow comparison of and suffice, or is a deep equality check between the two objects needed?
I think shallow is fine. Deep equality is too difficult/expensive because of cycles. Note that we should only do the check in dev mode, so surround your logic with a block
Change:
expect(stubStyle.color).toEqual(''); }); <ins> // trouble </ins> it("should update styles when 'style' changes from null to object", function() { var container = document.createElement('div'); var styles = {color: 'red'};

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:
"manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Microsoft Edge Developer Tools.", <del> "version": "4.27.7", "version_name": "4.27.7", </del> <ins> "version": "4.27.8", "version_name": "4.27.8", </ins> "minimum_chrome_version": "102", "icons": { "16": "icons/16-production.png",

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:
integrity sha512-zIURGIS1E1Q4pcrMjp+nnEh+16G56eG/MUllJH8yEvw7asDo7Ac9uhC9KIH5jzpITueEZolfYglnCGIuSBz39g== axios@^1.6.1: <del> version "1.7.1" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.1.tgz#522145622a09dfaf49359837db9649ff245a35b9" integrity sha512-+LV37nQcd1EpFalkXksWNBiA17NZ5m5/WspmHGmZmdx1qBOg/VNq/c4eRJiA9VQQHBOs+N0ZhhdU10h2TyNK7Q== </del> <ins> version "1.7.4" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.4.tgz#4c8ded1b43683c8dd362973c393f3ede24052aa2" integrity sha512-DukmaFRnY6AzAALSH4J2M3k6PkaC+MfaAGdEERRWcC9q3/TWQwLpHR8ZRLKTdQ3aBDL64EdluRDjJqKw+BPZEw== </ins> dependencies: follow-redirects "^1.15.6" form-data "^4.0.0"

Discussion:
Now that react-python is being completely deprecated and will probably cease to function soon with new versions of react ( ) the docs should probably no longer link to it from the Use React and JSX in Python Applications page.
For those following along, I assume is referring to It's an old blog post (with a date), not part of the living docs. We generally don't go back in time and update old posts because things are constantly changing over time and it's hard enough to just keep the main documentation up-to-date. If someone wants to add a red note box that says "Update: PyReact is now deprecated", I think I would be ok with that and we would likely accept such a PR. cc because he feels the strongest about updating historical posts. Anyway, I'm going to close this out to take it off our radar, because we don't generally track/update historical posts.
Meh, If somebody did want to add a note like that, that would be fine. But I don't think we need to change the content of the post. And linking to the actual project is probably good because it has a nice big deprecated notice in the readme.
Ah, I actually hadn't noticed that it's a blog post. It's the thing that comes up when you google "react python" (or anything similar) and is formatted the same as the rest of React's documentation. But yeah, it seems like a shame to have to keep every old blog post up to date. (I suppose after JSXTransformer becomes completely nonfunctional it might be worth making PyReact's deprecation notice a bit stronger, but at this point it's really just nitpicking)
Change:
five: true }); }); <ins> it('should support mergeKeySets with undefined input', function () { var prev = { one: true, two: true }; var next = undefined; expect(ReactTransitionKeySet.mergeKeySets(prev, next)).toEqual({ one: true, two: true }); prev = undefined; next = { three: true, four: true }; expect(ReactTransitionKeySet.mergeKeySets(prev, next)).toEqual({ three: true, four: true }); }); </ins> });

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 :)
Change:
} } <ins> function stripComplexValues(key, value) { if (typeof value !== 'object' || Array.isArray(value) || value == null) { return value; } var prototype = Object.getPrototypeOf(value); if (!prototype || prototype === Object.prototype) { return value; } return '<not serializable>'; } </ins> // This implementation of ReactPerf is going away some time mid 15.x. // While we plan to keep most of the API, the actual format of measurements // will change dramatically. To signal this, we wrap them into an opaque-ish

Discussion:
Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.
Change:
var runScripts; var loadScripts; var headEl; <ins> var dummyAnchor; </ins> var buffer = require('buffer'); var transform = require('jstransform').transform;

Discussion:
It was reported to me on IRC today and confirmed on master / FF nightly myself. Also
I should add that when there are no errors in the jsx file the page still renders correctly, but the behavior persists (cannot load source file). Errors are reported from lines that do not exist in html file which makes bugs hard to track down. Confirmed on Windows 7 and Firefox 29. I can add more details once I get back to work on Monday - just let me know what information you need. Thanks, -Eric
What exactly is the issue? If it's just source lines being "off/out of bounds" then it's possible that it's the old JSX issue where source lines reported by esprima are mysteriously offset. AFAIK it was never explicitly solved, but no one was able to reproduce it anymore, perhaps it struck again? Other than that, JSX is just sugar on-top of esprima (and source-map I assume), and I think even the above issue is/was, so I don't think JSX is necessarily the root cause here.
Hi thanks for responding. At the most general level, the problem I am trying to solve is this: I want to be able to use the JSXTransformer script and be able to see a useful version of my compiled JS script which (pre-compilation) had JSX in it. I want to do this so that when I make an error in my JSX-containing JS script I can get a useful error message and hopefully see where the problem is in my original script (or get some clue as to where the problem might be). As it stands now, when I have an error in my script, the console just complains about lines which do not exist in my HTML file (which is only a few lines). So it'll say there's an error in line 65 of even though is only 15 lines. Compounding the problem is that, even when there were no errors and the JSX compiled perfectly to JS and the JS file ran just fine, I still cannot see any sources other than the JSX compiler, the reactjs source and my jquery source. I can't see either a uncompiled or compiled version of my JSX-containing JS file. Instead, what I see is this: Hopefully that explains everything, but let me know if you're still confused. I can provide more info when/if you need it.

Thanks
When I tested last week I couldn't get the source map to do anything at all in Firefox.
Figured it out. I can't decide if it's a Firefox issue or something we're doing wrong, but is the problem. It seems when we pass URLs (eg "") here, Firefox chokes. If we pass a filename (eg "") the sourcemap is usable. So short term, I'm just going to pull off the actual filename and use that. Inline scripts don't appear to have been a problem (supporting my URL theory). cc from the Firefox devtools team, might be worth looking into on your end as well (can't remember if I filed that bug).
Can we keep the full path but drop the domain-part perhaps?
Good idea, I changed to doing that :)
would love a minimal test case. Can you repro with just mozilla/source-map, or only while using devtools?
Change:
function markRef(current: Fiber | null, workInProgress: Fiber) { const ref = workInProgress.ref; <del> if (ref !== null && (!current || current.ref !== ref)) { </del> <ins> if ( (current === null && ref !== null) || (current !== null && current.ref !== ref) ) { </ins> // Schedule a Ref effect workInProgress.effectTag |= Ref; }

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.
Change:
expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key]) .length, <del> ).toEqual(1); </del> <ins> ).toEqual(2); </ins> ReactDOM.render(<TestComponent destroy={true} />, container); expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key])

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.