jiebi/CodeConvo huggingface dataset:
Code change:
<ReallyLongErrorMessageThatWillCauseTextToBeTruncated /> <DuplicateWarningsAndErrors /> <MultipleWarningsAndErrors /> <ins> <ComponentWithSymbolWarning /> </ins> </Fragment> ); }

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:
if (!styles.hasOwnProperty(styleName)) { continue; } <ins> var styleValue = styles[styleName]; </ins> if (__DEV__) { <del> if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } else if (badVendoredStyleNamePattern.test(styleName)) { warnBadVendoredStyleName(styleName); } </del> <ins> warnValidStyle(styleName, styleValue); </ins> } <del> var styleValue = styles[styleName]; </del> if (styleValue != null) { serialized += processStyleName(styleName) + ':'; serialized += dangerousStyleValue(styleName, styleValue) + ';';

Related discussion:
text: On the first render it works, but then the update silently fails. Expected would be the semicolon being removed, or an error/warning in the development build. Tested on Chrome latest, Firefox latest, with 0.12.1 and master. Minimal: ran into (on IRC).
My first instinct is to put a warning in DEV so we don't incur any costs in prod. This would be similar to our other style key warning ("you used background-color but probably meant backgroundColor" or whatever it is we say).
sounds reasonable, I don't think there's any valid reason to have a semicolon there.
It's only a warning, but it's worth considering that is valid CSS IIRC.
so that wouldn't warn :)
Oh right :), but I've seen plenty of invalid , but perhaps that's an exercise for some other time. Anyway, you might want to ignore white-space after the as well.
I'm working on this issue. I've a warning, but thinking that it may be a good idea to trim any semicolons as well. The warning will serve to let developers know it's invalid syntax, but try and fix the problem while we're at it.
Code change:
} `, }, <ins> { code: normalizeIndent` export const notAComponent = () => { return () => { useState(); } } `, // TODO: this should error but doesn't. // errors: [functionError('use', 'notAComponent')], }, { code: normalizeIndent` export default () => { if (isVal) { useState(0); } } `, // TODO: this should error but doesn't. // errors: [genericError('useState')], }, { code: normalizeIndent` function notAComponent() { return new Promise.then(() => { useState(); }); } `, // TODO: this should error but doesn't. // errors: [genericError('useState')], }, </ins> ], invalid: [ {

Related discussion:
text: React version: "eslint-plugin-react-hooks": "^4.2.0" Link to code example: (eslint-plugin-react-hooks) did not fire when it is inside of a Promise block. Please find the detailed explanation in example code below. thx
How do you use hooks inside promises? Hooks should only be called in the body of components
that is right, but I was not aware of it when I code it. And I think should have caught the error. Can you update the code for to make sure the bug won't fall through the crack? To be specific, the hook I was trying to access inside of promise is , which is about injecting the relay environment to handle the GraphQL query/mutation. Because Eslint did not capture this issue, I merged the bug into production until users complained...
This is described in the documentation and any tutorials. I'm not the maintainer of react, but it seems to me that the plugin should not check such things.
I think this issue is actually the anon function, which is reported here: Leaving this open to confirm fixing anon function fixes this.
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!
Code change:
} `, }, <ins> { code: normalizeIndent` export const notAComponent = () => { return () => { useState(); } } `, // TODO: this should error but doesn't. // errors: [functionError('use', 'notAComponent')], }, { code: normalizeIndent` export default () => { if (isVal) { useState(0); } } `, // TODO: this should error but doesn't. // errors: [genericError('useState')], }, { code: normalizeIndent` function notAComponent() { return new Promise.then(() => { useState(); }); } `, // TODO: this should error but doesn't. // errors: [genericError('useState')], }, </ins> ], invalid: [ {

Related discussion:
text: React version: 17.0.2 React-refresh version: 0.10.0 This issue is similar to , but ignores default exported unnamed functions instead. As a code comment suggests, this is a known limitation: Would a fix be considered? Given the following files, making changes to doesn't trigger a re-render. module: module: Making changes to does not re-render the element in . The transformed module does not register the for refresh. Making changes to does re-render the element in .
This is intentional — even if we fix this case, we need some heuristic for other tools like lint rules. Why are you using this style? Functions should have names so that you get them in stack traces and so on.
Indeed, but then it becomes confusing: If there's no way around, this can be closed and I'll make a suggestion downstream to use The code comment mentioned above should then also be more explicit, replacing "currently" by "intentionally".
However, given that an ignored component prevents a refresh (), I haven't figured out yet whether this is an issue with itself or with . AFAIK, a code update of an ignored component should still trigger a refresh.
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!
Code change:
findHostInstancesForRefresh, } from './ReactFiberHotReloading.new'; import {markRenderScheduled} from './SchedulingProfiler'; <ins> import ReactVersion from 'shared/ReactVersion'; </ins> export {registerMutableSourceForHydration} from './ReactMutableSource.new'; export {createPortal} from './ReactPortal'; export {

Related discussion:
text: This is a followup issue for pmndrs/react-three-fiber From my understanding of , the DevTools parse the version number advertised by the renderer in to select how to parse the internal fiber object. Unfortunately this means that third-party renderers that advertise a version lower than the equivalent React version for the release they are using get misclassified: for instance is using which is equivalent to , and since major version is much lower than it uses the default values for the enum which in turns lead to getting identified as and hook inspection being unavailable. A short term solution for renderers is to advertise a React-compatible version number, but ideally this is an implementation detail of the devtools that users of should not have to be aware of (also this means the version number displayed in the devtools is wrong). I'm not sure I'm familiar enough with the internals of the devtools to open a PR for this, but since the version parsing logic is used to detect features that are internal to anyway I guess a solution would be to have the Reconciler package add its own value for the constant along with the parameters sent to the devtools backend, and have the devtools use this string if its available over the renderer version.
Once and land (and get released) newer versions of the reconciler will inject its own version (to be used instead of the renderer version). Unfortunately this won't help you until you upgrade.
Code change:
onMouseMove onMouseOut onMouseOver onMouseUp ``` <del> Properties: </del> <ins> Properties: </ins> ```javascript boolean altKey

Related discussion:
text: We currently support this, but it makes code less understandable and we'd like to stop supporting it and encourage people to use either e.preventDefault() or e.stopPropagation() as appropriate.
:+1: And then free up the event handler's return value for something else.
you mean? :)
Maybe =) Otherwise we can always use it to indicate something in a potential future event system.
Code change:
} var frame = this.stack[this.stack.length - 1]; if (frame.childIndex >= frame.children.length) { <del> out += frame.footer; this.previousWasTextNode = false; </del> <ins> var footer = frame.footer; out += footer; if (footer !== '') { this.previousWasTextNode = false; } </ins> this.stack.pop(); if (frame.tag === 'select') { this.currentSelectValue = null;

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:
this._instance.context = context; this._instance.props = props; this._instance.state = state; <ins> this._newState = null; </ins> if (shouldUpdate) { this._rendered = this._instance.render();

Related discussion:
text: <!-- 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 , the shallow renderer will set instance state in so the and will be the same in , which is different with the behavior of real rendering. 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: given below class component: render with ReactDOM, the will return true since will be the old value : In shallow renderer, the behavior is different: What is the expected behavior? ShallowRenderer should not set the instance state in getDeriveStateFromProps, or in the we have no way to compare it. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I have tested this in master branch and 16.3, both not work. By the way this problem is related to airbnb/enzyme . If it's recoginzed as a bug I can provide a PR in next several days.
Code change:
// 'msTransform' is correct, but the other prefixes should be capitalized var badVendoredStyleNamePattern = /^(?:webkit|moz|o)[A-Z]/; <ins> // style values shouldn't contain a semicolon var badStyleValueWithSemicolonPattern = /;s*$/; </ins> var warnedStyleNames = {}; <ins> var warnedStyleValues = {}; </ins> var warnHyphenatedStyleName = function(name) { if (warnedStyleNames.hasOwnProperty(name) && warnedStyleNames[name]) {

Related discussion:
text: On the first render it works, but then the update silently fails. Expected would be the semicolon being removed, or an error/warning in the development build. Tested on Chrome latest, Firefox latest, with 0.12.1 and master. Minimal: ran into (on IRC).
My first instinct is to put a warning in DEV so we don't incur any costs in prod. This would be similar to our other style key warning ("you used background-color but probably meant backgroundColor" or whatever it is we say).
sounds reasonable, I don't think there's any valid reason to have a semicolon there.
It's only a warning, but it's worth considering that is valid CSS IIRC.
so that wouldn't warn :)
Oh right :), but I've seen plenty of invalid , but perhaps that's an exercise for some other time. Anyway, you might want to ignore white-space after the as well.
I'm working on this issue. I've a warning, but thinking that it may be a good idea to trim any semicolons as well. The warning will serve to let developers know it's invalid syntax, but try and fix the problem while we're at it.
Code change:
through2 "^2.0.0" fbjs@^0.8.9: <del> version "0.8.12" resolved "https://registry.yarnpkg.com/fbjs/-/fbjs-0.8.12.tgz#10b5d92f76d45575fd63a217d4ea02bea2f8ed04" </del> <ins> version "0.8.14" resolved "https://registry.yarnpkg.com/fbjs/-/fbjs-0.8.14.tgz#d1dbe2be254c35a91e09f31f9cd50a40b2a0ed1c" </ins> dependencies: core-js "^1.0.0" isomorphic-fetch "^2.1.1"

Related discussion:
text: Check that they were a part of the latest internal sync. For stable releases, prefer that they’ve been landed for a week or so. Only skip this step if you really know what you’re doing! [x] You’re in [x] You’re in [x] You’re in [x] You’re in If not, ping someone on the team![x] Ensure you’re on [x] Do a . [x] Check that your local output matches the commit list. [x] Run in the repo root.[x] For : [x] Look at the version range of in root . [x] Ensure all depending on specify the same range. [x] Run in the repo root. (Don’t miss the caret!) [x] For : [x] Look at the version range of in root . [x] Ensure all depending on specify the same range. [x] Run in the repo root. (Don’t miss the caret!) [x] For : [x] Look at the version range of in root . [x] Ensure all depending on specify the same range. [x] Run in the repo root. (Don’t miss the caret!) [x] This might change the lockfile. This should not change any . [x] Commit the changes, if any. (see )[x] Edit: is broken in the 16 branch but this shouldn't block RC, and will be fixed asap by and in [x] Run in the repo root. [x] Run in the repo root. [x] Run in the repo root.[x] Run in the repo root. [x] If changes, [x] Maybe: If we still have a separate branch for docs when you’re reading this, we need to cherry-pick that commit to that branch. This makes sure the website decoder knows about the updated error codes. But ideally we should just change docs to serve from master. (See and ) [x] Update export in [x] Update in all : [x] [x] [x] [x] [x] If you see any other packages, update this list :-) [x] Run to verify your changes. [x][x] Run in the repo root.[x] Open in the browser for a smoke test.
Code change:
through2 "^2.0.0" fbjs@^0.8.9: <del> version "0.8.12" resolved "https://registry.yarnpkg.com/fbjs/-/fbjs-0.8.12.tgz#10b5d92f76d45575fd63a217d4ea02bea2f8ed04" </del> <ins> version "0.8.14" resolved "https://registry.yarnpkg.com/fbjs/-/fbjs-0.8.14.tgz#d1dbe2be254c35a91e09f31f9cd50a40b2a0ed1c" </ins> dependencies: core-js "^1.0.0" isomorphic-fetch "^2.1.1"

Related discussion:
text: [x] It should say “Hello world!”[x] Go to and run [x] [x] Go to the repo root and run [x] Open http://localhost:5000/fixtures/packaging/ and verify every iframe shows “Hello World!”[x] Run [x] Run [x] Go to [x] For every subfolder: [x] For non-stable versions: Run in the subfolder. [x] For stable versions: Run in the subfolder.[ ] [ ] [ ]
w00t~
Code change:
it("should empty element when removing innerHTML", function() { var stub = ReactTestUtils.renderIntoDocument( <del> <div dangerouslySetInnerHTML={{__html: ":)"}} /> </del> <ins> <div dangerouslySetInnerHTML={{__html: ':)'}} /> </ins> ); expect(stub.getDOMNode().innerHTML).toEqual(':)');

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:
it("should empty element when removing innerHTML", function() { var stub = ReactTestUtils.renderIntoDocument( <del> <div dangerouslySetInnerHTML={{__html: ":)"}} /> </del> <ins> <div dangerouslySetInnerHTML={{__html: ':)'}} /> </ins> ); expect(stub.getDOMNode().innerHTML).toEqual(':)');

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:
expect(result).toEqual(<div>value:1</div>); }); <ins> it('should pass previous state to shouldComponentUpdate even with getDerivedStateFromProps', () => { class SimpleComponent extends React.Component { constructor(props) { super(props); this.state = { value: props.value, }; } static getDerivedStateFromProps(nextProps, prevState) { if (nextProps.value === prevState.value) { return null; } return {value: nextProps.value}; } shouldComponentUpdate(nextProps, nextState) { return nextState.value !== this.state.value; } render() { return <div>{`value:${this.state.value}`}</div>; } } const shallowRenderer = createRenderer(); const initialResult = shallowRenderer.render( <SimpleComponent value="initial" />, ); expect(initialResult).toEqual(<div>value:initial</div>); const updatedResult = shallowRenderer.render( <SimpleComponent value="updated" />, ); expect(updatedResult).toEqual(<div>value:updated</div>); }); </ins> it('can setState with an updater function', () => { let instance;

Related discussion:
text: <!-- 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 , the shallow renderer will set instance state in so the and will be the same in , which is different with the behavior of real rendering. 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: given below class component: render with ReactDOM, the will return true since will be the old value : In shallow renderer, the behavior is different: What is the expected behavior? ShallowRenderer should not set the instance state in getDeriveStateFromProps, or in the we have no way to compare it. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I have tested this in master branch and 16.3, both not work. By the way this problem is related to airbnb/enzyme . If it's recoginzed as a bug I can provide a PR in next several days.
Code change:
/** * Same as the default implementation, except cancels the event when return <del> * value is false. </del> <ins> * value is false. This behavior will be disabled in a future release. </ins> * * @param {object} Event to be dispatched. * @param {function} Application-level callback.

Related discussion:
text: We currently support this, but it makes code less understandable and we'd like to stop supporting it and encourage people to use either e.preventDefault() or e.stopPropagation() as appropriate.
:+1: And then free up the event handler's return value for something else.
you mean? :)
Maybe =) Otherwise we can always use it to indicate something in a potential future event system.
Code change:
<a class="docs-next" href="/react/docs/{{ page.next }}">Next &rarr;</a> {% endif %} </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: