jiebi/CodeConvo huggingface dataset:
Change:
4. Trigger an update to the DOM. It's worth noting that React will handle new return values of `render()` by <del> making the mininal set of mutations necessary to bring the DOM up-to-date. In </del> <ins> making the minimal set of mutations necessary to bring the DOM up-to-date. In </ins> this case, only the `textContent` of the rendered link will be mutated. In summary:

Discussion:
In React 17 it was required to import ReactDOMServer using the js extension if on Node 17, unless was set. In React 18 you cannot use the .js extension because it is not exported. You end up with this error: My proposal that fixes the problem is to add to the list of exports in React version: 17.0.2 vs 18.2.0
It's also worth noting that was dropped in Node 19 so there would have to be yet another workaround using which is less than ideal.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Bump
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
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!
Change:
})(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-41298772-1', 'facebook.github.io'); ga('send', 'pageview'); <ins> !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="https://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs"); </ins> </script> </body> </html>

Discussion:
The shows:  Sometimes we will make a typo mistake,e.g., enter not , not ,and then the result are the same with the pic above.This will make us very confused. And sometimes will spend us 2 or more minutes to find the typo,because at first we will check the code when we first see the error,"oh,god,I don't use ,why the error says it should be a func?",and then check it again and again,and finally find that it's just a typo and react will treat the as a to check. I think this is not very friendly and the doc does not mention.Maybe it could be improved?
If it's really not what React intended, can I work on this to throw a relevant warning?
I think it's clear enough. It shows on console that the property type is invalid, so you start from there. The prop type can be any function, from PropTypes object or not.
You are right.But the point is that if you don't know react will treat the undefined as a func to check,then you will be very confused,it maybe will spend your a lot of time to figure it out especially for new people.And the doc doesn't mention this. So I agree that if you already know this,it will be easy to realize what the error means.But for new people,it's not very friendly.
PropTypes have been removed from React core and now exist as a separate package . Any future feature requests, bug reports, or changes should be directed to the new repo at
in python we have somthing called deprecation warning ¬¬
in python we have somthing called deprecation warning ¬¬ So do we, and PropTypes have been warning since April. And there's automated codemod that will change the code for you (it's in the link).
Change:
"react-server": "./unstable-shared-subset.js", "default": "./index.js" }, <del> "./build-info.json": "./build-info.json", </del> <ins> "./package.json": "./package.json", </ins> "./jsx-runtime": "./jsx-runtime.js", "./jsx-dev-runtime": "./jsx-dev-runtime.js", "./": "./"

Discussion:
This is not published to npm.
This is a left over artifact from the way our release script used to work. It shouldn't cause any problems, but if you'd like to submit a PR removing this entry that'd be okay too.
Change:
fakeNativeEvent, node ); <ins> // Since we aren't using pooling, always persist the event. This will make // sure it's marked and won't warn when setting additional properties. event.persist(); </ins> Object.assign(event, eventData); if (dispatchConfig.phasedRegistrationNames) {

Discussion:
To reproduce, open Error is logged to browser dev tools (in Chrome & Firefox, somehow not in Safari). Happens on v15.0.0-rc.2 and on latest master version. The assignment of additional event data to the newly created SyntheticEvent triggers a console error:
Thanks for reporting. We'll get this fixed.
Are we not checking for unexpected warnings in tests? Should we? Curious how this crept in unnoticed.
node doesn't support Proxies so none of that code is actually getting tested :/ Even running with flag (which we do at least with ) doesn't enable it since it's "in progress". We could probably run with to force it on.
Change:
var grunt = require('grunt'); var UglifyJS = require('uglify-js'); var uglifyify = require('uglifyify'); <del> var _ = require('lodash'); </del> <ins> var derequire = require('derequire'); </ins> var SIMPLE_TEMPLATE = '/**n

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:
Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <React.Profiler id="parent" onRender={callback}> <AdvanceTime byAmount={10}> <React.Profiler id="child" onRender={callback}>

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

