jiebi/CodeConvo huggingface dataset:
Change:
// Should be document order, not mount order (which would be purple, orange) expect(log).toEqual(['orangepurple', 'orange', 'purple']); }); <ins> it('does not warn for getDOMNode on ES6 classes', function() { var Foo = React.createClass({ render: function() { return <div />; } }); class Bar extends React.Component { render() { return <div />; } } spyOn(console, 'warn'); var foo = ReactTestUtils.renderIntoDocument(<Foo />); expect(ReactTestUtils.isDOMComponent(foo)).toBe(false); var bar = ReactTestUtils.renderIntoDocument(<Bar />); expect(ReactTestUtils.isDOMComponent(bar)).toBe(false); var div = ReactTestUtils.renderIntoDocument(<div />); expect(ReactTestUtils.isDOMComponent(div)).toBe(true); expect(console.warn.calls.length).toBe(0); }); </ins> });

Discussion:
TestUtils.isDOMComponent(...) uses deprecated Element.getDOMNode(), resulting in console warnings when running tests. In my case, running 175 unit tests results in 700+ such warnings, drowning the output of the tests.
How are what tests are you running?
The tests are standard unit tests for custom React components. For example, I have a Toggle component that dispatches an event with type '' when clicked.
I'm also seeing the same issue testing under karma and mocha.
it looks like you this TODO? Can we get this fixed? Happy to help, but not sure what the right heuristic is.
This is unfortunate. I don't quite know what the right heuristic should be for 0.13, but we're changing it for 0.14 anyway since refs on DOM component will just be regular DOM nodes so I think we'll just power through. :/
Maybe we can do ?
I was thinking that we can reuse string types for ART and React Native too. We wouldn't want a React Native node to hit this.
maybe then?
It is not an own property. (And will be deprecated anyway so not a great heuristic.)
Lets just move fast on the ref === real DOM node stuff instead of spending time figuring this out.
Change:
} else if (expectedMessages.length === 1) { errorMessage = 'Unexpected warning recorded: ' + <del> jestDiff(normalizedMessage, expectedMessages[0]); </del> <ins> jestDiff(expectedMessages[0], normalizedMessage); </ins> } else { errorMessage = 'Unexpected warning recorded: ' + <del> jestDiff([normalizedMessage], expectedMessages); </del> <ins> jestDiff(expectedMessages, [normalizedMessage]); </ins> } // Record the call stack for unexpected warnings.

Discussion:
Do you want to request a feature or report a bug? bug What is the current behavior? calls as and :  where by default is annotated as (green), as (red). What is the expected behavior? should pass the expected values into , the actual (received) values into of :
Change:
topError: null, topFocus: null, topInput: null, <ins> topInvalid: null, </ins> topKeyDown: null, topKeyPress: null, topKeyUp: null,

