jiebi/CodeConvo huggingface dataset:
Change:
} export function utfDecodeString(array: Array<number>): string { <del> return String.fromCodePoint(...array); </del> <ins> // Avoid spreading the array (e.g. String.fromCodePoint(...array)) // Functions arguments are first placed on the stack before the function is called // which throws a RangeError for large arrays. // See github.com/facebook/react/issues/22293 let string = ''; for (let i = 0; i < array.length; i++) { const char = array[i]; string += String.fromCodePoint(char); } return string; </ins> } export function utfEncodeString(string: string): Array<number> {

Discussion:
I encountered the same issue as but using as a stand-alone app instead of from the the browser. The bottom line is that the profiler becomes unresponsive after any interaction with a heavily loaded react page. React version: React: 17.0.2 ReactDOM: 17.0.2 React Devtools: 4.18.0 a react-devtools stand-alone () to a session profiling something on your app that would cause a huge number of updates profiler stops functioning I actually went through and found out the origin of the issue, however I am not sure what would be the best approach to fix it. It seems the the origin is a (very) big incoming message: <img width="516" alt="image" src="https://user-"That eventually causes a maximum call stack exceeded error: <img width="522" alt="image" src="https://user-"Coming from : And interestingly enough, doing spread operator with an array with elements actually causes a error I tried replacing the code above with the following replacement and it seems to work:
Can you share a repro case with me please? I'd love to verify the fix (and if possible maybe even add an automated regression test– although this might not be possible, given the underlying problem seems to be with the generated code not the source code).
That is interesting! I don't think this is true for the native spread operator. For example, this runs okay for me in Chrome: I'm pretty sure this has to do with the code that's generated in the build (for backwards compat): This throws as you describe:
Actually I think this depends on the function. Indeed your array example works as expected, but try this: For me it fails natively on chrome EDIT: I just realised you are doing a spread operator on an array. This is trivially translated into a call and the stack is not used. However if you try to use the spread operation in a function call, all the function arguments must be first placed on stack before the function is called (per standard JS function call procedure). This means that if the array is big enough, you will exhaust your stack. Unfortunately my project structure is pretty complex to identify just one possible code path that is causing that issue. My best guess is that it's happening when I am replacing (un-mounting and re-mounting) a couple of thousand of child elements at once.

I can try to isolate a reproducible example it but it will take some time... If it suits you though, I can easily give you a JSON dump of the contents of the said "operations" event that caused the exception.
Nice follow up information! Thanks! Fair enough. I think we can proceed without a repro in this case.
Change:
<div className={styles.LeftColumn}> <div className={styles.Toolbar}> <RecordToggle disabled={!supportsProfiling} /> <del> <ReloadAndProfileButton disabled={selectedTabID === 'timeline' || !supportsProfiling} /> </del> <ins> <ReloadAndProfileButton disabled={!supportsProfiling} /> </ins> <ClearProfilingDataButton /> <ProfilingImportExportButtons /> <div className={styles.VRule} />

Discussion:
(local development) "Reload and profile" is enabled for Flamegraph: <img width="724" alt="Screenshot 2022-05-23 at 21 28 07" src="https://user-"But disabled for Timeline: <img width="671" alt="Screenshot 2022-05-23 at 21 28 12" src="https://user-"And yet I can "reload and profile" in Flamegraph, then switch to Timeline and it works. So this doesn't add up. Every time No response No response No response No response No response No response
Maybe related, a "reloaded" Timeline profile appears too much shifted to the left and thus a bit borked. See overlap in the left side. <img width="963" alt="Screenshot 2022-05-23 at 21 31 57" src="https://user-"
Just wanna confirm, by "borked" you mean some information is covered up? If so, does scrolling and dragging help?
Oh I see, that's just existing behavior. If I zoom in, then it helps, yea. So let's ignore that part.
Change:
}, ); <del> if (__DEV__) { // Getting the name for the warning cause the loading to start early. expect(Scheduler).toHaveYielded(['Started loading']); expect(Scheduler).toFlushAndYield(['Loading...']); } else { expect(Scheduler).toFlushAndYield(['Started loading', 'Loading...']); } </del> <ins> expect(Scheduler).toFlushAndYield(['Started loading', 'Loading...']); </ins> expect(root).not.toMatchRenderedOutput(<div>AB</div>); await Promise.resolve();

Discussion:
<!-- 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: 17.0.0-rc.1 elements out of components, use them conditionally. if the components are dynamically imported. <!-- 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: -- : : : : : <!-- 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: --The chunk is imported eagerly, even though the component isn't immediately rendered. ! This doesn't happen in prod mode, or with React 16, or with components that are not -ed eagerly. This affects react-router, as it uses this pattern: AFAICT it doesn't break anything, but it is unexpected/confusing. components that are not rendered should not be dynamically imported.
Shorter test case: This is enough to trigger the dynamic import in dev mode.
Behavior changed between 16.13.1 and the first release after . ! !
This is triggered by in . I think this doesn't really make sense to call but we'd need to see why this change to was made. <img width="398" alt="Screenshot 2020-09-03 at 13 56 14" src="https://user-"<img width="367" alt="Screenshot 2020-09-03 at 13 56 18" src="https://user-"
The suspense protocol is just a function that may throw. That allows for low overhead abstractions to be wrapped. This change was to allow the init function to encapsulate the actual suspense mechanism and that data structure. Unfortunately there’s no way to query the status of something in the suspense protocol without triggering the fetch. Same as you can’t do: Without triggering a fetch. The solution might be to move validation of lazy until it’s rendered instead of in createElement. Also, sigh PropTypes.

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.
Change:
"url": "https://github.com/facebook/react" }, "dependencies": { <del> "commoner": "~0.9.1", </del> <ins> "commoner": "^0.9.2", </ins> "esprima-fb": "~3001.1.0-dev-harmony-fb", "jstransform": "~3.0.0" },