Discussion:
in a project that has and node error: Published package contains the following code: No absolute paths in bundle. successful evaluation.
Edit: Looks like was what broke this. My bad.
Fix has been published as 4.22.1. Sorry again.
Change:
'--harmony', 'Turns on JS transformations such as ES6 Classes etc.' ).option( <ins> '--target [version]', 'Specify your target version of ECMAScript. Valid values are "es3" and ' + '"es5". The default is "es5". "es3" will avoid uses of defineProperty and ' + 'will quote reserved words. WARNING: "es5" is not properly supported, even ' + 'with the use of es5shim, es5sham. If you need to support IE8, use "es3".', 'es5' ).option( </ins> '--strip-types', 'Strips out type annotations.' ).option(

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?
Change:
"electron": "^23.1.2", "ip": "^1.1.4", "minimist": "^1.2.3", <del> "react-devtools-core": "4.27.7", </del> <ins> "react-devtools-core": "4.27.8", </ins> "update-notifier": "^2.1.0" } }

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:
// Always set children to the same thing. In IE9, the selection range will // get reset if `textContent` is mutated. <del> var nativeProps = Object.assign({}, props, { </del> <ins> var nativeProps = Object.assign({}, DisabledInputUtils.getNativeProps(inst, props), { </ins> defaultValue: undefined, value: undefined, children: inst._wrapperState.initialValue,

Discussion:
The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.
Change:
<ins> <div class="nav-docs"> <div class="nav-docs-section"> <h3>Recent posts</h3> <ul> {% for post in site.posts %} <li><a href="/react{{ post.url }}"{% if page.title == post.title %} class="active"{% endif %}>{{ post.title }}</a></li> {% endfor %} </ul> </div> </div> </ins>

Discussion:
I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.
Change:
<!-- Upcoming changes go here --> </details> <ins> ## 4.11.1 (April 11, 2021) #### Bugfix * Fixed broken import in `react-devtools-inline` for feature flags file ([bvaughn](https://github.com/bvaughn) in [#21235](https://github.com/facebook/react/issues/21235)) </ins> ## 4.11.0 (April 9, 2021) #### Bugfix * `$r` should contain hooks property when it is `forwardRef` or `memo` component  ([meowtec](https://github.com/meowtec) in [#20626](https://github.com/facebook/react/pull/20626))

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:
expect(shallowRenderer.getMountedInstance().state).toBeNull(); }); <del> it('should warn if both componentWillReceiveProps and static getDerivedStateFromProps exist', () => { class ComponentWithWarnings extends React.Component { state = {}; static getDerivedStateFromProps(props, prevState) { return null; } UNSAFE_componentWillReceiveProps(nextProps) {} render() { return null; } } const shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<ComponentWithWarnings />)).toWarnDev( 'ComponentWithWarnings uses getDerivedStateFromProps() but also contains the following legacy lifecycles', ); // Should not log duplicate warning shallowRenderer.render(<ComponentWithWarnings />); }); it('should warn if getDerivedStateFromProps returns undefined', () => { class Component extends React.Component { state = {}; static getDerivedStateFromProps() {} render() { return null; } } const shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<Component />)).toWarnDev( 'Component.getDerivedStateFromProps(): A valid state object (or null) must ' + 'be returned. You have returned undefined.', ); // De-duped shallowRenderer.render(<Component />); }); it('should warn if state not initialized before getDerivedStateFromProps', () => { class Component extends React.Component { static getDerivedStateFromProps() { return null; } render() { return null; } } const shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<Component />)).toWarnDev( 'Component: Did not properly initialize state during construction. ' + 'Expected state to be an object, but it was undefined.', ); // De-duped shallowRenderer.render(<Component />); }); </del> it('should invoke both deprecated and new lifecycles if both are present', () => { const log = [];

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:
개발 하다보면 CSS 속성들이 단위 없이 그대로 유지되어야 할 때가 있을 겁니다. 아래의 프로퍼티들은 자동으로 "px"가 붙지 않는 속성 리스트 입니다: <ins> - `boxFlex` - `boxFlexGroup` </ins> - `columnCount` - `fillOpacity` - `flex` - `flexGrow` <ins> - `flexPositive` </ins> - `flexShrink` <ins> - `flexNegative` </ins> - `fontWeight` - `lineClamp` - `lineHeight`

