jiebi/CodeConvo huggingface dataset:
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: 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:
'use strict'; <ins> var path = require("path"); </ins> var grunt = require("grunt"); var expand = grunt.file.expand; var spawn = grunt.util.spawn;

Related discussion:
text: H:githubreactgrunt Running "delete-build-modules" task Running "jsx:normal" (jsx) task Warning: This socket is closed. Use --force to continue. Aborted due to warnings. on windows. any hint?
The issue arises in the jsx task at line 42: File: [no files] Warning: This socket is closed. Use --force to continue. Error: This socket is closed. at () at doWrite () at writeOrBuffer () at () at () at (c:reactgrunttasks) at Object.<anonymous(c:reactnodemodulesgruntlibgrunt) at (c:reactnodemodulesgruntlibgrunt) at Object.<anonymous(c:reactnodemodulesgruntlibutil) at Task.runTaskFn (c:reactnode_modulesgruntlibutil) var child = spawn({ cmd: "bin/jsx-internal", args: args }, function(error, result, code) { if (error) { (error); done(false); } else { done(); } }); (JSON.stringify(config.getConfig())); So, looks like the spawn child's input stream is not available. Running node bin/jsx-internal" works however, get a message saying "Warning: still waiting for STDIN after 1000ms"
- can you take a look?
I was able to work around this by changing the following in grunttasks to Obviously this change is Windows-only but does provide a possible workaround.
What about changing it to
Yes, I can verify that worked on my machine. Sorry, I used some leftover code for executing batch files which requires going through cmd.
Cool, I can put up a PR for that (unless you have the time,
Sure, I can do that. Thanks for the help!
Code change:
continue; } if (__DEV__) { <del> if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } else if (badVendoredStyleNamePattern.test(styleName)) { warnBadVendoredStyleName(styleName); } </del> <ins> warnValidStyle(styleName, styles[styleName]); </ins> } var styleValue = dangerousStyleValue(styleName, styles[styleName]); if (styleName === 'float') {

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:
topKeyUp:       eventTypes.keyUp, topMouseDown:   eventTypes.mouseDown, topMouseMove:   eventTypes.mouseMove, <ins> topMouseOut:    eventTypes.mouseOut, topMouseOver:   eventTypes.mouseOver, </ins> topMouseUp:     eventTypes.mouseUp, topPaste:       eventTypes.paste, topScroll:      eventTypes.scroll,

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:
topKeyUp:       eventTypes.keyUp, topMouseDown:   eventTypes.mouseDown, topMouseMove:   eventTypes.mouseMove, <ins> topMouseOut:    eventTypes.mouseOut, topMouseOver:   eventTypes.mouseOver, </ins> topMouseUp:     eventTypes.mouseUp, topPaste:       eventTypes.paste, topScroll:      eventTypes.scroll,

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:
captured: keyOf({onMouseMoveCapture: true}) } }, <ins> mouseOut: { phasedRegistrationNames: { bubbled: keyOf({onMouseOut: true}), captured: keyOf({onMouseOutCapture: true}) } }, mouseOver: { phasedRegistrationNames: { bubbled: keyOf({onMouseOver: true}), captured: keyOf({onMouseOverCapture: true}) } }, </ins> mouseUp: { phasedRegistrationNames: { bubbled: keyOf({onMouseUp: true}),

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:
captured: keyOf({onMouseMoveCapture: true}) } }, <ins> mouseOut: { phasedRegistrationNames: { bubbled: keyOf({onMouseOut: true}), captured: keyOf({onMouseOutCapture: true}) } }, mouseOver: { phasedRegistrationNames: { bubbled: keyOf({onMouseOver: true}), captured: keyOf({onMouseOverCapture: true}) } }, </ins> mouseUp: { phasedRegistrationNames: { bubbled: keyOf({onMouseUp: true}),

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:
*/ var textContentAccessor = getTextContentAccessor() || 'NA'; <ins> var LEADING_SPACE = /^ /; </ins> /** * Operations used to process updates to DOM nodes. This is made injectable via * `ReactComponent.DOMIDOperations`.

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:
*/ var textContentAccessor = getTextContentAccessor() || 'NA'; <ins> var LEADING_SPACE = /^ /; </ins> /** * Operations used to process updates to DOM nodes. This is made injectable via * `ReactComponent.DOMIDOperations`.

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:
args.push("--config" /* from stdin */); var child = spawn({ <del> cmd: "bin/jsx-internal", args: args </del> <ins> cmd: "node", args: [path.join("bin", "jsx-internal")].concat(args) </ins> }, function(error, result, code) { if (error) { grunt.log.error(error);

Related discussion:
text: H:githubreactgrunt Running "delete-build-modules" task Running "jsx:normal" (jsx) task Warning: This socket is closed. Use --force to continue. Aborted due to warnings. on windows. any hint?
The issue arises in the jsx task at line 42: File: [no files] Warning: This socket is closed. Use --force to continue. Error: This socket is closed. at () at doWrite () at writeOrBuffer () at () at () at (c:reactgrunttasks) at Object.<anonymous(c:reactnodemodulesgruntlibgrunt) at (c:reactnodemodulesgruntlibgrunt) at Object.<anonymous(c:reactnodemodulesgruntlibutil) at Task.runTaskFn (c:reactnode_modulesgruntlibutil) var child = spawn({ cmd: "bin/jsx-internal", args: args }, function(error, result, code) { if (error) { (error); done(false); } else { done(); } }); (JSON.stringify(config.getConfig())); So, looks like the spawn child's input stream is not available. Running node bin/jsx-internal" works however, get a message saying "Warning: still waiting for STDIN after 1000ms"
- can you take a look?
I was able to work around this by changing the following in grunttasks to Obviously this change is Windows-only but does provide a possible workaround.
What about changing it to
Yes, I can verify that worked on my machine. Sorry, I used some leftover code for executing batch files which requires going through cmd.
Cool, I can put up a PR for that (unless you have the time,
Sure, I can do that. Thanks for the help!
Code change:
expect(console.warn.argsForCall[1][0]).toContain('WebkitTransform'); }); <ins> it('should warn about style having a trailing semicolon', function() { spyOn(console, 'warn'); CSSPropertyOperations.createMarkupForStyles({ fontFamily: 'Helvetica, arial', backgroundImage: 'url(foo;bar)', backgroundColor: 'blue;', color: 'red;   ' }); expect(console.warn.callCount).toBe(2); expect(console.warn.argsForCall[0][0]).toContain('Try "backgroundColor: blue" instead'); expect(console.warn.argsForCall[1][0]).toContain('Try "color: red" instead'); }); </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.