Discussion:
I am getting this error when I run jsx. Is this happening to anybody else? Am I doing something wrong?
version, how are you running it, any details to help repro? cc - this is in commoner.
Thanks for the quick reply. It happened on 0.8, 0.9 and 0.10.0-rc1. I just ran it like this. Also, if I run it on a file, like this. It works. But not when I run it against a whole directory.
Thanks a lot for the report. Looks like has updated commoner and I'm sure he'll update our dependency here as soon as he pushes that to npm.
Hey guys, thanks for the quick response, and thanks for all the good work :+1:
mysql I aslo encounter this problem today
Just in case you still have an old version of the dependency installed, you can do
Change:
ReactNoop.flush(); expect(ReactNoop.getChildren()).toEqual([span('Count: 8')]); }); <ins> // Regression test for https://github.com/facebook/react/issues/14360 it('handles dispatches with mixed priorities', () => { const INCREMENT = 'INCREMENT'; function reducer(state, action) { return action === INCREMENT ? state + 1 : state; } function Counter(props, ref) { const [count, dispatch] = useReducer(reducer, 0); useImperativeMethods(ref, () => ({dispatch})); return <Text text={'Count: ' + count} />; } Counter = forwardRef(Counter); const counter = React.createRef(null); ReactNoop.render(<Counter ref={counter} />); ReactNoop.flush(); expect(ReactNoop.getChildren()).toEqual([span('Count: 0')]); counter.current.dispatch(INCREMENT); counter.current.dispatch(INCREMENT); counter.current.dispatch(INCREMENT); ReactNoop.flushSync(() => { counter.current.dispatch(INCREMENT); }); expect(ReactNoop.getChildren()).toEqual([span('Count: 1')]); ReactNoop.flush(); expect(ReactNoop.getChildren()).toEqual([span('Count: 4')]); }); </ins> }); describe('useEffect', () => {

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:
}; onProfilingStatus: (isProfiling: boolean) => void = isProfiling => { <ins> if (this._isProfiling === isProfiling) { return; } </ins> if (isProfiling) { this._dataBackends.splice(0); this._dataFrontend = null;

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

debugging my nextjs project to find out which component is slowing down my application by using react devtools profiler section. when i start recording by clcking the blue button it start recording. then when go to my page and navigate different page like first i sign in to my application and then navigate from home to my when i stop the recording this error occured. Every time react-devtools-extensions 2- Could not find node with id "464" in commit tree
best of luck
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:
// The signature call is split in two parts. One part is called inside the function. // This is used to signal when first render happens. <ins> if (path.node.body.type !== 'BlockStatement') { path.node.body = t.blockStatement([ t.returnStatement(path.node.body), ]); } </ins> path .get('body') .unshiftContainer(

Discussion:
Using 0.4.0 is giving me this error on a large number of files: I narrowed down that file to the simplest thing that causes it: Originally posted by in
Fixed in 0.4.1
Change:
}, "homepage": "https://reactjs.org/", "peerDependencies": { <del> "eslint": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0" </del> <ins> "eslint": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" </ins> }, "devDependencies": { "@typescript-eslint/parser": "^2.26.0"

Discussion:
eslint yesterday. gets a peerDependency warning: Ensure compatibility with the newly released major and add to .
Oh I just realized is coming from another repo: Will open an issue there as well and edit this one.
Change:
<ins> let React; let ReactNoop; let Scheduler; let useState; let useEffect; describe('ReactFlushSync', () => { beforeEach(() => { jest.resetModules(); React = require('react'); ReactNoop = require('react-noop-renderer'); Scheduler = require('scheduler'); useState = React.useState; useEffect = React.useEffect; }); function Text({text}) { Scheduler.unstable_yieldValue(text); return text; } test('changes priority of updates in useEffect', async () => { function App() { const [syncState, setSyncState] = useState(0); const [state, setState] = useState(0); useEffect(() => { if (syncState !== 1) { setState(1); ReactNoop.flushSync(() => setSyncState(1)); } }, [syncState, state]); return <Text text={`${syncState}, ${state}`} />; } const root = ReactNoop.createRoot(); await ReactNoop.act(async () => { root.render(<App />); // This will yield right before the passive effect fires expect(Scheduler).toFlushUntilNextPaint(['0, 0']); // The passive effect will schedule a sync update and a normal update. // They should commit in two separate batches. First the sync one. expect(() => expect(Scheduler).toFlushUntilNextPaint(['1, 0']), ).toErrorDev('flushSync was called from inside a lifecycle method'); // The remaining update is not sync ReactNoop.flushSync(); expect(Scheduler).toHaveYielded([]); // Now flush it. expect(Scheduler).toFlushUntilNextPaint(['1, 1']); }); expect(root).toMatchRenderedOutput('1, 1'); }); }); </ins>

Discussion:
flushSync early returns if it detects it's in the commit (or render) phase, since it can't synchronously flush when React is already working. However, it should still change the priority of updates scheduled by the callback to be synchronous. This mostly already works because the commit phase itself has a sync event priority context, but the passive effect phase doesn't. Need more tests for this.
Change:
```javascript render() { return [ <del> <li key="A"/>First item</li>, <li key="B"/>Second item</li>, <li key="C"/>Third item</li>, </del> <ins> <li key="A">First item</li>, <li key="B">Second item</li>, <li key="C">Third item</li>, </ins> ]; } ```

Discussion:
Do you want to request a feature or report a bug? bug What is the current behavior? In the render Fragments example, the JSX tag is closed prematurely. 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: ). — What is the expected behavior? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.0.0 documentation website on Chrome Android. Previously array Fragments weren't supported.
Change:
style: '`style` must be set using `updateStylesByID()`.' }; <del> /** * The DOM property to use when setting text content. * * @type {string} * @private */ var textContentAccessor = getTextContentAccessor(); </del> var useWhitespaceWorkaround; /**

Discussion:
On re-render, we innerText. This causes inconsistencies in rendering whitespace. See demo: We should make sure this doesn't happen.
We switched to use but it broke some contentEditable stuff internal to FB. knows more.
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer
looks like this was brought up in
Right, we should also do the right thing in IE8.
jQuery empties then adds a text node. Relevant commits: ()
okay interesting. I'll do this for ie8
I have a patch almost ready.
I'm curious if is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML.
hmm interesting. We definitely want to preserve whitespace though. (because of and and )
Change:
throwOnInvalidObjectType(returnFiber, newChild); } <ins> if (__DEV__) { const disableNewFiberFeatures = ReactFeatureFlags.disableNewFiberFeatures; if (!disableNewFiberFeatures && typeof newChild === 'function') { warnOnFunctionType(); } } </ins> return null; }

Discussion:
When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.
Change:
{ "name": "react-devtools", <del> "version": "4.27.7", </del> <ins> "version": "4.27.8", </ins> "description": "Use react-devtools outside of the browser", "license": "MIT", "repository": {

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:
* @protected */ setState: function(partialState, callback) { <ins> invariant( typeof partialState === 'object' || partialState == null, 'setState(...): takes an object of state variables to update.' ); if (__DEV__){ if (partialState == null) { console.warn( 'setState(...): You passed an undefined or null state object; ' + 'instead, use forceUpdate().' ); } } </ins> // Merge with `_pendingState` if it exists, otherwise with existing state. this.replaceState( merge(this._pendingState || this.state, partialState),

Discussion:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.