jiebi/CodeConvo huggingface dataset:
Change:
var warn = jest.genMockFn(); console.error = warn; getInitialStateWasCalled = false; <ins> getDefaultPropsWasCalled = false; </ins> test(React.createElement(ClassicProperties), 'SPAN', 'foo'); expect(getInitialStateWasCalled).toBe(false); <del> expect(warn.mock.calls.length).toBe(3); </del> <ins> expect(getDefaultPropsWasCalled).toBe(false); expect(warn.mock.calls.length).toBe(4); </ins> expect(warn.mock.calls[0][0]).toContain( 'getInitialState was defined on ClassicProperties, ' + 'a plain JavaScript class.' ); expect(warn.mock.calls[1][0]).toContain( <del> 'propTypes was defined as an instance property on ClassicProperties.' </del> <ins> 'getDefaultProps was defined on ClassicProperties, ' + 'a plain JavaScript class.' </ins> ); expect(warn.mock.calls[2][0]).toContain( <ins> 'propTypes was defined as an instance property on ClassicProperties.' ); expect(warn.mock.calls[3][0]).toContain( </ins> 'contextTypes was defined as an instance property on ClassicProperties.' ); });

Discussion:
I am working on a very simple component with default props. And I simply render it without any props (). But I got an empty object from console output. I am using react 0.13.1, chrome 41, OSX 10.10. Any idea what is going wrong?
Es6 classes need defaultProps as a static property. Navigation.defaultProps = {...}
Thanks. Maybe update this in documentation :) ? I will be happy to send in a PR
has some commentary on docs and es6. I agree that I’d like to see better docs on the class syntax. I’m just a guy who happened to see your issue really quickly :)
does reference this. It might be good to also put some documentation in to make it a bit easier to find. I'm going to close this out since it's invalid but I'd love to see a PR with more docs :)
I think you should have also seen a runtime warning for this?
not really, though
Thanks, looks like an oversight. Fix incoming…
Change:
* @return {string} */ function getComponentKey(component, index) { <del> if (component && component.key != null) { </del> <ins> // Do some typechecking here since we call this blindly. We want to ensure // that we don't block potential future ES APIs. if (component && typeof component === 'object' && component.key != null) { </ins> // Explicit key return wrapUserProvidedKey(component.key); }

Discussion:
I came across this one because I'd extended with a custom key generator. React ends up treating the function itself as the child key, so it hides any strings that come after it. Object key handling is documented and makes sense. Not sure it makes sense to handle string keys this way.
what do you want to do here?
I think the issue is actually here yeah? Should probably be changed to
Nice catch. I think that we might actually have more of these flaws. We should be more careful as this prevents browsers to add to the string prototype. that if branch can be separated and we just use the implicit key for string/number.
Change:
); } }); <ins> JQueryMobileContent = React.createFactory(JQueryMobileContent); </ins> /** jQuery Mobile footer component. */ var JQueryMobileFooter = 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:
} } }, <ins> isProfiling() { return isProfiling; }, </ins> beginProfiling() { if (__DEV__) { if (isProfiling) {

Discussion:
I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR
Change:
} .PrimitiveHookNumber { <del> color: var(--color-component-badge-count-inverted); background-color: var(--color-component-badge-background-inverted); </del> <ins> background-color: var(--color-primitive-hook-badge-background); color: var(--color-primitive-hook-badge-text); </ins> font-size: var(--font-size-monospace-small); margin-right: 0.25rem; border-radius: 0.125rem;

Discussion:
I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.
Change:
} if (typeof value === 'string') { <ins> if (__DEV__) { if (component) { var owner = component._currentElement._owner; var ownerName = owner ? owner.getName() : null; if (ownerName && !styleWarnings[ownerName]) { styleWarnings[ownerName] = {}; } var warned = false; if (ownerName) { var warnings = styleWarnings[ownerName]; warned = warnings[name]; if (!warned) { warnings[name] = true; } } if (!warned) { warning( false, 'a `%s` tag (owner: `%s`) was passed a numeric string value ' + 'for CSS property `%s` (value: `%s`) which will be treated ' + 'as a unitless number in a future version of React.', component._currentElement.type, ownerName || 'unknown', name, value ); } } } </ins> value = value.trim(); } return value + 'px';

Discussion:
It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.
Change:
var ON_CLICK_KEY = keyOf({onClick: null}); var ON_TOUCH_TAP_KEY = keyOf({onTouchTap: null}); var ON_CHANGE_KEY = keyOf({onChange: null}); <ins> var ON_MOUSE_ENTER_KEY = keyOf({onMouseEnter: null}); </ins> /**

Discussion:
While testing I wanted to simulate and events, but for some reason they are not firing the handlers in the component. Here's a fiddle to show you: You'll see that with the Simulate functions, only the click is actually triggered, while the other ones not. With the real events everything works perfectly. I tried to debug a little bit what's going on, but didn't get much information, especially since it's the first time I'm diving into the events mechanism internals in React. If you want more info, then I can try and dig a bit deeper, but I think the fiddle is clear enough.
Yeah, unfortunately mouseEnter/mouseLeave don't get simulated properly at the moment due to their unique bubbling situation. The biggest blocker here is picking a good API, I think. Maybe just ?
Why should the user care about where the mouse moves from/to? Perhaps this can be handled internally? Is the problem due to bubbling here? I may need to dive into the code a little more to get a better understanding and stop saying nonsense :P
Yes, it's due to bubbling. If you have the DOM structure and your mouse moves from C to D, then C and B receive mouseleave events, D receives a mouseenter event, and A receives nothing. All other events bubble up to the root. Perhaps it's good enough to just make simulated mouseEnter and mouseLeave events not bubble at all.
That would work at least where I was trying to test. While testing I generally don't need anything too complex, just making sure the right behavior triggers when the event happens. Hopefully that's the way others do as well
(As a workaround for now, you can use SimulateNative.mouseOver and SimulateNative.mouseOut (making sure to specify relatedTarget appropriately on each) and together they will cause React to fire onMouseEnter and onMouseLeave events.)
Do we have a good solution for such case now? I'm trying my solution but feeling so tricky. And I got still quite strange results:
can you give an example. I can't find any documentation on SimulateNative or how to set relatedTarget appropriately?
You want to do something like this: The simulates the mouse moving one element another. The element can be anything really, it’s not important.
Do we have a good solution for such case now? or It can not be solved?

I am manually applying this patch until it is pulled into the core:
Any update on this?
I was able to get my tests to pass using SimulateNative. Here's my codez: Test results:
I tried that using both and instead of but it still did not trigger my event.
If it helps - the difference which worked for me was calling with a and not a . Pass & fail states listed along with full test case below: This seems to also work:
No update so far? Maybe some workarounds?
This was fixed in in April as you can see a few messages up; it'll be in the 0.14 release. If you search "workaround" on this page you'll see that I also posted a workaround over a year ago.
Sorry, really missed it. Thanks for it!
Change:
"manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Firefox Developer Tools.", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "browser_specific_settings": { "gecko": { "id": "@react-devtools",

Discussion:
development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0
Change:
initBackend, setupNativeStyleEditor, }); hook.emit('devtools-backend-installed', COMPACT_VERSION_NAME); }

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:
skipEnvCheck: true, // To simplify debugging tests: emitFullSignatures: true, <ins> ...options.freshOptions, </ins> }, ], ...(options.plugins || []),

Discussion:
Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.
Change:
## JSRomandie Meetup <del> [Renault John Lecoultre](https://twitter.com/renajohn/) did a React introduction talk at a JS meetup called [JS Romandie](https://twitter.com/jsromandie) last week. </del> <ins> [Renault John Lecoultre](https://twitter.com/renajohn/) from [BugBuster](http://www.bugbuster.com) did a React introduction talk at a JS meetup called [JS Romandie](https://twitter.com/jsromandie) last week. </ins> <script async class="speakerdeck-embed" data-id="888a9d50c01b01300df36658d0894ac1" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>

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:
title: Two-Way Binding Helpers permalink: two-way-binding-helpers.html prev: animation.html <del> next: class-name-manipulation.html </del> <ins> next: test-utils.html </ins> --- `ReactLink` is an easy way to express two-way binding with React.

Discussion:
Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors
Change:
getInitialStateWasCalled = true {} <ins> getDefaultProps: -> getDefaultPropsWasCalled = true {} </ins> render: -> span className: 'foo' test React.createElement(Foo), 'SPAN', 'foo' expect(getInitialStateWasCalled).toBe false <del> expect(console.error.calls.length).toBe 3 </del> <ins> expect(getDefaultPropsWasCalled).toBe false expect(console.error.calls.length).toBe 4 </ins> expect(console.error.calls[0].args[0]).toContain( 'getInitialState was defined on Foo, a plain JavaScript class.' ) expect(console.error.calls[1].args[0]).toContain( <del> 'propTypes was defined as an instance property on Foo.' </del> <ins> 'getDefaultProps was defined on Foo, a plain JavaScript class.' </ins> ) expect(console.error.calls[2].args[0]).toContain( <ins> 'propTypes was defined as an instance property on Foo.' ) expect(console.error.calls[3].args[0]).toContain( </ins> 'contextTypes was defined as an instance property on Foo.' )

Discussion:
I am working on a very simple component with default props. And I simply render it without any props (). But I got an empty object from console output. I am using react 0.13.1, chrome 41, OSX 10.10. Any idea what is going wrong?
Es6 classes need defaultProps as a static property. Navigation.defaultProps = {...}
Thanks. Maybe update this in documentation :) ? I will be happy to send in a PR
has some commentary on docs and es6. I agree that I’d like to see better docs on the class syntax. I’m just a guy who happened to see your issue really quickly :)
does reference this. It might be good to also put some documentation in to make it a bit easier to find. I'm going to close this out since it's invalid but I'd love to see a PR with more docs :)
I think you should have also seen a runtime warning for this?
not really, though
Thanks, looks like an oversight. Fix incoming…
Change:
updateStyleHelper(theme, 'color-expand-collapse-toggle', documentElements); updateStyleHelper(theme, 'color-link', documentElements); updateStyleHelper(theme, 'color-modal-background', documentElements); <ins> updateStyleHelper( theme, 'color-primitive-hook-badge-background', documentElements, ); updateStyleHelper(theme, 'color-primitive-hook-badge-text', documentElements); </ins> updateStyleHelper(theme, 'color-record-active', documentElements); updateStyleHelper(theme, 'color-record-hover', documentElements); updateStyleHelper(theme, 'color-record-inactive', documentElements);

Discussion:
I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.
Change:
).toEqual(0); }); <ins> it('should remove refs when removing the child ref attribute', () => { const container = document.createElement('div'); const testInstance = ReactDOM.render(<TestComponent />, container); expect(ReactTestUtils.isDOMComponent(testInstance.refs.theInnerDiv)).toBe( true, ); expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key]) .length, ).toEqual(2); ReactDOM.render(<TestComponent removeRef={true} />, container); expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key]) .length, ).toEqual(0); }); </ins> it('should not error when destroying child with ref asynchronously', () => { class Modal extends React.Component { componentDidMount() {

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:
} propValue = this._previousStyleCopy = assign({}, props.style); } <del> propValue = CSSPropertyOperations.createMarkupForStyles(propValue); </del> <ins> propValue = CSSPropertyOperations.createMarkupForStyles(propValue, this); </ins> } var markup = null; if (this._tag != null && isCustomComponent(this._tag, props)) {

Discussion:
It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.
Change:
time: true, // There are working polyfills for <dialog>. Let people use it. dialog: true, <ins> // Electron ships a custom <webview> tag to display external web content in // an isolated frame and process. // This tag is not present in non Electron environments such as JSDom which // is often used for testing purposes. // @see https://electronjs.org/docs/api/webview-tag webview: true, </ins> }; validatePropertiesInDevelopment = function(type, props) {

Discussion:
Do you want to request a feature or report a bug? Bug (for electron users) What is the current behavior? When running jest, if any components containing a webview element are rendered, a warning is rendered to the console. When many tests are run, the output is littered with warnings. 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? No warning is logged to the console. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React: 16.4.1 Electron: 2.0.6 Unknown if it worked in prior versions of react.
What other special tags does Electron have?
Looking through their docs it seems to be only the tag for now:
In that case I don’t mind adding it to the whitelist. Send a PR?
You beat me to the punch. Thanks so much and