jiebi/CodeConvo huggingface dataset:
Change:
--- <ins> ### 4.27.8 May 17, 2023 #### Bugfixes * Fixed duplicated backend activation with multiple renderers ([hoxyq](https://github.com/hoxyq) in [#26807](https://github.com/facebook/react/pull/26807)) --- </ins> ### 4.27.7 May 4, 2023

Discussion:
local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.
Change:
return { memoizedState: hook.memoizedState, <del> baseState: hook.memoizedState, </del> <ins> baseState: hook.baseState, </ins> queue: hook.queue, baseUpdate: hook.baseUpdate,

Discussion:
Do you want to request a feature or report a bug? Report a bug What is the current behavior? There are cases where actions dispatched by 's dispatch function are reduced twice (in concurrent mode). As far as I can tell from my first quick read of the code of react-dom (so I might be totally wrong!), this happens, when a higher priority action is to a queue that already contains lower priority actions. On the first run, that is caused by for example an onClick handler (higher priority), the dispatched action is appended to the queue. On processing the queue the lower priority actions (for example from setInterval events) are ignored and the "onClick action" is reduced, but stays on the end of the queue, so that on the next time the queue is processed, that action gets reduced a second time. See a testcase at: Pressing the button increments the button (most of the time not always, depending if 'TICK' actions are in the queue) by two. What is the expected behavior? I'd expect a dispatched action to be only reduced once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with React 16.7.0-alpha.2 on Chrome (70.0.3538.110) and Safari (12.0.1) both on macOs
This does look like a bug. Want to dig into it?
I'd love to, but I am not sure I understand the implications on messing with the action queue, there are quit a lot of special cases and as I wrote that was my first read of any react implementation code :) Also it might take me a week or so, as I am pretty busy at the moment.
Actually I was wrong, the higher priority action should be reduced twice, the error is in where the memoizedState (action applied) overwrites the baseState (which should stay the last state before updates were skipped). I have a test that reproduced my bug and is fixed by correcting (while the other tests are still passing). I'll have that cleaned up tomorrow or Monday, so I'd take this issue.
Nice find :-)
Change:
"url": "https://github.com/facebook/react" }, "dependencies": { <del> "commoner": "~0.8.14", </del> <ins> "commoner": "~0.9.0", </ins> "esprima-fb": "~2001.1001.0-dev-harmony-fb", "jstransform": "~2.0.2" },

Discussion:
When I run jsx --watch src/ build/ it compiles the jsx files and create a file in the build directory. On the next jsx file modification, the jsx process crashes. Once the is present, jsx won't compile jsx files even when ran manually. I use OSX Maverick and jsx 0.8.13.
AFAIK this is a "bug" with or whatever JSX relies on to expose that feature. Just make sure to close the watch instance instead of just closing the terminal/powering down and it should be fine.
Does it work again if you remove the file?
Yes it does. Oh or wait, the crashing.
It seems like there are two ways of fixing this. We can either out why is not cleaning up the file when the process exits, or the functionality and just hope people don't accidentally have multiple processes targeting the same output directory. I'm pretty comfortable with option 2, honestly. Thoughts,
Yeah, no lock seems fine for me, it could warn if it was found perhaps? Another thing to mention that has been happening to me, I'm using React through a Linux VM and accessing the filesystem through samba. When saving a file it immediately triggers a recompile before the file has finished saving, causing it to error. Shortly after it recompiles it again, so no harm, but it's worth noting.
I'm fine with no locking. I didn't even know that existed. Do what works!
Change:
// logging too much when using transferPropsTo. warning( standardName == null, <del> 'Unknown DOM property ' + name + '. Did you mean ' + standardName + '?' </del> <ins> 'Unknown DOM property %s. Did you mean %s?', name, standardName </ins> ); };

Discussion:
Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks
Change:
} } <del> // For IE8 and IE9. </del> function handleEventsForInputEventIE( topLevelType, topLevelTarget,

Discussion:
Check: Tested in IE10. Likely related to .
We're having issues with this too and had to put in a workaround to deal with it. is this on your roadmap?
Having the same issue with on using IE 11.0.
I have the same issue as when adding a placeholder a textarea, with no value, the onChange event is fired.
I hava the same issue. A input with a placeholder and no value, the onChange event is fired.

