jiebi/CodeConvo huggingface dataset:
Code change:
ReactDOMIDOperations.updateInnerHTMLByID( 'testID', <del> {__html: ' testContent'} </del> <ins> ' testContent' </ins> ); expect(

Related discussion:
text: reported the following issue on IRC: (Both on master and 4.0) The repro case is: 1) Render 2) Render 3) Render the same as 1) The div has its innerHTML empty instead of . I don't really know what's going on. can you guys look at it?
One other tidbit: this only seems to happen when the value is exactly the same in step 3 as it was in step 1. If it's different (i.e. ), things work as expected.
What happens if you change step 2 to a instead of a ? It works, right?
I just reduced the test case to 19 lines.
yeah changing 2) to use a span works as expected
If anyone wants to look into this, the bug is probably here
I cannot reproduce what you are seeing: It also bugs if I use a different string
I'm not able to reproduce that particular behavior given this small repro case. The original code had several more layers... will keep trying.
I know this is a very old issue but I had a similar problem and came across this. I found that this problem occurs when you do not add a property to the React component containing the property. So, does not seem to work reproducibly, whereas seems to. I think this could be related to React's diffing algorithm that might not properly treat a component with a statement if that component gets rerendered multiple times with different inner content. Just posting this here in case other people have the same issue and stumble upon this.
thx you saved my day :-)
Seems like the issue is back again. Thanks, solves the problem for me too.
If any of you can post a simple repro case showing the broken behavior here, I'd be happy to take a look at fixing it.
Took me a while to repro, but here you go: (ugly, but demonstrates the issue well)
Thanks. This is the same issue as . No fix currently, but using the key as a workaround is fine and I'll see if we can fix this sometime.
Thanks that was giving me fits!
If anyone is still seeing issues on 0.14, please make a new issue with a simple repro case.
Code change:
ReactDOMIDOperations.updateInnerHTMLByID( 'testID', <del> {__html: ' testContent'} </del> <ins> ' testContent' </ins> ); expect(

Related discussion:
text: I have this issue, but can't reproduce in a simple example - my original code is layered and I think that's the reason the real DOM doesn't reconcile. In the react debugger is looks as dangerouslySetInnerHTML has proper __html value, but it doesn't equeal to the innerHTML of the actual element. I used an extremely simple (and equally nasty) workaround. Writing it here just in case it will help someone:
Reading out will rarely give you what you put in because the browser does various kinds of normalization on it. If you can repro with a standalone example though I'm happy to take a look.
well, that's more like a control shot :-)
Looks like the issue still exist in 16.4.1 when using on a tag, you cannot nest other or . issue is fixed by replacing the container with a
If you experience something similar three years later, and the original issue is closed, you can be sure it's a different unrelated issue. :-) Please file a new one. We don't keep track of closed issues so your feedback is unfortunately going into the void. When filing a new issue, please provide a reproducing example. when using dangerouslySetInnerHTML on a tag, you cannot nest other or This sounds like browsers work. You can't nest into . This is why React warns when you do it (except in which case React can't validate it).
Code change:
const commitTrees = ((rootToCommitTreeMap.get( rootID, ): any): Array<CommitTree>); if (commitIndex < commitTrees.length) { return commitTrees[commitIndex]; }

Related discussion:
text: Describe what you were doing when the bug occurred: back to go back through the frames following a profile session. I think I got to zero and then clicked it again and then it errored Please do not remove the text below this line DevTools version: 4.8.2- Call stack: at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) at getCommitTree (chrome-) Component stack: at CommitRankedAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevToolsDevTools (chrome-)
Please how do I replicate this? I don't seem to be able to replicate it.
sorry, I won't have time to create a mre. I was doing a recording on a site with a lot of components and a lot of frames in the recording. I ended up going to maybe frame 30 then clicking back rapidly to get back to 0 and I guess went to far or something. Feel free to close this, I thought that the logs might be enough and it was encouraging me to submit the issue.
Can I have a look ?
Maybe change this recursive function And use a loop going to correct the issue. If it is ok, i can work on it.
can you share how you were able to replicate the issue?
I think for there to be a stack overflow from calling itself, it would need to have profiling data with thousands (?) of commits. This function only recurses (at most) once per commit when processing data, and then, too, only if you jump through commits you haven't yet processed (so 0 -N would recurse N times). That being said, it seems like we could also rewrite this function to be iterative without too much trouble. Done in PR !
That's quite possible actually. The issue I was trying to diagnose was high CPU usage on an app that has spreadsheet like functionality, i.e.
Code change:
const commitTrees = ((rootToCommitTreeMap.get( rootID, ): any): Array<CommitTree>); if (commitIndex < commitTrees.length) { return commitTrees[commitIndex]; }

