jiebi/CodeConvo huggingface dataset:
Change:
'a valid ReactComponent.' ); }); <ins> it('allows setState in componentWillMount without using DOM', function() { var Component = React.createClass({ componentWillMount: function() { this.setState({text: 'hello, world'}); }, render: function() { return <div>{this.state.text}</div>; } }); ReactReconcileTransaction.prototype.perform = function() { // We shouldn't ever be calling this on the server throw new Error('Browser reconcile transaction should not be used'); }; var markup = ReactServerRendering.renderComponentToString( <Component /> ); expect(markup.indexOf('hello, world') >= 0).toBe(true); }); </ins> }); });

Discussion:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!
Change:
invariant( one[key] === undefined, 'mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: %s', </del> <ins> 'Tried to merge two objects with the same key: `%s`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.', </ins> key ); one[key] = value;

Discussion:
Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.
Change:
.openProfiler(); } <del> const link = $('#rn-help-link'); link.addEventListener('click', event => { event.preventDefault(); require('electron').shell.openExternal(link.href); }); const $localhost = $("#localhost"); $localhost.innerText = `<script src="${server}"></` + 'script>'; $localhost.addEventListener('click', selectAllAndCopy); $localhost.addEventListener('focus', selectAllAndCopy); const $byIp = $("#byip"); $byIp.innerText = `<script src="${serverIp}"></` + 'script>'; $byIp.addEventListener('click', selectAllAndCopy); $byIp.addEventListener('focus', selectAllAndCopy); </del> <ins> function attachListeners() { const link = $('#rn-help-link'); link.addEventListener('click', event => { event.preventDefault(); require('electron').shell.openExternal(link.href); }); const $localhost = $("#localhost"); $localhost.innerText = `<script src="${server}"></` + 'script>'; $localhost.addEventListener('click', selectAllAndCopy); $localhost.addEventListener('focus', selectAllAndCopy); const $byIp = $("#byip"); $byIp.innerText = `<script src="${serverIp}"></` + 'script>'; $byIp.addEventListener('click', selectAllAndCopy); $byIp.addEventListener('focus', selectAllAndCopy); const $profiler = $("#profiler"); $profiler.addEventListener('click', openProfiler); }; </ins> <del> const $profiler = $("#profiler"); $profiler.addEventListener('click', openProfiler); </del> <ins> // Initially attach the listeners attachListeners(); </ins> let devtools; try {

Discussion:
Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!
Change:
}); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> var result = shallowRenderer.getRenderOutput(); expect(result.type).toBe('div'); expect(result.props.children).toEqual([

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:
} break; case 'SELECT_PREVIOUS_ELEMENT_WITH_ERROR_OR_WARNING_IN_TREE': { <del> if (store.errorCount === 0 && store.warningCount === 0) { </del> <ins> const elementIndicesWithErrorsOrWarnings = store.getElementsWithErrorsAndWarnings(); if (elementIndicesWithErrorsOrWarnings.length === 0) { </ins> return state; } <del> const elementIndicesWithErrorsOrWarnings = store.getElementsWithErrorsAndWarnings(); </del> let flatIndex = 0; if (selectedElementIndex !== null) { // Resume from the current position in the list.

Discussion:
Unfortunately I don't know how to reproduce this bug. It was just logged to Sentry. It seems like there's a logic bug here though: If is null or is empty, then would be 0 still– and this statement would result in an undefined entry: Only once react-devtools-inline 24.4 Error: can't access property "id", n is undefined No response No response
Not sure if will fix your issue. Let me know if you can get a repro!
Change:
): FiberRoot | null { checkForNestedUpdates(); <ins> if (__DEV__) { if (isRunningInsertionEffect) { console.error('useInsertionEffect must not schedule updates.'); } } </ins> const root = markUpdateLaneFromFiberToRoot(fiber, lane); if (root === null) { return null;

Discussion:
Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?
Change:
* renders a div with a single child surrounded by whitespace with client render on top of bad server markup * renders >,<, and & as single child with client render on top of bad server markup * renders >,<, and & as multiple children with client render on top of bad server markup <del> * throws when rendering a string component with clean client render * throws when rendering a string component with client render on top of bad server markup * throws when rendering an undefined component with clean client render * throws when rendering an undefined component with client render on top of bad server markup * throws when rendering a number component with clean client render * throws when rendering a number component with client render on top of bad server markup </del> * renders an input with a value and an onChange with client render on top of bad server markup * renders an input with a value and readOnly with client render on top of bad server markup * renders an input with a value and no onChange/readOnly with client render on top of bad server markup

Discussion:
I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.
Change:
expect(console.error.argsForCall.length).toBe(0); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('identifies valid elements', function() { var Component = React.createClass({ render: 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:
); } }); <ins> JQueryMobileFooter = React.createFactory(JQueryMobileFooter); </ins> /** jQuery Mobile header component. */ var JQueryMobileHeader = 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:
props = assign({}, props, {selected: this.state.selected}); } <del> return option(props, this.props.children); </del> <ins> var content = ''; // Flatten children and warn if they aren't strings or numbers; // invalid types are ignored. ReactChildren.forEach(this.props.children, function(child) { if (child == null) { return; } if (typeof child === 'string' || typeof child === 'number') { content += child; } else { warning( false, 'Only strings and numbers are supported as <option> children.' ); } }); return option(props, content); </ins> } });

Discussion:
If the contents of the element is constructed in special way, it breaks React on component update with "Unable to find element" error. Here's an example of method body: Here's working jsfiddle (with React 0.12.0): Adding to option props fixes the issue.
React separates the 's children with s. In HTML only text is allowed there and the browser handles it gracefully by removing the s. On the next render React tries to change those s, but can't find them. A workaround is to give a string to the :
Thanks for explaining this. In such case probably the best solution would be to extend error explanation with information about "option" elements (behind "table" etc).
Yea, we should probably do some checks in our ReactDOMOption wrapper and not allow anything but text as children.
Just hit this
This can be fixed by using ReactChildren.forEach in ReactDOMOption to flatten the children before passing it to the raw HTML component. Strings and numbers get concatted together; other elements should be skipped and log a warning for invalid children.
Change:
case 'rt': return impliedEndTags.indexOf(parentTag) === -1; <ins> case 'body': </ins> case 'caption': case 'col': case 'colgroup':

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 url = sourceMappingURLs[i].split('=')[1]; <del> if (ABSOLUTE_URL_REGEX.test(url)) { const baseURL = url.slice(0, url.lastIndexOf('/')); url = `${baseURL}/${url}`; if (!isValidUrl(url)) { throw new Error(`Invalid source map URL "${url}"`); } } else if (!url.startsWith('/')) { </del> <ins> if (!url.startsWith('http') && !url.startsWith('/')) { </ins> // Resolve paths relative to the location of the file name const lastSlashIdx = runtimeSourceURL.lastIndexOf('/'); if (lastSlashIdx !== -1) {

Discussion:
This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).
Change:
isDOMComponent: function(inst) { // TODO: Fix this heuristic. It's just here because composites can currently // pretend to be DOM components. <del> return !!(inst && inst.getDOMNode && inst.tagName); </del> <ins> return !!(inst && inst.tagName && inst.getDOMNode); </ins> }, isDOMComponentElement: function(inst) {

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:
Component.displayName || Component.name || 'Component'; warning( <del> typeof inst.props === 'undefined' || !propsMutated, </del> <ins> inst.props === undefined || !propsMutated, </ins> '%s(...): When calling super() in `%s`, make sure to pass ' + 'up the same props that your component's constructor was passed.', componentName, componentName

Discussion:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.
Change:
'radio': true }; <del> function _assertLink(input) { </del> <ins> function _assertSingleLink(input) { invariant( input.props.checkedLink == null || input.props.valueLink == null, 'Cannot provide a checkedLink and a valueLink. If you want to use ' + 'checkedLink, you probably don't want to use valueLink and vice versa.' ); } function _assertValueLink(input) { _assertSingleLink(input); </ins> invariant( input.props.value == null && input.props.onChange == null, 'Cannot provide a valueLink and a value or onChange event. If you want ' +

Discussion:
When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?
Change:
'use strict'; <ins> var DisabledInputUtils = require('DisabledInputUtils'); </ins> var DOMPropertyOperations = require('DOMPropertyOperations'); var LinkedValueUtils = require('LinkedValueUtils'); var ReactDOMComponentTree = require('ReactDOMComponentTree');

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:
<title>Hello React</title> <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/JSXTransformer-{{site.react_version}}.js"></script> <del> <script src="https://code.jquery.com/jquery-1.10.0.min.js"></script> </del> <ins> <script src="https://code.jquery.com/jquery-2.1.3.min.js"></script> </ins> <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/0.3.2/marked.min.js"></script> </head> ```

Discussion:
"Getting started" defined to . "Adding Markdown" defined to . Should be unify to or ?
Nice find. We should use the same version. Are you interested in creating a PR to update it?
Yes I am. I looking at I think will attempt to unify the . I would like to create a PR so I'll do that soon.