jiebi/CodeConvo huggingface dataset:
Change:
render() { instance = this; return ( <del> <> </del> <ins> <React.Fragment> </ins> <Yield value="first" /> {this.state.count} <Yield value="last" /> <del> </> </del> <ins> </React.Fragment> </ins> ); } }

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:
for (var i = 0; i < expectedFeatures.length; i++) { if (!expectedFeatures[i]) { <del> console.error( </del> <ins> warning( false, </ins> 'One or more ES5 shims expected by React are not available: ' + 'https://fb.me/react-warning-polyfills' );

Discussion:
Do we want to do this now? mentioned this but I forgot about it until this morning.
That would be nice but shouldn't be blocking. We can make that 0.15.
Change:
throwOnInvalidObjectType(returnFiber, newChild); } <ins> if (__DEV__) { if (!disableNewFiberFeatures && typeof newChild === 'function') { warnOnFunctionType(); } } </ins> if (!disableNewFiberFeatures && typeof newChild === 'undefined') { // If the new child is undefined, and the return fiber is a composite // component, throw an error. If Fiber return types are disabled,

Discussion:
When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.
Change:
deleteListener(this, propKey); } } else if (isCustomComponent(this._tag, nextProps)) { <del> if (propKey === CHILDREN) { nextProp = null; </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { DOMPropertyOperations.setValueForAttribute( getNode(this), propKey, nextProp ); </ins> } <del> DOMPropertyOperations.setValueForAttribute( getNode(this), propKey, nextProp ); </del> } else if (this._namespaceURI === DOMNamespaces.svg) { <del> DOMPropertyOperations.setValueForSVGAttribute( getNode(this), propKey, nextProp ); </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { DOMPropertyOperations.setValueForSVGAttribute( getNode(this), propKey, nextProp ); } </ins> } else if ( DOMProperty.properties[propKey] || DOMProperty.isCustomAttribute(propKey)) {

Discussion:
See for a basic example. I'm assuming there's some step in the new SVG code that we just need to remove the key if we consume it as a React prop.
Going to leave this open to ensure we block even though wrote fix before I finished submitting (do you ever sleep Dan!?)
I sleep incrementally. FWIW the fix is in
Change:
<ins> function Component(props) { let value; const object = { set value(v) { value = v; }, }; object.value = props.value; return <div>{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:
string displayName ``` <del> 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). </del> <ins> 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

Discussion:
The link to "JSX in depth" in the "displayName" section on the "Component Specs and Lifecycle" page points to This url is not correct, the correct url is:
Thanks! Fixed in . You can close this.
Change:
ReactFeatureFlags.debugRenderPhaseSideEffectsForStrictMode = false; React = require('react'); ReactNoop = require('react-noop-renderer'); <ins> ({Suspense} = React); </ins> }); function span(prop) {

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? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). 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: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0
Change:
var ReactCurrentOwner = require('ReactCurrentOwner'); var assign = require('Object.assign'); <ins> var warning = require('warning'); </ins> var canDefineProperty = require('canDefineProperty'); // The Symbol used to tag the ReactElement type. If there is no native Symbol

Discussion:
The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.
Change:
transformer: React.PropTypes.func, renderCode: React.PropTypes.bool, showCompiledJSTab: React.PropTypes.bool, <ins> showLineNumbers: React.PropTypes.bool, </ins> editorTabTitle: React.PropTypes.string },

Discussion:
is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !
Change:
var flattenChildren = require('flattenChildren'); var instantiateReactComponent = require('instantiateReactComponent'); var shouldUpdateReactComponent = require('shouldUpdateReactComponent'); <ins> var traverseAllChildren = require('traverseAllChildren'); var warning = require('warning'); function instantiateChild(childInstances, child, name) { // We found a component instance. var keyUnique = (childInstances[name] === undefined); if (__DEV__) { warning( keyUnique, 'flattenChildren(...): Encountered two children with the same key, ' + '`%s`. Child keys must be unique; when two children share a key, only ' + 'the first child will be used.', name ); } if (child != null && keyUnique) { childInstances[name] = instantiateReactComponent(child, null); } } </ins> /** * ReactChildReconciler provides helpers for initializing or updating a set of

Discussion:
Flattening children to an array is 20 times faster than flattening to an object. For long list of elements, this shows up on the initial render flame graphs as pretty hot.
Change:
); } }); <ins> PageOneContent = React.createFactory(PageOneContent); </ins> /** Application page two component. */ var PageTwoContent = 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:
expect(element.props).toEqual({foo:'56'}); }); <ins> it('treats a null key as omitted but warns', function() { spyOn(console, 'warn'); var element = React.createFactory(ComponentFactory)({ key: null, foo: '56' }); expect(element.type).toBe(ComponentClass); expect(element.key).toBe(null);  // as opposed to string 'null' expect(element.ref).toBe(null); expect(element.props).toEqual({foo:'56'}); expect(console.warn.argsForCall.length).toBe(1); expect(console.warn.argsForCall[0][0]).toContain( 'will be treated as equivalent to the string 'null'' ); }); </ins> it('preserves the context on the element', function() { var Component = React.createFactory(ComponentFactory); var element;

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:
return function(done) { spawn( <del> process.execPath, </del> <ins> path.join('node_modules', '.bin', 'flow' + extension), </ins> [ <del> path.join('node_modules', '.bin', 'flow' + extension), </del> 'check', '.', ],

Discussion:
"npm run lint" fails on Windows, at least Windows 7. Error: Screenshot: ! I found this but I couldn't fix it anyway. What might it be?
I encountered the same problem. If you look into the code in , you'll find the following code: which spawns a new process using the command "node node_modules.bin .". The command tries to interpret a batch file using node. However node can interpret js files only. That's why there's a SyntaxError. A change like this should work as expected:
Would you like to send a PR if you have a working fix?
Sure. I'll fix the same problem in gulp flow task too.
I rolled this into
Change:
this.getName() || 'a component' ); warning( <ins> !inst.getDefaultProps || inst.getDefaultProps.isReactClassApproved, 'getDefaultProps was defined on %s, a plain JavaScript class. ' + 'This is only supported for classes created using React.createClass. ' + 'Use a static property to define defaultProps instead.', this.getName() || 'a component' ); warning( </ins> !inst.propTypes, 'propTypes was defined as an instance property on %s. Use a static ' + 'property to define propTypes instead.',

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:
| `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:
expect(root).toMatchRenderedOutput('FooBar'); expect(ref.current).not.toBe(null); }); <ins> // Regression test for #14310 it('supports defaultProps defined on the memo() return value', async () => { const Add = React.memo(props => { return props.inner + props.outer; }); Add.defaultProps = { inner: 2, }; const LazyAdd = lazy(() => fakeImport(Add)); const root = ReactTestRenderer.create( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, { unstable_isConcurrent: true, }, ); expect(root).toFlushAndYield(['Loading...']); expect(root).toMatchRenderedOutput(null); // Mount await Promise.resolve(); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update (shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update (shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update (explicit props) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} inner={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); // Update (explicit props, shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} inner={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('3'); }); it('merges defaultProps in the correct order', async () => { let Add = React.memo(props => { return props.inner + props.outer; }); Add.defaultProps = { inner: 100, }; Add = React.memo(Add); Add.defaultProps = { inner: 2, outer: 0, }; const LazyAdd = lazy(() => fakeImport(Add)); const root = ReactTestRenderer.create( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, { unstable_isConcurrent: true, }, ); expect(root).toFlushAndYield(['Loading...']); expect(root).toMatchRenderedOutput(null); // Mount await Promise.resolve(); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); }); </ins> });

Discussion:
With this: If I render again after it resolves, it won't get the default prop value. This is a bug.