Related discussion:
text: lots of components so I was trying to see exactly what was taking all the CPU time. Thanks for the PR. Hopefully next time this crops up it will solve it.
Great Should be released sometime in the next few days.
Code change:
return [<div />]; } <ins> function ComponentWithSymbolWarning() { console.warn('this is a symbol', Symbol('foo')); console.error('this is a symbol', Symbol.for('bar')); return null; } </ins> export default function ErrorsAndWarnings() { const [count, setCount] = useState(0); const handleClick = () => setCount(count + 1);

Related discussion:
text: <!-- 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: DevTools version 4.12.2- from within a React component where the last argument is typeof <!-- 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. --Link to code example: The bug only happens when you make a change, so if you use the code sandbox link you need, open a new window, active dev tools, open the React dev tools and then uncomment line 5: only then will the error actually happen. I've located the culprit to this line of code And would offer the following change <!-- 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: --React DevTools is implicitly converting a Symbol to a string. React DevTools does not implicitly try to convert a Symbol to a string.
Thanks for the report. Also reproduced with DevTools version 4.12.3- in Chrome 90 In addition to fixing the bug, it would also be nice to guard against devtools failing so that the UI is unaffected if devtools is faulty. /cc
Your the best, thanks for a quick turn around!
Code change:
expectTextNode(e.childNodes[1], 'bar'); } }); <ins> itRenders( 'a component returning text node between two text nodes', async render => { const B = () => 'b'; const e = await render(<div>{'a'}<B />{'c'}</div>); if ( render === serverRender || render === clientRenderOnServerString || render === streamRender ) { // In the server render output there's a comment between them. expect(e.childNodes.length).toBe(5); expectTextNode(e.childNodes[0], 'a'); expectTextNode(e.childNodes[2], 'b'); expectTextNode(e.childNodes[4], 'c'); } else { expect(e.childNodes.length).toBe(3); expectTextNode(e.childNodes[0], 'a'); expectTextNode(e.childNodes[1], 'b'); expectTextNode(e.childNodes[2], 'c'); } }, ); itRenders('a tree with sibling host and text nodes', async render => { class X extends React.Component { render() { return [null, [<Y key="1" />], false]; } } function Y() { return [<Z key="1" />, ['c']]; } function Z() { return null; } const e = await render( <div> {[['a'], 'b']} <div> <X key="1" /> d </div> e </div>, ); if ( render === serverRender || render === clientRenderOnServerString || render === streamRender ) { // In the server render output there's comments between text nodes. expect(e.childNodes.length).toBe(5); expectTextNode(e.childNodes[0], 'a'); expectTextNode(e.childNodes[2], 'b'); expect(e.childNodes[3].childNodes.length).toBe(3); expectTextNode(e.childNodes[3].childNodes[0], 'c'); expectTextNode(e.childNodes[3].childNodes[2], 'd'); expectTextNode(e.childNodes[4], 'e'); } else { expect(e.childNodes.length).toBe(4); expectTextNode(e.childNodes[0], 'a'); expectTextNode(e.childNodes[1], 'b'); expect(e.childNodes[2].childNodes.length).toBe(2); expectTextNode(e.childNodes[2].childNodes[0], 'c'); expectTextNode(e.childNodes[2].childNodes[1], 'd'); expectTextNode(e.childNodes[3], 'e'); } }); </ins> }); describe('number children', function() {

Related discussion:
text: Observed this on react This renders as . If you try to hydrate this you'll get the error: Text content did not match. Server: "bc" Client: "b".
I suppose the bug here is that we do not separate from here but we should.
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.
Everything looks good on my end, thanks!
Code change:
var inlineScriptCount = 0; <ins> // This method returns a nicely formated line of code pointing the // exactly location of the error `e`. // The line is limited in size so big lines of code are also shown // in a readable way. // Example: // // ... x', overflow:'scroll'}} id={} onScroll={this.scroll} class=" ... //                                 ^ var createSourceCodeErrorMessage = function(code, e) { var sourceLines = code.split('n'); var erroneousLine = sourceLines[e.lineNumber - 1]; // Removes any leading indenting spaces and gets the number of // chars indenting the `erroneousLine` var indentation = 0; erroneousLine = erroneousLine.replace(/^s+/, function(leadingSpaces) { indentation = leadingSpaces.length; return ''; }); // Defines the number of characters that are going to show // before and after the erroneous code var LIMIT = 30; var errorColumn = e.column - indentation; if (errorColumn > LIMIT) { erroneousLine = '... ' + erroneousLine.slice(errorColumn - LIMIT); errorColumn = 4 + LIMIT; } if (erroneousLine.length - errorColumn > LIMIT) { erroneousLine = erroneousLine.slice(0, errorColumn + LIMIT) + ' ...'; } var message = 'nn' + erroneousLine + 'n'; message += new Array(errorColumn - 1).join(' ') + '^'; return message; }; </ins> var transformCode = function(code, source) { var jsx = docblock.parseAsObject(docblock.extract(code)).jsx; if (jsx) { <del> var transformed = transformReact(code); </del> <ins> try { var transformed = transformReact(code); } catch(e) { e.message += 'n    at '; if (source) { if ('fileName' in e) { // We set `fileName` if it's supported by this error object and // a `source` was provided. // The error will correctly point to `source` in Firefox. e.fileName = source; } e.message += source + ':' + e.lineNumber + ':' + e.column; } else { e.message += location.href; } e.message += createSourceCodeErrorMessage(code, e); throw e; } </ins> var map = transformed.sourceMap.toJSON(); if (source == null) {

Related discussion:
text: This makes it basically unusable in any nontrivial project. While people shouldn't be using this in production, we should still fix this bug for newbies and people using it for hackathons.
This should be relatively easy. What should we do with inline tags?
Code change:
} const {operations} = dataForRoot; <ins> if (operations.length <= commitIndex) { throw Error( `getCommitTree(): Invalid commit "${commitIndex}" for root "${rootID}". There are only "${operations.length}" commits.`, ); } </ins> <del> // Commits are generated sequentially and cached. // If this is the very first commit, start with the cached snapshot and apply the first mutation. // Otherwise load (or generate) the previous commit and append a mutation to it. if (commitIndex === 0) { const nodes = new Map(); // Construct the initial tree. recursivelyInitializeTree(rootID, 0, nodes, dataForRoot); </del> <ins> let commitTree: CommitTree = ((null: any): CommitTree); for (let index = commitTrees.length; index <= commitIndex; index++) { // Commits are generated sequentially and cached. // If this is the very first commit, start with the cached snapshot and apply the first mutation. // Otherwise load (or generate) the previous commit and append a mutation to it. if (index === 0) { const nodes = new Map(); </ins> <del> // Mutate the tree if (operations != null && commitIndex < operations.length) { const commitTree = updateTree({nodes, rootID}, operations[commitIndex]); </del> <ins> // Construct the initial tree. recursivelyInitializeTree(rootID, 0, nodes, dataForRoot); </ins> <del> if (__DEBUG__) { __printTree(commitTree); } </del> <ins> // Mutate the tree if (operations != null && index < operations.length) { commitTree = updateTree({nodes, rootID}, operations[index]); </ins> <del> commitTrees.push(commitTree); return commitTree; } } else { const previousCommitTree = getCommitTree({ commitIndex: commitIndex - 1, profilerStore, rootID, }); </del> <ins> if (__DEBUG__) { __printTree(commitTree); } </ins> <del> if (operations != null && commitIndex < operations.length) { const commitTree = updateTree( previousCommitTree, operations[commitIndex], ); </del> <ins> commitTrees.push(commitTree); } } else { const previousCommitTree = commitTrees[index - 1]; commitTree = updateTree(previousCommitTree, operations[index]); </ins> if (__DEBUG__) { __printTree(commitTree); } commitTrees.push(commitTree); <del> return commitTree; </del> } } <del> throw Error( `getCommitTree(): Unable to reconstruct tree for root "${rootID}" and commit "${commitIndex}"`, ); </del> <ins> return commitTree; </ins> } function recursivelyInitializeTree(

Related discussion:
text: lots of components so I was trying to see exactly what was taking all the CPU time. Thanks for the PR. Hopefully next time this crops up it will solve it.
Great Should be released sometime in the next few days.
Code change:
<ins> /** * Copyright 2013-2014, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ "use strict"; var React; var ReactTestUtils; var mocks; var warn; describe('ReactTestUtils', function() { beforeEach(function() { mocks = require('mocks'); React = require('React'); ReactTestUtils = require('ReactTestUtils'); warn = console.warn; console.warn = mocks.getMockFunction(); }); afterEach(function() { console.warn = warn; }); it('should have shallow rendering', function() { var SomeComponent = React.createClass({ render: function() { return ( <div> <span className="child1" /> <span className="child2" /> </div> ); } }); var shallowRenderer = ReactTestUtils.createRenderer(); shallowRenderer.render(<SomeComponent />); var result = shallowRenderer.getRenderOutput(); expect(result.type).toBe('div'); expect(result.props.children).toEqual([ <span className="child1" />, <span className="child2" /> ]); }); it('lets you update shallowly rendered components', function() { var SomeComponent = React.createClass({ getInitialState: function() { return {clicked: false}; }, onClick: function() { this.setState({clicked: true}); }, render: function() { var className = this.state.clicked ? 'was-clicked' : ''; if (this.props.aNew === 'prop') { return ( <a href="#" onClick={this.onClick} className={className}> Test link </a> ); } else { return ( <div> <span className="child1" /> <span className="child2" /> </div> ); } } }); var shallowRenderer = ReactTestUtils.createRenderer(); shallowRenderer.render(<SomeComponent />); var result = shallowRenderer.getRenderOutput(); expect(result.type).toBe('div'); expect(result.props.children).toEqual([ <span className="child1" />, <span className="child2" /> ]); shallowRenderer.render(<SomeComponent aNew="prop" />); var updatedResult = shallowRenderer.getRenderOutput(); expect(updatedResult.type).toBe('a'); var mockEvent = {}; updatedResult.props.onClick(mockEvent); var updatedResultCausedByClick = shallowRenderer.getRenderOutput(); expect(updatedResultCausedByClick.type).toBe('a'); expect(updatedResultCausedByClick.props.className).toBe('was-clicked'); }); }); </ins>

Related discussion:
text: If there are specific features you miss in the shallow renderer please create new issues with proposals on how they should work. Note that we a new that is much more feature-complete.
Code change:
* @internal */ unmountComponent: function() { <ins> this.unmountChildren(); </ins> ReactEventEmitter.deleteAllListeners(this._rootNodeID); ReactComponent.Mixin.unmountComponent.call(this); <del> this.unmountChildren(); </del> } };

Related discussion:
text: When unmounting components like this: a memory leak happens because ReactMount.getID(node) puts DOM nodes back to nodeCache if they are not there.. just right after they were purged from cache. Here is what's happing when unmounting that example component: label component gets purged from nodeCache when ReactDOMInput component is going to unmount it calls this method: which contains this.getDOMNode() which iterates through the children of the Form element calling getID() on each of them.. which puts these elements back into the cache. So first they were purged and here they are all put back in cache causing a memory leak :( I'm playing with React just 3rd day so not sure of a way to correctly fix this issue
(I took the liberty to edit your comment to add syntax highlighting)
I can't reproduce this. With this diff applied, I loaded http://127.0.0.1:8000/examples/ballmer-peak/ in the console and checked -- it was empty. Am I misunderstanding?
Yes. You've missed one more user defined component in there.. Here you go:
Thanks, fixed in .
Thank you for fast fix :)
Thanks for the find/fix!
Code change:
</div> <div class="fb-like" data-send="true" data-width="650" data-show-faces="false"></div> <del> <div class="fb-comments" data-width="650" data-num-posts="10" data-href="{{ site.url }}{{ site.baseurl }}{{ page.url }}"></div> </del> </div> </section>