See for example code. When setting and removing focus from an empty field with some text, the event is triggered for IE 11 (I have not tested older versions). It does not trigger for other browsers. My current work-around is to test the that was last passed to the input with what is returned by , and only act if they are different, but it would be nice if React would not send the change-event in the first place.
Sounds like a browser quark that we should normalize against, right? Is there anything other than value that we would need to check?
Yeah, this seems odd. Probably on the challenging side for a first bug, but it would be good to figure out why this is happening and how we can prevent it, while still making it possible to type the placeholder text in directly as says.
, not really related but I imagine both could be solved by a similar fix.
Also goes for IE10.
Change:
// events and have it go through ReactEventTopLevelCallback. Since it // doesn't, we manually listen for the propertychange event and so we // have to enqueue and process the abstract event manually. <del> EventPluginHub.enqueueAbstractEvents(abstractEvent); EventPluginHub.processAbstractEventQueue(); </del> <ins> EventPluginHub.enqueueEvents(abstractEvent); EventPluginHub.processEventQueue(); </ins> } } };

Discussion:
I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.
Change:
opacity: true, order: true, orphans: true, <ins> scale: true, </ins> tabSize: true, widows: true, zIndex: true,

Discussion:
we have property in css . In Plain JavaScript, we can directly pass a Number type and change the scale value like below scale:2.5 simulates the shorthand for transform: scale(2.5) Similarly I tried to do the Above in React, but it does not work as of now and only can work with string, the fix i took is adding it as a unitless Number in the file since it accepts the css properties accepting number , doing the same and running the fixtures standalone file , it is working the way as i expected Before the changes https://user- After the changes https://user-
cc
Change:
selection.removeAllRanges(); selection.addRange(range); clipboard.writeText(event.target.textContent); <ins> const $promptDiv = $("#box-content-prompt"); const $confirmationDiv = $("#box-content-confirmation"); </ins> $promptDiv.classList.add('hidden'); $confirmationDiv.classList.remove('hidden');

Discussion:
Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!
Change:
itemRef: MUST_USE_ATTRIBUTE, // property is supported for OpenGraph in meta tags. property: null, <ins> // IE-only attribute that specifies security restrictions on an iframe // as an alternative to the sandbox attribute on IE<10 security: MUST_USE_ATTRIBUTE, </ins> // IE-only attribute that controls focus behavior unselectable: MUST_USE_ATTRIBUTE, },