Discussion:
Ref:
I'm taking a look at this as a first bug - from the docs and some testing, the event seems to be fired at the form element level rather than the form itself. That is to say: will not log on submit, but: will log on submit. Does this match the expected behaviour, and if so do we want the handler to be on the individual React.DOM form elements (i.e. so it is called when that element is invalid), or do we want it to bubble up to the parent (i.e. so it is called whenever at least one element in that form is invalid)?
We should match the DOM and fire it on the element (not the form). We already have support for these events which don't bubble. Most of our events are at the document level and then delegated but the ones which don't bubble need to be to specific elements on creation. Here's how we're doing it for forms and the submit & reset events: Thanks for taking this on! Feel free to get a PR up before it's completely ready if you have questions / need help.
Thanks Paul, good to know I was looking in the right place! Will update when I have had time to create a PR or if I need any help :) Cheers Tom
Hey, I've put together a PR at - it would be great to get your feedback on it. A couple of specific questions I had: should I handle automated testing of this? There's a lot of test code to look at and I'm unfamiliar with the React codebase, so I'm unsure if/how this should be tested. the splitting out of the logic make sense? Or do you think it would be better to have a separate statement for this bit, preceeding the other in , matching all the elements which need this setup, and then keep the other as is (minus the first ) Any feedback appreciated, this does seem to work but I'm totally new to the React code so not sure if the way I've gone about it is suitable or not! Cheers, Tom
Awesome!
Change:
<ins> --- title: JSFiddle Integration layout: post author: Vjeux --- [JSFiddle](http://jsfiddle.net) just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this **[base React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)**, fork it and share it! A [fiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) is also available . <blockquote class="twitter-tweet" align="center"><p>React (by Facebook) is now available on JSFiddle. <a href="http://t.co/wNQf9JPv5u" title="http://facebook.github.io/react/">facebook.github.io/react/</a></p>&mdash; JSFiddle (@jsfiddle) <a href="https://twitter.com/jsfiddle/status/341114115781177344">June 2, 2013</a></blockquote> <script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> </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:
expect(typeof Component.specialType.isRequired).toBe('function'); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('is indistinguishable from a plain object', function() { var element = React.createElement('div', {className: 'foo'}); var object = {}; expect(element.constructor).toBe(object.constructor); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('should use default prop value when removing a prop', function() { var Component = React.createClass({ getDefaultProps: function() {

Discussion:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.
Change:
It is a good idea to avoid spamming the console with duplicate warnings: <del> ````js </del> <ins> ```js </ins> var warning = require('warning'); var didWarnAboutMath = false;

Discussion:
There appears to be a typo on line 116 of "codebase-". Specifically, I see one "" symbol. This results in all text after line 116 appearing as one large block of code. See the screenshot below, with the markdown code on the left and the stylized code rendered on the right: <img width="1389" alt="screen shot 2017-01-09 at 2 38 51 pm" src=""Based on the content of the subsequent text after line 116, I would expect it to appear as the following: <img width="1436" alt="screen shot 2017-01-09 at 2 42 08 pm" src=""If this is indeed something that should be fixed, I'd like to fix it, and can submit a PR immediately.
I think you're right, please do submit a PR.
(For future reference, feel free to send PRs for small fixes like this without creating an issue.)
Change:
| `tabIndex=(array with string)`| (initial)| `<number: -1>` | | `tabIndex=(empty array)`| (initial)| `<number: -1>` | | `tabIndex=(object)`| (initial)| `<number: -1>` | <del> | `tabIndex=(numeric string)`| (initial, ssr mismatch)| `<number: -1>` | </del> <ins> | `tabIndex=(numeric string)`| (changed)| `<number: 42>` | </ins> | `tabIndex=(-1)`| (initial)| `<number: -1>` | <del> | `tabIndex=(0)`| (initial, ssr mismatch)| `<number: -1>` | | `tabIndex=(integer)`| (initial, ssr mismatch)| `<number: -1>` | </del> <ins> | `tabIndex=(0)`| (changed)| `<number: 0>` | | `tabIndex=(integer)`| (changed)| `<number: 1>` | </ins> | `tabIndex=(NaN)`| (initial, warning)| `<number: -1>` | <del> | `tabIndex=(float)`| (initial, ssr mismatch)| `<number: -1>` | </del> <ins> | `tabIndex=(float)`| (changed)| `<number: 99>` | </ins> | `tabIndex=(true)`| (initial, warning)| `<number: -1>` | | `tabIndex=(false)`| (initial, warning)| `<number: -1>` | | `tabIndex=(string 'true')`| (initial)| `<number: -1>` | | `tabIndex=(string 'false')`| (initial)| `<number: -1>` | | `tabIndex=(string 'on')`| (initial)| `<number: -1>` | | `tabIndex=(string 'off')`| (initial)| `<number: -1>` | <del> | `tabIndex=(symbol)`| (initial, warning)| `<number: -1>` | </del> <ins> | `tabIndex=(symbol)`| (initial, warning, ssr error, ssr mismatch)| `<number: -1>` | </ins> | `tabIndex=(function)`| (initial, warning)| `<number: -1>` | | `tabIndex=(null)`| (initial)| `<number: -1>` | | `tabIndex=(undefined)`| (initial)| `<number: -1>` |

Discussion:
See the original report in The problem is that SVG is case sensitive, and so naïvely setting and relying on insensitivity won't work with it. The good news is it seems like is the only valid with this problem. We just missed it because it applies both to HTML and SVG. I think the fix is to add it back to the whitelist.
simple example where tabbing works & doesn't work depending on case Note that the console does not state the error did you mean not being Not really sure why this is but it does display in our app.
Thanks for confirming this issue, I've been struggling to identify the reason my svg component stopped working after the update. A component made of clickable <circleshave lost both focus and blur functionality, because "tabIndex" is rendered in the camelCase style and then ignored by the browser. I've tried adding the property "tabindex" to the <circletag in the jsx, but it was swallow by React and not rendered to the final component.
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
apologies just seeing this message now. Yes. The issue is resolved with the beta, rc & 16.1
Change:
Scheduler.flushAll(); expect(root).toMatchRenderedOutput('hello'); }); <ins> // Regression test for https://github.com/facebook/react/issues/15732 it('resets hooks when an error is thrown in the middle of a list of hooks', async () => { const {useEffect, useState} = React; class ErrorBoundary extends React.Component { state = {hasError: false}; static getDerivedStateFromError() { return {hasError: true}; } render() { return ( <Wrapper> {this.state.hasError ? 'Error!' : this.props.children} </Wrapper> ); } } function Wrapper({children}) { return children; } let setShouldThrow; function Thrower() { const [shouldThrow, _setShouldThrow] = useState(false); setShouldThrow = _setShouldThrow; if (shouldThrow) { throw new Error('Throw!'); } useEffect(() => {}, []); return 'Throw!'; } const root = ReactTestRenderer.create( <ErrorBoundary> <Thrower /> </ErrorBoundary>, ); expect(root).toMatchRenderedOutput('Throw!'); act(() => setShouldThrow(true)); expect(root).toMatchRenderedOutput('Error!'); }); </ins> });

Discussion:
I’ve seen the “rendered fewer hooks than expected” invariant a couple times now pointing at a component rendered as a part of an error boundary that just caught an error when that component does not use hooks at all. I’ve been able to fix this issue by un-commenting: I haven’t been able to produce a minimal test-case yet . I’m reporting anyway with the temporary fix that worked for me in case you have any insight on what a minimal test-case could be. I’ll update this issue if I keep running into the problem and I can create a minimal test-case.
I ran into the issue again and was able to produce a small repro: Pressing the “throw” button results in the invariant: With a component stack of: Which is weird since has no hooks!
Wanna look into fixing? Should be easy — there must be a missing call somewhere. Or maybe doesn't reset everything we need.
I looked into it, wrote a test, and discovered it’s fixed on master The test is broken on 16.8.6, I didn’t bother bisecting to find the commit that fixed it. PR for the test: .
I thought I was seeing this in 16.9, but it turns out we were on and , and both need to be updated for this to work.
Change:
if (config != null) { ref = config.ref === undefined ? null : config.ref; <del> key = config.key === undefined ? null : '' + config.key; </del> <ins> if (__DEV__) { warning( config.key !== null, 'createElement(...): Encountered component with a `key` of null. In ' + 'a future version, this will be treated as equivalent to the string ' + ''null'; instead, provide an explicit key or use undefined.' ); } // TODO: Change this back to `config.key === undefined` key = config.key == null ? null : '' + config.key; </ins> // Remaining properties are added to a new props object for (propName in config) { if (config.hasOwnProperty(propName) &&

Discussion:
In 0.11, the code assigned implicit keys to both children. In 0.12, it gives the error and renders only "foo", because the key is cast to a string in ReactElement before it gets checked against null in traverseAllChildren: I guess it's okay if this is intentional but it broke a part of KA in the upgrade. (cc
hm. Yea, this was intentional to ensure more stable types through out the system. I don't think null should be treated as a valid "non-value" to align it with defaultProps, default arguments and default values in destructuring. The intention of "null" is to symbolize a missing object. However, this can be of any type. It's weird that is coerced into . It should be left as . For refs, we expect them to become objects so it is valid to have there to represent a missing value. We have a two options: 1) Allow any value to be coerced to strings. 2) Throw on non-string values. 3) Don't coerce to string and start using maps as keys. E.g. Dates would become by reference instead of by value. would be treated as a key and would still be duplicate.
Maybe we can support meaning no key for a 0.12 with a warning, then drop support in 0.13? Just trying to avoid breaking things (that are impossible to grep for) without a warning. (I have no idea if we have other places in our code that do this by accident…)
They don't in prod though, right? I thought we had a fallback for duplicate values that would be essentially the same?
No, that code previously outputted and outputs just with 0.12. We ignore all children after the first with a given key.
oh. fine, warning for one version and then swap behavior. Want to send a PR?
Will do.
Change:
if (!styles.hasOwnProperty(styleName)) { continue; } <ins> if (__DEV__) { if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } } </ins> var styleValue = styles[styleName]; if (styleValue != null) { serialized += processStyleName(styleName) + ':';

Discussion:
We happen to "support" hyphenated keys to the style object on initial render (because we attempt to hyphenate camelcased keys) but those styles will never be updated on subsequent renders because we never attempt to unhyphenate. So we should warn when we see a hyphenated style.
Some browsers support assigning with hyphenated keys, but probably not all do.
AFAIK only Webkit does. (And I guess by association, Blink)
Perhaps another one for you!
OK
Sorry for the long delay, been busy. I'll try to do this today.
No problem, whenever you have time.
Curious: why do we not want to hyphenate names on subsequent updates, and instead show a warning? Because there should be “one way to do that”?
Yes, this matches our existing practice of requiring camel-cased attributes in general, which makes it easier to make warpper components that modify props in some way because you only need to look in one place to find the original value. In addition, you don't need to worry about what happens if someone were to specify both and in the same style block. (One last advantage: if the warnings happen only in the dev version, then there's no runtime cost in the production build.)
Do you think it's worth adding for the sake of providing a suggestive warning? (e.g. )
There you go! I also updated the docs about prefix, since it's not clear right now.
A warning would be very helpful, this just sucked up a lot of my time. If anyone is interested, chrome seems to handle hyphenated CSS props OK but FF doesn't
Change:
expect(a.getDOMNode().childNodes[0].id).toBe('two'); expect(a.getDOMNode().childNodes[1].id).toBe('one'); }); <ins> describe('with an undefined child', function () { it('should fail silently', function () { var a = React.renderComponent( <ReactTransitionGroup transitionName="yolo"> </ReactTransitionGroup>, container ); }); }); </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:
// register renderers that inject themselves later. hook.sub('renderer', ({renderer}) => { <del> registerRenderer(renderer); </del> <ins> registerRenderer(renderer, hook); </ins> updateRequiredBackends(); });

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:
warnedStyleNames[name] = true; warning( false, <del> 'Unsupported style property ' + name + '. Did you mean ' + camelizeStyleName(name) + '?' </del> <ins> 'Unsupported style property %s. Did you mean %s?', name, camelizeStyleName(name) </ins> ); };

Discussion:
Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks
Change:
import React from 'react'; import {isForwardRef} from 'react-is'; <del> import {warnAboutDeprecatedLifecycles} from 'shared/ReactFeatureFlags'; </del> import describeComponentFrame from 'shared/describeComponentFrame'; import getComponentName from 'shared/getComponentName'; import emptyObject from 'fbjs/lib/emptyObject'; import invariant from 'fbjs/lib/invariant'; <del> import lowPriorityWarning from 'shared/lowPriorityWarning'; </del> import shallowEqual from 'fbjs/lib/shallowEqual'; import checkPropTypes from 'prop-types/checkPropTypes'; <del> import warning from 'fbjs/lib/warning'; let didWarnAboutLegacyWillMount; let didWarnAboutLegacyWillReceiveProps; let didWarnAboutLegacyWillUpdate; let didWarnAboutUndefinedDerivedState; let didWarnAboutUninitializedState; let didWarnAboutLegacyLifecyclesAndDerivedState; if (__DEV__) { if (warnAboutDeprecatedLifecycles) { didWarnAboutLegacyWillMount = {}; didWarnAboutLegacyWillReceiveProps = {}; didWarnAboutLegacyWillUpdate = {}; } didWarnAboutUndefinedDerivedState = {}; didWarnAboutUninitializedState = {}; didWarnAboutLegacyLifecyclesAndDerivedState = {}; } </del> class ReactShallowRenderer { static createRenderer = 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:
'* put files on CDN', '* push changes to git repositories', '* publish npm module (`npm publish .`)', <del> '* publish gem (`gem push react-source-' + VERSION + '.gem`)', </del> '* announce it on FB/Twitter/mailing list', ].forEach(function(ln) { grunt.log.writeln(ln);

Discussion:
I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)