Related discussion:
text: Should those comment sections exist? I'd rather people come to IRC. Their questions are often neglected at the bottom of a doc page.
:+1: for shutting down comments
+1
:+1:
Code change:
styleUpdates[styleName] = ''; } } <del> } else if (propKey === DANGEROUSLY_SET_INNER_HTML) { // http://jsperf.com/emptying-speed ReactComponent.DOMIDOperations.updateTextContentByID( this._rootNodeID, '' ); </del> } else if (registrationNames[propKey]) { deleteListener(this._rootNodeID, propKey); <del> } else { </del> <ins> } else if ( DOMProperty.isStandardName[propKey] || DOMProperty.isCustomAttribute(propKey)) { </ins> ReactComponent.DOMIDOperations.deletePropertyByID( this._rootNodeID, propKey

Related discussion:
text: reported the following issue on IRC: (Both on master and 4.0) The repro case is: 1) Render 2) Render 3) Render the same as 1) The div has its innerHTML empty instead of . I don't really know what's going on. can you guys look at it?
One other tidbit: this only seems to happen when the value is exactly the same in step 3 as it was in step 1. If it's different (i.e. ), things work as expected.
What happens if you change step 2 to a instead of a ? It works, right?
I just reduced the test case to 19 lines.
yeah changing 2) to use a span works as expected
If anyone wants to look into this, the bug is probably here
I cannot reproduce what you are seeing: It also bugs if I use a different string
I'm not able to reproduce that particular behavior given this small repro case. The original code had several more layers... will keep trying.
I know this is a very old issue but I had a similar problem and came across this. I found that this problem occurs when you do not add a property to the React component containing the property. So, does not seem to work reproducibly, whereas seems to. I think this could be related to React's diffing algorithm that might not properly treat a component with a statement if that component gets rerendered multiple times with different inner content. Just posting this here in case other people have the same issue and stumble upon this.
thx you saved my day :-)
Seems like the issue is back again. Thanks, solves the problem for me too.
If any of you can post a simple repro case showing the broken behavior here, I'd be happy to take a look at fixing it.
Took me a while to repro, but here you go: (ugly, but demonstrates the issue well)
Thanks. This is the same issue as . No fix currently, but using the key as a workaround is fine and I'll see if we can fix this sometime.
Thanks that was giving me fits!
If anyone is still seeing issues on 0.14, please make a new issue with a simple repro case.
Code change:
styleUpdates[styleName] = ''; } } <del> } else if (propKey === DANGEROUSLY_SET_INNER_HTML) { // http://jsperf.com/emptying-speed ReactComponent.DOMIDOperations.updateTextContentByID( this._rootNodeID, '' ); </del> } else if (registrationNames[propKey]) { deleteListener(this._rootNodeID, propKey); <del> } else { </del> <ins> } else if ( DOMProperty.isStandardName[propKey] || DOMProperty.isCustomAttribute(propKey)) { </ins> ReactComponent.DOMIDOperations.deletePropertyByID( this._rootNodeID, propKey

Related discussion:
text: I have this issue, but can't reproduce in a simple example - my original code is layered and I think that's the reason the real DOM doesn't reconcile. In the react debugger is looks as dangerouslySetInnerHTML has proper __html value, but it doesn't equeal to the innerHTML of the actual element. I used an extremely simple (and equally nasty) workaround. Writing it here just in case it will help someone:
Reading out will rarely give you what you put in because the browser does various kinds of normalization on it. If you can repro with a standalone example though I'm happy to take a look.
well, that's more like a control shot :-)
Looks like the issue still exist in 16.4.1 when using on a tag, you cannot nest other or . issue is fixed by replacing the container with a
If you experience something similar three years later, and the original issue is closed, you can be sure it's a different unrelated issue. :-) Please file a new one. We don't keep track of closed issues so your feedback is unfortunately going into the void. When filing a new issue, please provide a reproducing example. when using dangerouslySetInnerHTML on a tag, you cannot nest other or This sounds like browsers work. You can't nest into . This is why React warns when you do it (except in which case React can't validate it).