Discussion:
The attribute allows for restrictions to be placed on iframes, regardless of domain. It's useful if you're dealing with IE versions less than 10 that don't have the attribute. More info: (v=vs.85).aspx
Change:
} if (propKey === STYLE) { if (nextProp) { <ins> if (__DEV__) { checkAndWarnForMutatedStyle( this._previousStyleCopy, this._previousStyle, this ); this._previousStyle = nextProp; } </ins> nextProp = this._previousStyleCopy = assign({}, nextProp); } if (lastProp) {

Discussion:
Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.
Change:
"manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Chrome Developer Tools.", <del> "version": "5.3.1", "version_name": "5.3.1", </del> <ins> "version": "6.0.0", "version_name": "6.0.0", </ins> "minimum_chrome_version": "102", "icons": { "16": "icons/16-production.png",

Discussion:
development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0
Change:
var fakeNode = document.createElement('react'); ReactErrorUtils.invokeGuardedCallback = function(name, func, a, b) { var boundFunc = func.bind(null, a, b); <del> fakeNode.addEventListener(name, boundFunc, false); </del> <ins> var evtType = `react-${name}`; fakeNode.addEventListener(evtType, boundFunc, false); </ins> var evt = document.createEvent('Event'); <del> evt.initEvent(name, false, false); </del> <ins> evt.initEvent(evtType, false, false); </ins> fakeNode.dispatchEvent(evt); <del> fakeNode.removeEventListener(name, boundFunc, false); </del> <ins> fakeNode.removeEventListener(evtType, boundFunc, false); </ins> }; } }

Discussion:
Count up with 0.14.0 But can't count up 0.14.1 I got this issue on IE 10 and 11 + Windows 8, 7. And Windows 10 + IE 11 is move fine.
:+1: I'm seeing the same issue when I use react-dom 0.14.1
:+1: same
cc seems bad.
Fix incoming. Worth noting (as reminded me) that this is only an issue in dev mode.
:+1:
:+1: Makes our app difficult to test on Windows 7 / 8. I can confirm that switching to production mode does resolve it for us.
Yea sorry about the issues, we'll be shipping 0.14.2 tomorrow with this fixed.
:+1:
Is this related only to anchor tags, or other elements as well? I've seen this when applying onClick to div elements as well as anchors in IE10 and IE11.
All elements.
Change:
<del> module React module Source def self.bundled_path_for(build) File.expand_path("../../../build/#{build}", __FILE__) end end end </del>

Discussion:
I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)
Change:
```css .example-leave { <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> transition: opacity .5s ease-in; }

Discussion:
Hello, Today I have spotted the bug(?) in IE10/IE11: while setting the inner HTML on any element (, , ) using property the browser will raise an error . I use this with SSR, but the actual HTML received from the server is good, so probably there's a problem with func. Some code: where is some string that contains HTML. !
Hey! This was fixed in and is a known issue. A fix should be out in the next release. However thank you for the great write up!
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.
Hi Dan, everything is working now, thank you!
Change:
); } }); <ins> JQueryMobilePage = React.createFactory(JQueryMobilePage); </ins> /** Application page one component. */ var PageOneContent = React.createClass({

Discussion:
When I run the in examples jquery-mobile in the chromium browser, I get: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of (anonymous function)
I can confirm. Works fine with React version “0.12.2", but "0.13.0-alpha.2" gives: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of undefined ReactClass.createClass.Constructor (anonymous function) The jquery-mobile example is using component constructors in a way which makes the new version explode. gaearon lays is out here:
We'll make sure all the examples are working before we release 0.13 final but until then there's a non-trivial change they'll be broken at any point in time. Check out the latest stable branch for the working examples.
Change:
// Most of the real functionality is covered in other unit tests, this just // makes sure we're wired up correctly. describe('ReactTransitionGroup', function() { <ins> var container; </ins> beforeEach(function() { React = require('React'); ReactTransitionGroup = require('ReactTransitionGroup'); mocks = require('mocks'); <ins> container = document.createElement('div'); </ins> }); it('should warn after time with no transitionend', function() { <del> var container; var a; container = document.createElement('div'); a = React.renderComponent( </del> <ins> var a = React.renderComponent( </ins> <ReactTransitionGroup transitionName="yolo"> <span key="one" id="one" /> </ReactTransitionGroup>,

Discussion:
Consider this example: If is false or undefined, will be and will throw
Want to take a go at fixing this? I think it would be a good opportunity to learn a bit more about a constrained subset of internals.
yea - i'll give it a shot :)
Change:
// componentDidUpdate) but we need to check here too in order to catch // updates enqueued by setState callbacks. while (dirtyComponents.length) { <ins> var allUnmounted = true; for (var i = 0, l = dirtyComponents.length; i < l; i++) { if (dirtyComponents[i].isMounted()) { allUnmounted = false; break; } } if (allUnmounted) { // All the "dirty" components are unmounted, which probably means that // they were marked dirty due to setState calls in componentWillMount // handlers and the components are currently in the process of mounting. // `runBatchedUpdates` will be a noop. In that case, initializing the // DOM-dependent ReactReconcileTransaction is thus not what we want to // do, especially when using server rendering, so we skip it. dirtyComponents.length = 0; return; } </ins> var transaction = ReactUpdatesFlushTransaction.getPooled(); transaction.perform(runBatchedUpdates, null, transaction); ReactUpdatesFlushTransaction.release(transaction);

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

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? is never set to true when calling within , but it does work properly when within a . Here's the correct behavior (accomplished via ): ! Here's the incorrect behavior (via ): ! Note the difference is that the opacity never changes to 0.4 (which is determined based on the state). What is the expected behavior? I expect them to both behave the same (at least as far as the user can observe). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? react react-dom
I guess startTransition is never intended to be used in effects. I didn't expect it even works. Looking at the doc again, Hmm, it doesn't clearly say so.
Ok but the use cases is interesting.
Do you think this is the same as
Yes, I believe that's the same issue.
Hello, I think I have a similar issue when using with . When returns a new value I would like to create a new resource. I tried to use for this, but I don't even have an idea where to put ...
you can see the isPending is if the is bigger than 5100 when calling in .
I'm seeing the same behavior as - setting to a value of 5200 or higher causes to fire reliably in the original CodeSandbox:
That is a bug we need to fix regardless.
Fixed by . Updated Sandbox:
Change:
Dev build with warnings: <https://fb.me/react-dom-0.14.0-rc1.js> Minified build for production: <https://fb.me/react-dom-0.14.0-rc1.min.js> <del> These builds are also available in the `react` and `react-dom` packages on bower. </del> <ins> These builds are also available in the `react` package on bower. </ins> ## Changelog

Discussion:
I tried doing the following to pick up react-dom: However, it said that the only version available was Poking around on Github yielded a repo called that appears to be linked to Bower. I'm guessing this isn't the right library; what's the dependency installation story going to look like with Bower?
Never mind, just found that it shipped in the same package. However, the documentation is misleading on the :
Thanks, we should fix that.
Change:
*/ getValue: function(input) { if (input.props.valueLink) { <del> _assertLink(input); </del> <ins> _assertValueLink(input); </ins> return input.props.valueLink.value; } return input.props.value;

Discussion:
When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?