jiebi/CodeConvo huggingface dataset:
Change:
The examples in the React repository are declared a bit differently than a third-party renderer would be. In particular, the `HostConfig` object mentioned above is never explicitly declared, and instead is a *module* in our code. However, its exports correspond directly to properties on a `HostConfig` object you'd need to declare in your code: * [React ART](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactART.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactARTHostConfig.js) <del> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOMHostConfig.js) </del> <ins> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom-bindings/src/client/ReactDOMHostConfig.js) </ins> * [React Native](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeRenderer.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeHostConfig.js) If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving. If you have more questions please file an issue and we’ll try to help!

Discussion:
<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: main branch "" in " and its " <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --The page is 404. The page should exist.
Fixed by
Change:
} }); <ins> TestComponentWithReverseSpec = React.createClass({ render: function() { return <div />; }, componentDidMount: function() { this.props.listener('Component didMount'); }, mixins: [MixinBWithReverseSpec, MixinC, MixinD] }); </ins> TestComponentWithPropTypes = React.createClass({ mixins: [MixinD], propTypes: {

Discussion:
Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.
Change:
// For quickly matching children type, to test if can be treated as content. var CONTENT_TYPES = {'string': true, 'number': true}; <del> var CHILDREN = keyOf({children: null}); </del> var STYLE = keyOf({style: null}); var HTML = keyOf({__html: null}); <ins> var RESERVED_PROPS = { children: null, dangerouslySetInnerHTML: null, suppressContentEditableWarning: null, }; </ins> function getDeclarationErrorAddendum(internalInstance) { if (internalInstance) {

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:
* The result should be HTML-escaped before insertion into the DOM. * * @param {object} styles <ins> * @param {ReactDOMComponent} component </ins> * @return {?string} */ <del> createMarkupForStyles: function(styles) { </del> <ins> createMarkupForStyles: function(styles, component) { </ins> var serialized = ''; for (var styleName in styles) { if (!styles.hasOwnProperty(styleName)) {

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:
expect(/style=".*"/.test(root.innerHTML)).toBe(false); }); <ins> it('should warn when using hyphenated style names', function() { spyOn(console, 'warn'); expect(CSSPropertyOperations.createMarkupForStyles({ 'background-color': 'crimson' })).toBe('background-color:crimson;'); expect(console.warn.argsForCall.length).toBe(1); expect(console.warn.argsForCall[0][0]).toContain('backgroundColor'); }); it('should warn when updating hyphenated style names', function() { spyOn(console, 'warn'); var root = document.createElement('div'); var styles = { '-ms-transform': 'translate3d(0, 0, 0)', '-webkit-transform': 'translate3d(0, 0, 0)' }; React.renderComponent(<div />, root); React.renderComponent(<div style={styles} />, root); expect(console.warn.argsForCall.length).toBe(2); expect(console.warn.argsForCall[0][0]).toContain('msTransform'); expect(console.warn.argsForCall[1][0]).toContain('WebkitTransform'); }); </ins> });

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:
React = require('react'); ReactDOM = require('react-dom'); ReactDOMServer = require('react-dom/server'); <del> ReactDOMFeatureFlags = require('ReactDOMFeatureFlags'); </del> ReactTestUtils = require('react-dom/test-utils'); });

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:
} else { if (propKey === STYLE) { if (propValue) { <ins> if (__DEV__) { // See `_updateDOMProperties`. style block this._previousStyle = propValue; } </ins> propValue = this._previousStyleCopy = assign({}, props.style); } propValue = CSSPropertyOperations.createMarkupForStyles(propValue);

Discussion:
Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.
Change:
require('jstransform/visitors/es7-spread-property-visitors'); var react = require('./transforms/react'); var reactDisplayName = require('./transforms/reactDisplayName'); <ins> var reservedWords = require('jstransform/visitors/reserved-words-visitors'); </ins> /** * Map from transformName => orderedListOfVisitors.

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:
<ins> ## Input ```javascript function Component({ value }) { const object = { get value() { return value; }, }; return <div>{object.value}</div>; } export const FIXTURE_ENTRYPOINT = { fn: foo, params: [{ value: 0 }], sequentialRenders: [{ value: 1 }, { value: 2 }], }; ``` ## Error ``` 1 | function Component({ value }) { 2 |   const object = { > 3 |     get value() { |     ^^^^^^^^^^^^^ > 4 |       return value; | ^^^^^^^^^^^^^^^^^^^ > 5 |     }, | ^^^^^^ Todo: (BuildHIR::lowerExpression) Handle get functions in ObjectExpression (3:5) 6 |   }; 7 |   return <div>{object.value}</div>; 8 | } ``` </ins>  No newline at end of file

Discussion:
[ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization) [X] babel-plugin-react-compiler (build issue installing or using the Babel plugin) [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin) [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script) In the above code, doubleValue uses get syntax, and after compilation, it loses the keyword and becomes an ordinary function. In this case the compiler should skip compilation until this syntax is supported. I know that some syntaxes are currently unsupported by the react compiler, can we know what syntaxes are currently unsupported and in process? Every time 0-rc--
Thanks for posting, this is a bug. We have not support for get/set syntax but looks like we missed a todo for this.
Let’s close when the associated PR lands
Oops my bad, I didn't read
Change:
'use strict'; <ins> var DisabledInputUtils = require('DisabledInputUtils'); </ins> var LinkedValueUtils = require('LinkedValueUtils'); var ReactDOMComponentTree = require('ReactDOMComponentTree'); var ReactUpdates = require('ReactUpdates');

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:
```javascript{3-5} render: function() { return ( <del> <ReactCSSTransitionGroup transitionName="example" transitionAppear={true}> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}> </ins> <h1>Fading at Initial Mount</h1> </ReactCSSTransitionGroup> );

Discussion:
When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..
Change:
if (parseHookNames) { if ( inspectedElement !== null && <del> inspectedElement.type === ElementTypeFunction && </del> inspectedElement.hooks !== null && loadHookNamesFunction !== null ) {

Discussion:
The named hooks cache returns The first (mixed array of string and null) indicates an overall success, even if some names couldn't be inferred. The second indicates an error (e.g. couldn't locate or load source map). In the event of the 2nd response type, the UI currently does nothing (falls back to default) but we should show an error badge (maybe a disabled but red icon with a tooltip saying there was an error) since it's a confusing user experience to just do nothing.
Change:
// warns when classic properties are defined on the instance, // but does not invoke them. var getInitialStateWasCalled = false; <ins> var getDefaultPropsWasCalled = false; </ins> class ClassicProperties extends React.Component { contextTypes = {}; propTypes = {}; <ins> getDefaultProps() { getDefaultPropsWasCalled = true; return {}; } </ins> getInitialState() { getInitialStateWasCalled = true; return {};

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:
}); describe('inline errors and warnings', () => { <del> // Some actions require the Fiber id. // In those instances you might want to make assertions based on the ID instead of the index. function getErrorsAndWarningsForElement(id: number) { const index = ((store.getIndexOfElementID(id): any): number); return getErrorsAndWarningsForElementAtIndex(index); } </del> async function getErrorsAndWarningsForElementAtIndex(index) { const id = ((store.getElementIDAtIndex(index): any): number); <ins> if (id == null) { throw Error(`Element at index "${index}"" not found in store`); } </ins> let errors = null; let warnings = null;

Discussion:
the block to inspect "Component" in DevTools : "Could not inspect element with id 5" Originally reported in https://user- Every time
Here's another Chrome extension build with the fix from :
Everything fixed. Awesome :+1:
FYI just published as 4.13.4
Change:
}); }); <ins> it('inspecting nested renderers should not throw', async () => { // Ignoring react art warnings spyOn(console, 'error'); const ReactArt = require('react-art'); const ArtSVGMode = require('art/modes/svg'); const ARTCurrentMode = require('art/modes/current'); store.componentFilters = []; ARTCurrentMode.setCurrent(ArtSVGMode); const {Surface, Group} = ReactArt; function Child() { return ( <Surface width={1} height={1}> <Group /> </Surface> ); } function App() { return <Child />; } await utils.actAsync(() => { legacyRender(<App />, document.createElement('div')); }); expect(store).toMatchInlineSnapshot(` [root] ▾ <App> ▾ <Child> ▾ <Surface> <svg> [root] <Group> `); const inspectedElement = await inspectElementAtIndex(4); expect(inspectedElement.owners).toMatchInlineSnapshot(` Array [ Object { "displayName": "Child", "hocDisplayNames": null, "id": 3, "key": null, "type": 5, }, Object { "displayName": "App", "hocDisplayNames": null, "id": 2, "key": null, "type": 5, }, ] `); }); </ins> describe('error boundary', () => { it('can toggle error', async () => { class LocalErrorBoundary extends React.Component<any> {

Discussion:
Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via
Change:
return {default: result}; } <ins> it('warns when giving a ref (simple)', async () => { // This test lives outside sharedTests because the wrappers don't forward // refs properly, and they end up affecting the current owner which is used // by the warning (making the messages not line up). function App() { return null; } App = React.memo(App); function Outer() { return <App ref={() => {}} />; } ReactNoop.render(<Outer />); expect(ReactNoop.flush).toWarnDev([ 'Warning: Function components cannot be given refs. Attempts to access ' + 'this ref will fail.', ]); }); it('warns when giving a ref (complex)', async () => { // defaultProps means this won't use SimpleMemoComponent (as of this writing) // SimpleMemoComponent is unobservable tho, so we can't check :) function App() { return null; } App.defaultProps = {}; App = React.memo(App); function Outer() { return <App ref={() => {}} />; } ReactNoop.render(<Outer />); expect(ReactNoop.flush).toWarnDev([ 'Warning: Function components cannot be given refs. Attempts to access ' + 'this ref will fail.', ]); }); </ins> // Tests should run against both the lazy and non-lazy versions of `memo`. // To make the tests work for both versions, we wrap the non-lazy version in // a lazy function component.

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