jiebi/CodeConvo huggingface dataset:
Code change:
name.charAt(0).toUpperCase() + name.slice(1) + '?' ); }; <ins> var warnStyleValueWithSemicolon = function(name, value) { if (warnedStyleValues.hasOwnProperty(value) && warnedStyleValues[value]) { return; } warnedStyleValues[value] = true; warning( false, 'Style property values shouldn't contain a semicolon. ' + 'Try "%s: %s" instead.', name, value.replace(badStyleValueWithSemicolonPattern, '') ); }; /** * @param {string} name * @param {*} value */ var warnValidStyle = function(name, value) { if (name.indexOf('-') > -1) { warnHyphenatedStyleName(name); } else if (badVendoredStyleNamePattern.test(name)) { warnBadVendoredStyleName(name); } else if (badStyleValueWithSemicolonPattern.test(value)) { warnStyleValueWithSemicolon(name, value); } }; </ins> } /**

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:
expect(called).toBe(true); }); <ins> it('warns and throws if you use TestUtils.act instead of TestRenderer.act in node', () => { // we warn when you try to load 2 renderers in the same 'scope' // so as suggested, we call resetModules() to carry on with the test jest.resetModules(); const {act} = require('react-dom/test-utils'); expect(() => { expect(() => act(() => {})).toThrow('document is not defined'); }).toWarnDev( [ 'It looks like you called TestUtils.act(...) in a non-browser environment', ], {withoutStack: 1}, ); }); </ins> }); });

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. Behavior regression. What is the current behavior? Package throws when being required in Node. 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: What is the expected behavior? should not throw in "pure" node (without providing fake document on global). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? happens on 16.8.0 previous versions work.
We also got this issue after upgrading to 16.8.0
Found the fix and putting together a PR now edit: now on the case
Code change:
var invariant = require('invariant'); var keyOf = require('keyOf'); <ins> var warning = require('warning'); </ins> var topLevelTypes = EventConstants.topLevelTypes;

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:
> lightweight description of what the DOM should look like. We call this process **reconciliation**. Check out <del> [this jsFiddle](http://jsfiddle.net/fv6RD/3/) to see an example of </del> <ins> [this jsFiddle](http://jsfiddle.net/2h6th4ju/) to see an example of </ins> reconciliation in action. Because this re-render is so fast (around 1ms for TodoMVC), the developer

Related discussion:
text: Do you want to request a feature or report a bug? bug What is the current behavior? does not work, the code is not executed, there are two files loaded from the Facebook servers but they both return a 5xx error If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Go to and then click the link at the bottom to go to and then click on the link to jsfiddle in the text What is the expected behavior? that there is some generated output in the result pane Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Chrome (latest stable, Mac OS), Safari (Mac OS)
That’s a pretty old blogpost. I’m not sure why the integration broke, but I recommend to look at more modern examples (e.g. is up to date).
Well, this blogpost is still linked at the bottom here: So this is how I came there. By reading the guide and I thought I would get an uptodate guide with uptodate links ;-)
Fixed now. The new link is It will appear in the blog post the next time we sync our docs. Thanks!
Great. Thanks too.
Code change:
this._defaultProps = null; <del> ReactComponent.Mixin.unmountComponent.call(this); </del> this._renderedComponent.unmountComponent(); this._renderedComponent = null; <ins> ReactComponent.Mixin.unmountComponent.call(this); </ins> if (this.refs) { this.refs = null; }

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:
* **Computed data:** Don't worry about precomputing values based on state — it's easier to ensure that your UI is consistent if you do all computation within `render()`. For example, if you have an array of list items in state and you want to render the count as a string, simply render `this.state.listItems.length + ' list items'` in your `render()` method rather than storing it on state. * **React components:** Build them in `render()` based on underlying props and state. <del> * **Duplicated data from props:** Try to use props as the source of truth where possible. Because props can change over time, it's appropriate to store props in state to be able to know its previous values. </del> <ins> * **Duplicated data from props:** Try to use props as the source of truth where possible. One valid use to store props in state is to be able to know it's previous values, because props can change over time. </ins>

Related discussion:
text: At the end, there is a confusing explanation about "Duplicated data from props" in the section "What Shouldn’t Go in State?": Perhaps what is trying to be said is something like:
Ah, perhaps what they're really referring to is basically "edit pages", where you might want to diff the before and after, so that you can send only the changed variables. But it really reads quite weirdly, especially for beginners.
This change is needed. I'm new to React and just did a Google search on that part of the documentation for clarification and it came up with this page. I'm guessing that what you've interpreted it to mean is correct, as it makes sense that way.
Code change:
``` onClick onDoubleClick onDrag onDragEnd onDragEnter onDragExit onDragLeave onDragOver onDragStart onDrop onMouseDown onMouseEnter onMouseLeave <del> onMouseMove onMouseUp </del> <ins> onMouseMove onMouseOut onMouseOver onMouseUp </ins> ``` Properties:

Related discussion:
text: Someone had the trouble in IRC about it. Edit: changed the subject from "document it" to "support it", because the documentation issue is already at .
Better yet, support it!
Yeah, is there a particular reason it's not supported?
Curious if you've seen the . It's automatically injected into React by default, so you can use it today. IMHO it's (much) better than . (I suppose we could support just for the sake of completeness, but I thought I'd just make sure you guys were aware of .)
We discussed this for a bit on IRC -- was just confused that silently didn't work whereas other events did -- perhaps adding more documentation () will fix the problem too but it seems like we might as well add for completeness. (I agree that enter/leave are much more useful and suggested that over/out are likely missing simply because no one has needed them!)
Agree - I believe there are a few extra allocations (not-pooled) occuring in the event system already today. I'd love to track those down before adding more mouse-move event allocations. If you open the memory profiler in Chrome and move the mouse around, you'll see memory being allocated (and then properly freed of course) but if we use es everywhere, we should be flat. That would make me much more comfortable with adding to . Edit: Just checked out - we already have which fires way more frequently than would so it's probably not such a big deal to add - though we really should get rid of all additional allocations in the event path.
Just started to look a little bit into the allocations here. Redefining trapBubbledEvent in ReactEventEmitter with: still shows allocations in the Chrome memory timeline view, so I'm not convinced that there's anything we can do here? (Replacing trapBubbledEvent itself with a noop makes the allocations go away. simply calls addEventListener.)
I am pretty sure we have done all we can here -- at least I think we've tracked down every callsite where PooledClass would have helped us. I updated our recast transforms to log every syntax construct that would cause an obvious allocation and couldn't find anything. I was thinking maybe there was an array slice or a bind() in there, but experiment shows that this is not the case.
Code change:
``` onClick onDoubleClick onDrag onDragEnd onDragEnter onDragExit onDragLeave onDragOver onDragStart onDrop onMouseDown onMouseEnter onMouseLeave <del> onMouseMove onMouseUp </del> <ins> onMouseMove onMouseOut onMouseOver onMouseUp </ins> ``` Properties:

Related discussion:
text: (I didn't verify that we don't have more allocations than the empty-function case; I don't know of a good way to do so.)
I might be misinformed, but isn't there quite a difference in use cases between mouseenter and mouseover events? Here's a theoretical (non-react) example working with some hover states for nested elements: I tried to apply the above concept in react (with nested components) using onMouseEnter instead, but it obviously fails because it's only triggered once on the top-most element. Moving into a child element and back has no effect. Maybe there's a better approach for this in react altogether?
If you render the child hierarchy with React, you can listen to on each child element you are interested in instead of using event bubbling. It is cheap.
Code change:
'n    in Child (at **)n    in Intermediate (at **)n    in Parent (at **)', ); }); <ins> it('should correctly log Symbols', () => { const Component = ({children}) => { fakeConsole.warn('Symbol:', Symbol('')); return null; }; act(() => ReactDOM.render(<Component />, document.createElement('div'))); expect(mockWarn).toHaveBeenCalledTimes(1); expect(mockWarn.mock.calls[0][0]).toBe('Symbol:'); }); </ins> });

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:
// Relies on `updateStylesByID` not mutating `styleUpdates`. styleUpdates = nextProp; } <del> } else if (propKey === DANGEROUSLY_SET_INNER_HTML) { var lastHtml = lastProp && lastProp.__html; var nextHtml = nextProp && nextProp.__html; if (lastHtml !== nextHtml) { ReactComponent.DOMIDOperations.updateInnerHTMLByID( this._rootNodeID, nextProp ); } </del> } else if (registrationNames[propKey]) { putListener(this._rootNodeID, propKey, nextProp); } else if (

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:
// Relies on `updateStylesByID` not mutating `styleUpdates`. styleUpdates = nextProp; } <del> } else if (propKey === DANGEROUSLY_SET_INNER_HTML) { var lastHtml = lastProp && lastProp.__html; var nextHtml = nextProp && nextProp.__html; if (lastHtml !== nextHtml) { ReactComponent.DOMIDOperations.updateInnerHTMLByID( this._rootNodeID, nextProp ); } </del> } else if (registrationNames[propKey]) { putListener(this._rootNodeID, propKey, nextProp); } else if (

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:
runScripts = function() { var scripts = document.getElementsByTagName('script'); // Array.prototype.slice cannot be used on NodeList on IE8 var jsxScripts = []; for (var i = 0; i < scripts.length; i++) {

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:
For the remainder of this tutorial, we'll be writing our JavaScript code in this script tag. <ins> > Note: > > We included jQuery here because we want to simplify the code of our future ajax calls, but it's **NOT** mandatory for React to work. </ins> ### Your first component React is all about modular, composable components. For our comment box example, we'll have the following component structure:

Related discussion:
text: This may be controversial, but after browsing StackOverflow I believe there's way too many people that load jQuery when they really don't need it. Let's not add to that. I don't think we should be loading jQuery in the tutorial just to do an AJAX request. Let's instead have a dummy object that just returns a static list. Which could simply be replaced to implement AJAX loading. Old post (before I thought of just using static data): Let's replace it with standard XMLHttpRequest code and say something like "Here's some simple code for doing an AJAX request, alternatively you could use your favourite framework like jQuery, MooTools, YUI, ... instead". Having jQuery loaded in the tutorial may make people think that jQuery is necessary to use React.
I was thinking about this more and using a static list would probably be better than AJAX (given the tutorial just AJAX loads a static file). Updated the description to reflect this.
I think that would be fine. I would still put the equivalent jQuery call because that will be the inevitable question.
After reading pretty much everything related to this issue, I think it would be a good idea to add (for now) a little note in the tutorial, just under the code snippet having the jQuery inclusion. I think it's the only place it really needs to be. What do you think ? (So we can finally close this issue)
Agreed. A beginner tutorial isn't the place to debate jquery vs no jquery. The point is familiarity.
For what it's worth, I removed the use of jQuery in the ReactJS.NET version of the tutorial:
^ The note about jQuery not being mandatory got merged. I think this is good for now for newcomers. The react users probably already realized they don't actually need jQuery. Closing for now! =)
It dose not look very good when you are introducing new people to React and the first ting in the tutorial is: "We need to do some Ajax calls, let's just add jQuery".
Code change:
}, /** <del> * Updates a DOM node's innerHTML set by `props.dangerouslySetInnerHTML`. </del> <ins> * Updates a DOM node's innerHTML. </ins> * * @param {string} id ID of the node to update. <del> * @param {object} html An HTML object with the `__html` property. </del> <ins> * @param {string} html An HTML string. </ins> * @internal */ updateInnerHTMLByID: function(id, html) { var node = ReactMount.getNode(id); // HACK: IE8- normalize whitespace in innerHTML, removing leading spaces. // @see quirksmode.org/bugreports/archives/2004/11/innerhtml_and_t.html <del> node.innerHTML = (html && html.__html || '').replace(/^ /g, '&nbsp;'); </del> <ins> node.innerHTML = html.replace(LEADING_SPACE, '&nbsp;'); </ins> }, /**

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.