Discussion:
The  CSS property should not be getting a suffix automatically because a unit-less value can represent the number of spaces that make up the width in a tab. The JS name for this property is . See in the React docs.
A solution for now is to use the which is pretty much equivalent.
Sounds like a good idea. Are you interested in creating a PR to add it?
Yes, the only thing I don't know is whether there needs to be anything special done to also include and handle object already in place
We autogenerate the vender-prefixed styles there (which you might have seen below where you changed code) so that's all you need to do! Thanks again.
Change:
> > [Read the full post...](https://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-AngularJS-A-Closer-Look) <del> In the same vein, [Markov Twain](https://twitter.com/markov_twain/status/345702941845499906) re-implemented the examples on the front-page [with Ember](http://jsbin.com/azihiw/2/edit) and [Vlad Yazhbin](https://twitter.com/vla) re-implemented the tutorial [with Angular](https://jsfiddle.net/vla/Cdrse/). </del> <ins> In the same vein, [Markov Twain](https://twitter.com/markov_twain/status/345702941845499906) re-implemented the examples on the front-page [with Ember](http://jsbin.com/azihiw/2/edit) and [Vlad Yazhbin](https://twitter.com/vla) re-implemented the tutorial [with Angular](http://jsfiddle.net/vla/Cdrse/). </ins> ## Web Components: React & x-tags

Discussion:
The Post gave an example of reconciliation by this . but It's not working, If I understand correctly, it should be something like . Should I create a PR by change the url to fix it?
The problem is that it is a https link for a fiddle that only supports http. There are actually more links with the same bug. Updating the fiddles would be one way to fix it, but that is a lot of work. And since the fiddles are part of old blog posts, it would be kind of like rewriting history. In my opinion the best way to fix it is reverting the links back to http. See for my proposed solution.
I see, thank u
I feel like the more 'correct'/'ideal' solution is to have the fiddle authors update their fiddles. That said, I don't feel too strongly, and will let make the decision on this.
Change:
this._updater, ); <del> if (__DEV__) { if (typeof element.type.getDerivedStateFromProps === 'function') { if ( this._instance.state === null || this._instance.state === undefined ) { const componentName = getName(element.type, this._instance) || 'Unknown'; if (!didWarnAboutUninitializedState[componentName]) { warning( false, '%s: Did not properly initialize state during construction. ' + 'Expected state to be an object, but it was %s.', componentName, this._instance.state === null ? 'null' : 'undefined', ); didWarnAboutUninitializedState[componentName] = true; } } } } </del> this._updateStateFromStaticLifecycle(element.props); if (element.type.hasOwnProperty('contextTypes')) {

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:
{ "name": "react-devtools-inline", <del> "version": "4.11.0", </del> <ins> "version": "4.11.1", </ins> "description": "Embed react-devtools within a website", "license": "MIT", "main": "./dist/backend.js",

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:
<ins> // Do not delete or move this file. // Many fiddles reference it so we have to keep it here. (function() { var tag = document.querySelector( 'script[type="application/javascript;version=1.7"]' ); if (!tag || tag.textContent.indexOf('window.onload=function(){') !== -1) { alert('Bad JSFiddle configuration, please fork the original React JSFiddle'); } tag.setAttribute('type', 'text/jsx;harmony=true'); tag.textContent = tag.textContent.replace(/^//<![CDATA[/, ''); })(); </ins>

Discussion:
no longer works, and this causes all old fiddles like to break. We should fix it.
I've also noticed fiddles[1][2] linking to being broken. I assume they were/are linking to the same place, but it's something to keep in mind. [1] [2] (All the examples seem to be broken)
It will take a few minutes to deploy the site but hopefully this should be fixed now.
Unfortunately Recharts examples are broken because they don't specify the React version. So they accidentally "updated" to React 16 that has different file names. We could potentially fix this on our side by providing a fallback. But then, one of the most commonly used builds () doesn't even exist anymore. So this has to be fixed on their side anyway.