jiebi/CodeConvo huggingface dataset:
Change:
* ${license} */ <del> 'use strict'; </del> ${source}`; },

Discussion:
React version: 16.13.1 Even though React's code (and other packages like ReactDOM) are wrapped in a IIFE, the code applies an entire script strict mode by placing a 'use strict' before any other statement: MDN mentions the "trap" of concatenating conflicting scripts strict mode when using the entire script strict mode, see . a file with React's code at the top and concat an expression that causes a 'use strict' violation this file as a script tag Link to code example: (Scroll to bottom of file to see the concatenated expressions) 'use strict' mode is enforced on all the concatenated code, even if it was not defined as 'strict'. As a result, 'strict' violations at the other concatenated libraries will now throw errors (instead of silencing them), causing the script to stop execution. Global 'use strict' should not be used and should be replaced with function scope strict mode (which already exist in some cases of React IIFE bundles code wrappers, like ). - Always wrap UMD bundles in IIFEs - options for the build script stating - explained (vs )
Thanks for the super quick handling!
Change:
"uglifyify": "^3.0.1" }, "devEngines": { <del> "node": "4.x || 5.x", </del> <ins> "node": "4.x || 5.x || 6.x", </ins> "npm": "2.x || 3.x" }, "commonerConfig": {

Discussion:
The does not accept a node engine of version 6.x I don't think that there is some regressions caused by Node v6, so it should be okay?
there is in npm package.
My bad, -- I meant the , you cannot without getting an error with Node v6.0.0.
Change:
'Can only set one of `children` or `props.dangerouslySetInnerHTML`.' ); invariant( <del> props.dangerouslySetInnerHTML.__html != null, </del> <ins> typeof props.dangerouslySetInnerHTML === 'object' && '__html' in props.dangerouslySetInnerHTML, </ins> '`props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`. ' + 'Please visit https://fb.me/react-invariant-dangerously-set-inner-html ' + 'for more information.'

Discussion:
In following JSX fragment I should guarantee that will never be or : Otherwise throws an error although construction is correct: Should instead of check for ?
Someone else mentioned this being surprising to me too.
I've been experiencing the same issues recently
As far as I understand it, the idea is that is basically the equivalent of a HTML-type. You're not meant to use it as , but as so that you cannot accidentally pass unsafe data. So should be or , in this model it does not make sense to have .
That doesn't mean that people won't write it as – doing so is even pretty reasonable if you're careful about naming your vars/props and do .
The simplest workaround is to coerce into an empty string with . +1 for having React do this internally.
Got surprised by this today, upgrading from to . Was it a "bug" in (i.e. it shouldn't have accepted ), or is it a bug in ? Anyway, will use as suggested by just wanted to point out that it seemed to "work" in .
Change:
expect(isTagStackValid(['table', 'tr'])).toBe(false); expect(isTagStackValid(['div', 'ul', 'li', 'div', 'li'])).toBe(false); expect(isTagStackValid(['div', 'html'])).toBe(false); <ins> expect(isTagStackValid(['body', 'body'])).toBe(false); expect(isTagStackValid(['svg', 'foreignObject', 'body', 'p'])).toBe(false); </ins> }); });

Discussion:
(I am using 15rc2 because I need all the svg tags) I am rendering a foreignObject svg tag. According to I put body tag inside that tag and then whatever html I want in there. renderToString on the server leaves the body tag in place, and gives it a react-dataid. However when rendered on the client that body tag is removed. So when I look at the live elements, the body inside foreignObjects is gone, along with it's data-reactid. The server source ( ie view page source ) shows that the body tag was rendered with the missing react-dataid. The result is that you get a “Invariant Violation: Unable to find element with ID XX”, when the page updates, and somethings don't work. Removing the body from inside the foreignObject tag seems to solve the problem, but I don't know if that is an "OK" solution to this or if that body tag is necessary in some scenarios. But in either case this seems to be a scenario where server rendering results in different DOM/HTML then client rendering. Is this a problem, or is the body tag not supposed to there anyway? Todd
We never render the on the client side - only on the server side. Can you provide a jsfiddle that demonstrates the invariant violation?
Thanks for tracking down more specifically. Could be that browsers don't actually support that body usage? Or when actually parsed from markup, the body node doesn't exist (which seems likely and matches up with what we see in other situations where the browser changes markup). I won't have a chance to look into this more for a few days - it might be best to just use your alternate approach for now.
I can remove the body tag. It seems to work ok with out it. Whats clear at this point is that if the server sends the body tag, it is not parsed into a DOM node, at least on mac with Chrome and Safari. That results in the error, since the data-reactid for the body is missing. IE doesn't support foreignObject so its not relevant there. MS Edge does, but I haven't tested it.
It seems so.

Even without React, I can’t get Chrome (or Firefox for that matter) to make an actual node: <img width="261" alt="screen shot 2016-03-17 at 15 19 30" src=""
FWIW, does manage to put one in:
Sounds like we should add this to : we should warn and tell you you can't put a body tag inside foreignObject. We don't do anything much for SVG there right now; probably the ideal solution would be to pass the namespace info down too, then we can distinguish SVG and HTML tags with the same name (like title), then make sure the contents of a SVG tag are appropriate HTML tags. Not sure which HTML tags are and aren't allowed but it might be detailed in the HTML5 spec at
Can I take this one?
please do :-)
Change:
Let's call the callback from the `CommentForm` when the user submits the form: <del> ```javascript{6} </del> <ins> ```javascript{10} </ins> // tutorial18.js var CommentForm = React.createClass({ handleSubmit: function(e) {

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? In shallow renderer, The returned callback from is not the same one between two rerendering even though the dependencies are the same. But will work as expected. For example, the following test won't work: If returned the same callback between two rendering (I think) the assertion should pass. but the same (almost) logic will work with , in the shallow renderer test suite (See ). 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 created a branch in and you can run the failed shallow renderer test in . What is the expected behavior? should return the memoized callback when the dependencies unchanged even in shallow renderer. I tried to look into this and I found out that in shallow renderer just returns the original callback argument (See ) but will compare the dependencies between rendering. I'm not sure if it's intended (So it's expected that will not memoize callback in shallow renderer). If it's triaged as a bug I'm glad to send a pr for this :) Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? react
yup, this looks like a miss on our part. Would you like to send a PR? :)
thanks for reply :-) I'd try to make a PR in a few days.
I don't think it's a miss on our part. It was an intentional decision since it's mostly an optimization, and unclear why it would be important for shallow rendering to do that. Can you explain why it matters?
It’s important for shallow rendering to match production as much as possible, since shallow rendering is a testing tool.
Agree to Even it's optimization I think there might be still case that we want to make sure we've really do the optimization (though not guaranteed in production) in code.
Is this still open to be worked on?

For this code and statement: Isn't it creating two instances, and then rendering each of them independently? AFAIK this is not two renderings of the same, but instead two different elements. If I have a component rendered in different places those are independent of each other. They keep the same callback between re-renders, but not across all the instances.
The shallow renderer has moved to If this is still relevant, please feel free to file this issue there. Thanks!
Change:
<ins> <h1><a href="/react{{ page.url }}">{{ page.title }}</a></h1> <p class="meta">{{ page.date | date_to_string }} by {{ page.author }}</p> <div id="post"> {% if content != '' %} {{ content }} {% else %} {{ page.content }} {% endif %} </div> </ins>

Discussion:
I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.
Change:
<ins> // Do not delete or move this file. // Many fiddles reference it so we have to keep it here. (function() { var tag = document.querySelector( 'script[type="application/javascript;version=1.7"]' ); if (!tag || tag.textContent.indexOf('window.onload=function(){') !== -1) { alert('Bad JSFiddle configuration, please fork the original React JSFiddle'); } tag.setAttribute('type', 'text/babel'); tag.textContent = tag.textContent.replace(/^//<![CDATA[/, ''); })(); </ins>  No newline at end of file

Discussion:
no longer works, and this causes all old fiddles like to break. We should fix it.
I've also noticed fiddles[1][2] linking to being broken. I assume they were/are linking to the same place, but it's something to keep in mind. [1] [2] (All the examples seem to be broken)
It will take a few minutes to deploy the site but hopefully this should be fixed now.
Unfortunately Recharts examples are broken because they don't specify the React version. So they accidentally "updated" to React 16 that has different file names. We could potentially fix this on our side by providing a fallback. But then, one of the most commonly used builds () doesn't even exist anymore. So this has to be fixed on their side anyway.
Change:
componentWillReceiveProps: function(nextProps) { if (!nextProps.children && this.props.children) { this.savedChildren = this.props.children; <ins> } else if (nextProps.children && !this.props.children) { // We're being told to re-add the child.  Let's stop leaving! if (this.isMounted()) { var node = this.getDOMNode(); var className = this.props.name; CSSCore.removeClass(node, className + '-leave'); CSSCore.removeClass(node, className + '-leave-active'); if (this.props.enter) { CSSCore.addClass(node, className + '-enter'); CSSCore.addClass(node, className + '-enter-active'); } } </ins> } },

Discussion:
Please see: and do the following: 'Toggle' to make the list-item fade into view. -click/Spam-click the 'Toggle' button again to make the item fade-out of view. 'Toggle' again to try to make the component come back into view. You'll see that the item doesn't come back! If you check the HTML, you can see that the list-item is still there, with the class name "example-leave example-leave-active". I suspect that React should reverse the animation elegantly in the case of the same component being re- in the render function during a leave transition.
Thanks, I was going to point you to but I see that you're the author of it!
Hehe, I thought perhaps it'd be best if I made a proper Issue (with JSFiddle example!) rather than just rudely posting Pull Requests! :)
Change:
color: var(--color-text); } <ins> .Profiler, .Profiler * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); } </ins> .LeftColumn { display: flex; flex-direction: column;

Discussion:
I don't see the selection at all. My version is 4.5.0. I think this regressed. <img width="266" alt="Screenshot 2020-03-11 at 23 40 37" src="https://user-"
This is interesting. The extension seems to have a shorter toolbar height than I would expect, which is clipping the current index. Here's what the test harness/shell looks like: <img width="437" alt="Screen Shot 2020-03-11 at 6 11 50 PM" src="https://user-"
Looks like something is going wrong with the relative height of the list items in the extension. Works fine in Chrome but it's overflowing in the extension.
Ah, it looks like the style isn't cascading correctly in the extension.
I think this probably regressed with , because the extension uses portals to mount (so they don't get mounted underneath of the class).
Yay! Fixed. <img width="369" alt="Screen Shot 2020-03-11 at 6 35 52 PM" src="https://user-"
Change:
visitor: { CallExpression: function(path, file) { <del> if (file.filename.indexOf('shared/assign') !== -1) { </del> <ins> if (/shared(/|)assign/.test(file.filename)) { </ins> // Don't replace Object.assign if we're transforming shared/assign return; }

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: Current main branch the repository from the main branch node and yarn (node version: 16.14.0, yarn version: 1.22.17, JDK version: tried both 11 and 17) yarn yarn build <!-- 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. --Error message : <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --No error messages from rollup. Success in yarn build.
If rollup is crashing during the build process, that's a rollup problem.
Yes, that was what my colleagues and I are thinking too. Then shouldn't something change related to Rollup, like going back to the previous version of code, or another way to resolve the error in the react project?
Exactlly it's the problem of Rollup and already fix it two years ago. See
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Change:
}, isDOMComponent: function(inst) { <del> // TODO: Fix this heuristic. It's just here because composites can currently // pretend to be DOM components. </del> return !!(inst && inst.nodeType === 1 && inst.tagName); },

Discussion:
The function isn't quite working for me anymore after upgrading from 0.14-rc1 and 0.14. The error stack looks something like this:
Can you post a minimal repro case please?
The minimal repro for me is this: If I use an element -- I get the error reported above. If I use a element -- there is no error. I tried dropping this as a Jest test in the React source code -- but it passed. However, running this exact same test in my local project -- it fails. I've confirmed that all React libs are 0.14. Could there be some kind of build process that's causing the issue? The line that fails is this when is the element.
Sounds like what mentioned here:
Indeed. Looks like this is the same issue. I hope you can push that out fix in 0.14.1 soon as this is a blocking issue for my team for upgrading to 0.14. Thanks for the fast response.
We'll try. In the meantime, you could copy the definition from here since it doesn't rely on any React internals:
Change:
--- id: tutorial-ja-JP title: チュートリアル <ins> permalink: tutorial-ja-JP.html </ins> prev: getting-started-ja-JP.html next: thinking-in-react-ja-JP.html ---

Discussion:
At gh-pages branch, there are and files. I think those file name must be and .
Thanks! I just pushed the change to the stable branch so this should be updated on the site and in the gh-pages branch as soon as it builds.
Thanks!
Change:
CSSTransitionGroup: { module: 'ReactCSSTransitionGroup', name: 'css-transition-group', <ins> docs: 'animation', </ins> }, LinkedStateMixin: { module: 'LinkedStateMixin', name: 'linked-state-mixin', <ins> docs: 'two-way-binding-helpers', </ins> }, Perf: { module: 'ReactDefaultPerf', name: 'perf', <ins> docs: 'perf', </ins> }, PureRenderMixin: { module: 'ReactComponentWithPureRenderMixin', name: 'pure-render-mixin', <ins> docs: 'pure-render-mixin', </ins> }, TestUtils: { module: 'ReactTestUtils', name: 'test-utils', <ins> docs: 'test-utils', </ins> }, TransitionGroup: { module: 'ReactTransitionGroup', name: 'transition-group', <ins> docs: 'animation', </ins> }, cloneWithProps: { module: 'cloneWithProps', name: 'clone-with-props', <ins> docs: 'clone-with-props', </ins> }, createFragment: { module: 'ReactFragment', method: 'create', name: 'create-fragment', <ins> docs: 'create-fragment', </ins> }, shallowCompare: { module: 'shallowCompare',

Discussion:
Follow-up for : The react-addons-* packages should have a entry in their files.
Change:
*/ function transformReact(source, options) { // TODO: just use react-tools <ins> options = options || {}; </ins> var visitorList; <del> if (options && options.harmony) { </del> <ins> if (options.harmony) { </ins> visitorList = visitors.getAllVisitors(); } else { visitorList = visitors.transformVisitors.react; } return transform(visitorList, source, { <del> sourceMap: supportsAccessors </del> <ins> sourceMap: supportsAccessors && options.sourceMap </ins> }); }

Discussion:
This is a tricky issue, so I'll do my best to explain: I've been using the to build my React app using AMD. I've been using a of React (with ), which is based off of master. Until recently, everything was working fine. But since , I've been unable to create optimized builds using the plugin. At first, I assumed it was an issue with the plugin, but it seems that the offending line is the changed function: Until this change, wasn't forced on, and things worked just fine. With this change, it's no longer possible to build in an AMD environment, as errors out with: My best guess is that the isn't being correctly loaded (although it is included ), but I don't know enough about Browserify to debug this. Hoping someone else can take a look and find out what's going on. (in the meantime, I suppose I'll update my branch to undo the change that set )
is this still happening for you?
just updated to v0.9.0, and yep: Unfortunately still having to maintain my own branch :(
I have the same issue.
thanks for tracking this issue down. I was trying to update React in and was puzzled by this. I will disable it manually in the modified provides.
Change:
} } <ins> var testFunc = function testFn() {}; warning( (testFunc.name || testFunc.toString()).indexOf('testFn') !== -1, 'It looks like you're using a minified copy of the development build ' + 'of React. When deploying React apps to production, make sure to use ' + 'the production build which skips development warnings and is faster. ' + 'See https://fb.me/react-minification for more details.' ); </ins> // If we're in IE8, check to see if we are in compatibility mode and provide // information on preventing compatibility mode var ieCompatibilityMode =

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:
); ReactShallowRenderer.prototype.render = function(element, context) { <ins> if (!context) { context = emptyObject; } </ins> var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(); this._render(element, transaction, context); ReactUpdates.ReactReconcileTransaction.release(transaction);

Discussion:
I am trying to render a component using the preliminary shadow renderer support in TestUtils. A simple reproducible test case of my issue is this When I run this in my Jest test, I get: It looks like this error is thrown whenever the component being rendered has . I thought perhaps the context was required (although I haven't had any problems omitting it in my actual app), but even when using I get the same exception.
I think this is a known issue with shallow rendering. cc
thanks for the report. Context isn't meant to be supported with shallow rendering (i.e., we haven't tested it), but it looks like you may be able to work around this problem by passing an object as the second argument to : it looks like an additional argument was to the shallow rendering API in . What was the thinking here? Can we default this to an empty object?
Thanks, the workaround works great. And I see you posted a fix as well so looking forward to that.
Change:
draggable: null, encType: null, form: MUST_USE_ATTRIBUTE, <ins> formAction: MUST_USE_ATTRIBUTE, formEncType: MUST_USE_ATTRIBUTE, formMethod: MUST_USE_ATTRIBUTE, </ins> formNoValidate: HAS_BOOLEAN_VALUE, <ins> formTarget: MUST_USE_ATTRIBUTE, </ins> frameBorder: MUST_USE_ATTRIBUTE, headers: null, height: MUST_USE_ATTRIBUTE,

Discussion:
Docs here: And those ones taged as HTML5 are not in the list of supported tags:
, are in there. is handled at run time. The others are missing.
It seems autoFocus is not supported on server side rendering
The property should add the attribute to the html input element too. This is especially useful if you decide to do server-side rendering only. There shouldn’t be a conflict with the current JS code that handles auto focus on unsupported browsers.