Question:
} });  it('does not show a fallback if mismatch is after suspending', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child() { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return 'Hello'; } } function Component({shouldMismatch}) { Scheduler.log('Component'); if (shouldMismatch && client) { return
Mismatch
; } return
Component
; } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Child /> <Component shouldMismatch={true} /> </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Hello', 'Component']); expect(container.innerHTML).toBe( 'Hello
Component
', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll(['Suspend']); jest.runAllTimers(); // !! Unchanged, continue showing server content while suspended. expect(container.innerHTML).toBe( 'Hello
Component
', ); suspend = false; resolve(); await promise; await waitForAll([ // first pass, mismatches at end 'Hello', 'Component', 'Hello', 'Component', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // Client rendered - suspense comment nodes removed. expect(container.innerHTML).toBe('Hello
Mismatch
'); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'section', 'n' + '    in article (at **)n' + '    in Component (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } }); it('does not show a fallback if mismatch is child of suspended component', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child({children}) { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return
{children}
; } } function Component({shouldMismatch}) { Scheduler.log('Component'); if (shouldMismatch && client) { return
Mismatch
; } return
Component
; } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Child> <Component shouldMismatch={true} /> </Child> </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Hello', 'Component']); expect(container.innerHTML).toBe( '

Component

', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll(['Suspend']); jest.runAllTimers(); // !! Unchanged, continue showing server content while suspended. expect(container.innerHTML).toBe( '

Component

', ); suspend = false; resolve(); await promise; await waitForAll([ // first pass, mismatches at end 'Hello', 'Component', 'Hello', 'Component', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // Client rendered - suspense comment nodes removed expect(container.innerHTML).toBe( '

Mismatch

', ); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'div', 'n' + '    in article (at **)n' + '    in Component (at **)n' + '    in div (at **)n' + '    in Child (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } }); it('does not show a fallback if mismatch is parent and first child suspends', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child({children}) { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return
{children}
; } } function Component({shouldMismatch, children}) { Scheduler.log('Component'); if (shouldMismatch && client) { return (
 {children}
Mismatch

 ); } return (
 {children}
Component

 ); } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Component shouldMismatch={true}> <Child /> </Component> </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Component', 'Hello']); expect(container.innerHTML).toBe( '

Component

', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll(['Component', 'Suspend']); jest.runAllTimers(); // !! Unchanged, continue showing server content while suspended. expect(container.innerHTML).toBe( '

Component

', ); suspend = false; resolve(); await promise; await waitForAll([ // first pass, mismatches at end 'Component', 'Hello', 'Component', 'Hello', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // Client rendered - suspense comment nodes removed expect(container.innerHTML).toBe( '

Mismatch

', ); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'div', 'n' + '    in article (at **)n' + '    in div (at **)n' + '    in Component (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } }); it('does show a fallback if mismatch is parent and second child suspends', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child({children}) { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return
{children}
; } } function Component({shouldMismatch, children}) { Scheduler.log('Component'); if (shouldMismatch && client) { return (

Mismatch
 {children}
 ); } return (

Component
 {children}
 ); } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Component shouldMismatch={true}> <Child /> </Component> </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Component', 'Hello']); expect(container.innerHTML).toBe( '

Component

', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll([ 'Component', 'Component', 'Suspend', 'Fallback', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // !! Client switches to suspense fallback. expect(container.innerHTML).toBe('Loading...'); suspend = false; resolve(); await promise; await waitForAll(['Component', 'Hello']); jest.runAllTimers(); // Client rendered - suspense comment nodes removed expect(container.innerHTML).toBe( '

Mismatch

', ); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'div', 'n' + '    in article (at **)n' + '    in div (at **)n' + '    in Component (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } }); it('does show a fallback if mismatch is in parent element only', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child({children}) { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return
{children}
; } } function Component({shouldMismatch, children}) { Scheduler.log('Component'); if (shouldMismatch && client) { return
{children}
; } return
{children}
; } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Component shouldMismatch={true}> <Child /> </Component> </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Component', 'Hello']); expect(container.innerHTML).toBe( '

', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll([ 'Component', 'Component', 'Suspend', 'Fallback', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // !! Client switches to suspense fallback. expect(container.innerHTML).toBe('Loading...'); suspend = false; resolve(); await promise; await waitForAll(['Component', 'Hello']); jest.runAllTimers(); // Client rendered - suspense comment nodes removed expect(container.innerHTML).toBe('

'); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'section', 'n' + '    in article (at **)n' + '    in Component (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } }); it('does show a fallback if mismatch is before suspending', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child() { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return 'Hello'; } } function Component({shouldMismatch}) { Scheduler.log('Component'); if (shouldMismatch && client) { return
Mismatch
; } return
Component
; } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Component shouldMismatch={true} /> <Child /> </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Component', 'Hello']); expect(container.innerHTML).toBe( '
Component
Hello', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll([ 'Component', 'Component', 'Suspend', 'Fallback', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // !! Client switches to suspense fallback. expect(container.innerHTML).toBe('Loading...'); suspend = false; resolve(); await promise; await waitForAll([ // first pass, mismatches at end 'Component', 'Hello', ]); jest.runAllTimers(); // Client rendered - suspense comment nodes removed expect(container.innerHTML).toBe('
Mismatch
Hello'); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'section', 'n' + '    in article (at **)n' + '    in Component (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } }); it('does show a fallback if mismatch is before suspending in a child', async () => { // We can't use the toErrorDev helper here because this is async. const originalConsoleError = console.error; const mockError = jest.fn(); console.error = (...args) => { mockError(...args.map(normalizeCodeLocInfo)); }; let client = false; let suspend = false; let resolve; const promise = new Promise(resolvePromise => { resolve = () => { suspend = false; resolvePromise(); }; }); function Child() { if (suspend) { Scheduler.log('Suspend'); throw promise; } else { Scheduler.log('Hello'); return 'Hello'; } } function Component({shouldMismatch}) { Scheduler.log('Component'); if (shouldMismatch && client) { return
Mismatch
; } return
Component
; } function Fallback() { Scheduler.log('Fallback'); return 'Loading...'; } function App() { return ( <Suspense fallback={<Fallback />}> <Component shouldMismatch={true} />
 <Child />
 </Suspense> ); } try { const finalHTML = ReactDOMServer.renderToString(<App />); const container = document.createElement('section'); container.innerHTML = finalHTML; assertLog(['Component', 'Hello']); expect(container.innerHTML).toBe( '
Component

Hello
', ); suspend = true; client = true; ReactDOMClient.hydrateRoot(container, <App />, { onRecoverableError(error) { Scheduler.log(error.message); }, }); await waitForAll([ 'Component', 'Component', 'Suspend', 'Fallback', 'Hydration failed because the initial UI does not match what was rendered on the server.', 'There was an error while hydrating this Suspense boundary. Switched to client rendering.', ]); jest.runAllTimers(); // !! Client switches to suspense fallback. expect(container.innerHTML).toBe('Loading...'); suspend = false; resolve(); await promise; await waitForAll([ // first pass, mismatches at end 'Component', 'Hello', ]); jest.runAllTimers(); // Client rendered - suspense comment nodes removed. expect(container.innerHTML).toBe( '
Mismatch

Hello
', ); if (__DEV__) { const secondToLastCall = mockError.mock.calls[mockError.mock.calls.length - 2]; expect(secondToLastCall).toEqual([ 'Warning: Expected server HTML to contain a matching <%s> in <%s>.%s', 'article', 'section', 'n' + '    in article (at **)n' + '    in Component (at **)n' + '    in Suspense (at **)n' + '    in App (at **)', ]); } } finally { console.error = originalConsoleError; } });  it('calls the hydration callbacks after hydration or deletion', async () => { let suspend = false; let resolve;

React version: 18.2.0 a tiny app that uses + suspends during hydration + has a hydration mismatch, for example: (Full code in ) the app and observe that the suspense fallback is never mounted , wrap the element with a : () the app and observe that the suspense fallback is now mounted Code example: · The fallback is rendered inconsistently – depending on whether the element that suspends is wrapped with a ?! The fallback is rendered either never, or always, no matter if the element that suspends is wrapped with anything.
Spent a bunch of time debugging this, and I think I understand what’s causing this. Let’s say we’re trying to hydrate the following tree: Here’s why the bug happens: hydrating the tree, React enters the and starts walking its children. At some point, it walks over the node – and encounters a hydration mismatch. This causes React to find the nearest suspense boundary and . (Later, and switches the boundary to client-side rendering, .) , after setting the flag, React does not switch the to client rendering immediately. Instead, it walks the remaining siblings (in this case, two s and ) and then exits the subtree. is where the inconsistency lies. In the normal case (without ), React finishes walking all siblings, walks back up to , realizes that has set, and client-renders again from scratch. However, if one of the siblings React walks over () suspends, React . This effectively disables mismatch handling (until later) – instead, suspends, as if there was no hydration mismatch. And because it’s still hydrating, Suspense keeps the server HTML instead of rendering the fallback. This behavior disappears if lives in another part of the tree (not in direct siblings): With this tree, React won’t walk over (because it’s inside a sibling, and React won’t enter siblings after it encountered a hydration error). This means React will follow the normal code path → re-render the Suspense boundary from scratch instead of hydrating it → suspend that boundary when it finally encounters → and render the Suspense fallback. a result, if is a direct sibling to the hydration mismatch, React will keep the server HTML until the component unsuspends. If it’s not, React will render the Suspense fallback.

This is (imo) the bug: React’s behavior shouldn’t depend on where inside the boundary the hydration mismatch happens. Just from the code perspective, it feels easier/cheaper to keep the “normal” case – always resetting the boundary if there’s a hydration mismatch. This also matches that says that is rerendered from scratch on a mismatch – this is good because every edge case is an overhead that devs need to learn. But from the UX perspective, I’d maybe prefer React to keep the server HTML until the boundary unsuspends? If we keep the server HTML, the UI will go through two states: Server HTML → Client HTML. Both of these should be similar, despite a minor hydration mismatch. If we reset the boundary, the UI will jump through Server HTML → “Loading...” fallback → Client HTML, which feels like a worse UX. IDK, feels like a hard choice to make (good thing it’s not mine I guess ^_^)
Sorry for the direct ping – I see you referenced this bug in some other PR; any chance this bug can be set to “Confirmed”? (It still reproduces even in )
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!


Question: */ var ReactDOMSelect = { getNativeProps: function(inst, props) { <del> return Object.assign({}, props, { </del> <ins> return Object.assign({}, DisabledInputUtils.getNativeProps(inst, props), { </ins> onChange: inst._wrapperState.onChange, value: undefined, });

The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.


Question: if ( elementType === ElementTypeFunction || elementType === ElementTypeClass || <del> elementType === ElementTypeContext </del> <ins> elementType === ElementTypeContext || elementType === ElementTypeMemo || elementType === ElementTypeForwardRef </ins> ) { // Otherwise if this is a traced ancestor, flag for the nearest host descendant(s). traceNearestHostComponentUpdate = didFiberRender(

<!-- 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.1 the project: react dev tools and set the highlight updates when components render option. changes to the todos no updates are displayed via React dev tools <!-- 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: --currently, updates are only displayed if the react component is not memoized. all react components should show their updates regardless of memoization.
any idea who I should ping to get some eyes on this?
No one needs to be pinged. We review GitHub issues as we have bandwidth. If you'd like to contribute a bug fix, those are welcome.
Sure, do you have an idea where I might look to investigate something like this? It would be my first time contributing to that code so it'd be greatly helpful if someone could point me in the general direction.
a start would be reading this Then you can read through the of the to get an idea of to start and debug the dev tools locally. Haven't submitted anything myself, but that's how I'd start.


Question: { "private": true, "name": "react-devtools-timeline", <del> "version": "4.27.7", </del> <ins> "version": "4.27.8", </ins> "license": "MIT", "dependencies": { "@elg/speedscope": "1.9.0-a6f84db",

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.


Question: unstable_continueExecution: unstable_continueExecution, unstable_pauseExecution: unstable_pauseExecution, unstable_getFirstCallbackNode: unstable_getFirstCallbackNode, <ins> get unstable_IdlePriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_IdlePriority; }, get unstable_ImmediatePriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_ImmediatePriority; }, get unstable_LowPriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_LowPriority; }, get unstable_NormalPriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_NormalPriority; }, get unstable_UserBlockingPriority() { return global.React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED .Scheduler.unstable_UserBlockingPriority; }, </ins> }); });

<!-- 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? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost.

I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.


Question: } } <del> if (checked != null && node.checked !== !!checked) { node.checked = checked; </del> <ins> if (checked != null) { // Important to set this even if it's not a change in order to update input // value tracking with radio buttons // TODO: Should really update input value tracking for the whole radio // button group in an effect or something (similar to #27024) node.checked = checked && typeof checked !== 'function' && typeof checked !== 'symbol'; </ins> } if (

<!-- 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: 18.3.0-canary-- radio buttons that toggle in selecting each radio button, is no longer called <!-- 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 following CodeSandbox demonstrates the issue with the current react canary version. The issue is not present when react & react-dom versions are changed to stable 18.2.0 <!-- 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: --'s prop is not called on subsequent clicks of the input 's prop should be called on subsequent clicks of the input
As far as I an tell this also repros without toggling : So it's just about changing the controlled delayed.
The problem was introduced with . The previous version works.
It looks like it was this change that introduced this bug:
what are ways to fix this issue?
FYI, I find something by investigating, as below: : isn't called because here is falsy in that process. PS: In our case, should be equal to . Diving into the inner functions as the followings. : : : We can find the key is that the tracked value should be different from the value get from () in our case. We can believe the tracked value was not updated after the delayed state change, which cause the issue.

Analysis by reproduction steps (Please visit , which can print the tracked values): : One: checked ( is ), and the tracked value is Two: unchecked, and the tracked value is 'Two', and wait for delayed : is called One: unchecked, and the tracked value is Two: checked, and the tracked value is 'One', and wait for the delayed : is called One: checked, and the tracked value is Two: unchecked, and the tracked value is 'Two', won't call again PS: The tracked value can be updated at the end of the event handler (by ), so Step 2 will result in the correct tracked values. So, I think one solution is to update the tracked value (at the end of the commit mutation phase) when the checked prop changes. I'd like to submit a PR to fix it. Any corrections or suggestions will be appreciated, (for I'm not sure if I miss anything important).
I tried another way to understand what caused the bug. I just checked the between a working commit () and non-working commit () and figured out that the bug happens after removing in function of . just restoring or just adding the bug disappear. Maybe the problem is explained in this is not updated and will result null/undefined and the radio is no more controlled? You can check this . I've also made a change to to start devtools server with a simple radio example. To run the server: run in the root directory and in directory. from to the root directory run from folder execute (better to open another shell for this command) go to


Question:
expect(updatedResultCausedByClick.props.className).toBe('was-clicked'); });  it('can shallowly render components with contextTypes', function() { var SimpleComponent = React.createClass({ contextTypes: { name: React.PropTypes.string, }, render: function() { return
; }, }); var shallowRenderer = ReactTestUtils.createRenderer(); shallowRenderer.render(<SimpleComponent />); var result = shallowRenderer.getRenderOutput(); expect(result).toEqual(
); });  it('Test scryRenderedDOMComponentsWithClass with TextComponent', function() { var renderedComponent = ReactTestUtils.renderIntoDocument(
Hello Jim
); var scryResults = ReactTestUtils.scryRenderedDOMComponentsWithClass(

I am trying to render a component using the preliminary shadow renderer support in TestUtils. A simple reproducible test case of my issue is this When I run this in my Jest test, I get: It looks like this error is thrown whenever the component being rendered has . I thought perhaps the context was required (although I haven't had any problems omitting it in my actual app), but even when using I get the same exception.
I think this is a known issue with shallow rendering. cc
thanks for the report. Context isn't meant to be supported with shallow rendering (i.e., we haven't tested it), but it looks like you may be able to work around this problem by passing an object as the second argument to : it looks like an additional argument was to the shallow rendering API in . What was the thinking here? Can we default this to an empty object?
Thanks, the workaround works great. And I see you posted a fix as well so looking forward to that.


Question: * Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ <del> batchedUpdates: function(callback, param) { </del> <ins> batchedUpdates: function(callback, a, b) { </ins> var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates; ReactDefaultBatchingStrategy.isBatchingUpdates = true; // The code is written this way to avoid extra allocations if (alreadyBatchingUpdates) { <del> callback(param); </del> <ins> callback(a, b); </ins> } else { <del> transaction.perform(callback, null, param); </del> <ins> transaction.perform(callback, null, a, b); </ins> } } };

This throws . Maybe this can be simplified some more but this was the simplest repro I could make. Thanks for sending a repro case over.
Wow, it really was a bug. Narrowed it down a little, but it's still rediculously "complex". Big props to for repro! Anyway, just glancing at the code and from experience, I can safely assume that the issue is that receives multiple updates to the same node from . Which intuitively didn't make any sense at all to me, since always calls when it's done and is basically just recursive. However, when taking another peek at the code, I'm pretty sure that the issue is that (in this case) makes the invalid assumption that all updates belongs to the same root. When that is not the case, an to a component which itself updates another root will only once everything is done. The updates to the other root will NOT after each on that root because will always greater than 0. In practice this means that whenever updates another root, all DOM updates on that root will be batched one after the other (as opposed to batching component updates) which is a violation of assumptions in . It's also very inefficient. Intuitively it seems that what should happen is that all component updates within a call should be (but that is not for sure), exactly how this should be solved in practice I'm not 100% sure right now. But I'm 95% sure that this is what's happening, and the repro does have all the ingredients.
Speaking a bit to in chat, I feel like the issue is that and when called from within become asynchronous as opposed to synchronous as they usually are. Which leads to this issue, but also possibly a lot of other subtle issues.
Apparently is not at all to blame...
Narrowed it down even further, apparently it breaks immediately on the first , the error just didn't show up until later unless prodded.

I still don't feel any more enlightened on the issue though...
Your latest two jsbins (4 & 6) throw different error for me (from in X ): And, if one removes Z from A , the same X throws , because then A render won't have any refs on that render so will be undefined... React docs warn that "Never access refs inside of any component's render method - or while any component's render method is even running anywhere in the call stack.", don't know if it's relevant here.
Yeah different error, but I'm sure the cause is the same. The issue is the span not actually ever being rendered, just that in the old repro it doesn't actually turn into an error until later.
Ok, so perhaps here's a reduced test case, see console: is being called twice in a row, and the first time the span is not there in DOM even though it has been rendered already. One culprit for this behavior may be that you are effectively calling setState on sibling component where setState would not be allowed on component itself (triggered via componentWillUpdate).
Huh? It does end up being rendered in your test case, and there's no error?
no I didn't want to throw the error so that you can see that the componentDidUpdate will be called double. The point is that first the span is not there and if one would try to access it (as in your ref.getDOMNode()) it would throw. See console for flow.
is defined so it's an error regardless, and more than that, React expects the node to be there, but it isn't and throws an error. Even after it still isn't physically there in the DOM. So something is wrong. Unless I'm missing something.
Yes, there is definitely a problem there as you said, sorry for not being clear. I just wanted to reduce it so that there are no refs or forceUpdates which may bring other problems. One could throw the error in componentDidUpdate for clarity, as the innerHTML is definitely empty where it should not be. But it is interesting that it will be called right away again, and then the span will be there.

But it throws:
Was this fixed?
Was clearing up old some old issues and it seemed like this was fixed, but apparently not.
I've found this same problem. Here's a minimal failing example for React 0.12.2: ,output However, it appears that this is fixed in 0.13RC: ,output. Any ideas which commit fixed this? If there aren't tests which exercise this it might creep back in.
Same here. Was perhaps related? I created a simple test case based on jsbin, which currently passes. Unfortunately I'm unable to run tests in anything besides master so can't really validate.
AFAIK no longer exists as of React 0.13, so this issue should be irrelevant now.


Question: checkMergeObjectArg: function(arg) { invariant( !isTerminal(arg) && !Array.isArray(arg), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge an object, instead got %s.', arg </ins> ); },

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.


Question: } 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> {

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.


Question: <RecordToggle disabled={!supportsProfiling} />  <ReloadAndProfileButton disabled={selectedTabID === 'timeline' || !supportsProfiling} />   <ReloadAndProfileButton disabled={!supportsProfiling} />  <ClearProfilingDataButton /> <ProfilingImportExportButtons />

(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.


Question:
document.body.removeChild(parentContainer); });  it('regression test: Suspense + hydration in legacy mode ', () => { const element = document.createElement('div'); element.innerHTML = '
Hello World
'; ReactDOM.hydrate( <React.Suspense>
Hello World
 </React.Suspense>, element, ); });  });

Do you want to request a feature or report a bug? Bug What is the current behavior? React 16.10.0 has broken all applications (and potentially other SSR solutions). It appears you cannot in conjunction with a client-side component. ! CodeSandbox: What is the expected behavior? Not entirely sure -- I'm opening this issue to discuss. The provided example worked in React 16.9.0 (and prior releases containing Suspense). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? / is broken. / works.
Thanks for reporting! We'll have a fix out soon; in the meantime, please downgrade back to 16.9.0.
I believe technically we don't support conditionally rendering a Suspense boundary when server rendering. It just happened to (accidentally) work before. We'll either fix so it matches the old behavior or provide a more graceful error or fallback behavior.
The issue is that the error only occurred on the server. So if you conditionally rendered it, you’d miss (intentionally?) the error we logged to let you know not to use Suspense with SSR. The issue is that the accidental semantics this lead to, on the client, is not actually the semantics we want SSR Suspense to have. That’s why it was not yet available for SSR. We’ll at least need this fallback behavior to behave reasonably when the server renders the boundary. Now the question is if we can preserve the old accidental behavior if the server was conditionally excluding the boundary on the server. And if that’s even a good idea.
I've just found that error today only in my production build of Nextjs. There was no such error yesterday. But I am having React and didn't update any packages. Is it possible?
please file a separate issue. I’d recommend including a reproducing example on codesandbox or as a git repo.
I got the same error on version but it still not resolved <img width="1219" alt="Screen Shot 2019-09-28 at 23 05 56" src="https://user-"
The key issue here is that with the new model (behind the flag), this would be considered a hydration error. Something caused a mismatch.

We don't know if this is because the boundary was intentionally conditionally rendered, or if it was because something completely different was conditionally hydrated. E.g. consider this . If it rendered the div on the server but not on the client, then the Suspense boundary would have a mismatch because it finds the div where it expected its own content. I believe we will at least have to make this a hydration error log in DEV mode. So we'll need to find a fix in regardless. However, as a courtesy we can probably delay that log so there's time to coordinate a fix. Now the other question is what the runtime semantics should be. In this case, we're already in an error state for hydration so it's not considered normal semantics. I see two possible semantics: 1) it attempts to hydrate using the content of the Suspense boundary. 2) it client-renderers the Suspense boundary content without hydrating and then continues which will likely delete the existing siblings that already had such content. For (1) it gets quite strange if something suspends because in that case, it would try to hydrate using the fallback's content against the real content which could cause very strange effects. Normally we favor deleting and regenerating content in these cases because it avoids risks like transferring state or clicks to the wrong target which can cause severe negative effects. Therefore my preferred semantics here is actually that it regenerates on the client. This is not what currently assumes will happen though.
We have a fix for this. I'll release momentarily as 16.10.1. Release branch is here:
This is now fixed in .
please file a new issue with a reproducing example, either on codesandbox, or as a git repo. Thank you!


Question: 'use strict'; <ins> var REACT_VERSION = '0.14.0-alpha'; var ExecutionEnvironment = require('ExecutionEnvironment'); var warning = require('warning'); if (__DEV__) { // before performing any initialization of React, check that // only one instance is in use on the current page. // // Using multiple instances cause a variety of problems if elements // from different versions are mixed on the same page. // // See issue #2402 if (ExecutionEnvironment.canUseDOM) { warning( typeof window.__REACT_VERSION__ === 'undefined', 'Multiple instances of React have been initialized on the same page. ' + 'Currently initializing React v' + REACT_VERSION + ' but another instance of React v' + window.__REACT_VERSION__ + ' was already initialized' ); window.__REACT_VERSION__ = REACT_VERSION; } } </ins> var ReactChildren = require('ReactChildren'); var ReactComponent = require('ReactComponent'); var ReactClass = require('ReactClass');

People lose hours of work debugging a simple issue: two versions of React being loaded at the same time. Because there is no warning right away when this happens, they usually discover the problem through invariant violations. Some of them are descriptive (e.g. ) and I think I even saw warning that said something like "check if two copies of React are loaded", but some are really cryptic: . Is there a reason why we don't want to warn right away when two copies of React are loaded?
There's probably no good way to find out if two copies of React are loaded (CommonJS modules are the antithesis of sharing a global scope, they're literally two duplicate but separate modules). But I would expect React to be clever enough to figure out that, say, a component is a React component even if it's not from the same copy of React.
I think it's lesser evil to put some flag on , like , than to spend any more time on this.
Should be preferable to just extend (or w/e) with simple duck-typing that warns if it looks like a ReactElement but isn't... or something like that. It's free and doesn't interfere with intentionally running multiple React instances.
I think that in the future, this will actually just work. In the meantime we can warn here:
Would it catch all of the issues listed above though? Usually the problem comes up when some component or helper library loads its own version. Will we get to in this case? Besides, does React truly support independent Reacts on page right now? Do they not interfere in any way at all if they aren't mixed (e.g. browser event handling)?
(To clarify, I was referring to comment)
I might be mistaken, but ignoring weird hacks then the only issue with multiple instances of React are when ReactElements from different instances gets mixed up. Depending on which API you feed them to, you're going to see lots of different errors though. So yeah... I think that should take care of all, or most at the very least. As long as you never stop event propagation or mount them inside each other it should be OK I think (but still not great though). Good point.
Just a confirmation from someone who just flushed 3 hours of debugging time down the toilet that, yes, this issue is hard to debug, please make at least a warning.

In my case I was having a weird exception (TypeError: Cannot read property 'firstChild' of undefined) caused by the fact that a component created with a different (uninitialised) copy of React was carrying a _owner = null, thereby breaking findComponentRoot().
We should already be warning in the case that an element from one copy of React is passed to in another: I guess the cases here are when nesting elements from different versions inside each other?
Yes. At least it was in my case. Nested elements created from different React versions.
Just my 2cents: I had the same issue today and my problem was using browserify 8.1.3 instead of 8.1.1 Hope it helps
The other issue with this is you can't reliably use the dependency injection mechanism, e.g. to change the batching strategy, while using components from multiple modules where each has it's own instance of React as a dependency. Even if they are the same version of React.
+1 ; thanks gaearon
said: "The other issue with this is you can't reliably use the dependency injection mechanism, e.g. to change the batching strategy, while using components from multiple modules where each has it's own instance of React as a dependency. Even if they are the same version of React." This.
The main workaround many modular React components are using is to specify React as a -- the parent module must provide React to prevent multiple copies. This is problematic because are on track to because they introduce .
I've seen this a lot as well, and had lots of requests to switch React to a (+) in my packages which I'm currently resisting for reasons mentioned. The most common frustration I've seen is when npm subtly installs two versions of React, and Browserify (correctly) includes both in the build. It can happen unexpectedly w/ package updates and breakage ensues. A warning from React that "hey, there is more than one of me on the page" seems like the most elegant way to warn developers early and direct them to an explanation of what's gone wrong / how to fix it. It's a side-effect of npm's dependency rules and node's behaviour that I end up with two Reacts when I just want one.

Looks like things will get better with (see npm/npm) but in the meantime I agree with about adding a "lesser evil" hack: ... there's a good argument to be made that this isn't React's problem to solve, but since it's a common problem and React can solve it, I think it would be great if it did.
A solution I found with was to alias all calls like so (example shown with grunt): so it isn't impossible to fix, but I'd make the argument that since this is such a common issue it needs to be highlighted more clearly in the React docs.
when using browserify it can happen just when requiring two different versions of React because of the way it handles deduplication. Requires with the same path and code between the two versions can end up getting de-duped. Modules where the code/require path was changed between versions get deduplicated and others don't. So I encountered this: (from React v1) is evaluated and it mixes in ReactBrowserComponentMixin as part of its spec .Class.injectMixin(ReactBrowserComponentMixin) is evaluated and it adds ReactBrowserComponentMixin to all classes subsequently created by ReactClass.createClass (shared between React v1 and v2 because it didn't change between the two versions of React) (from React v2) is evaluated and it tries to mix in ReactBrowserComponentMixin twice, once from ReactDOMSelect's own spec and once from the global injected mixin list. As long as modules can be stateful, this approach to deduplication seems horrifically unsafe. I'll file an issue with Browserify itself, I haven't yet verified if Webpack would have the same issue. Either way - I think it would make sense to handle it specifically in React given how it can trip newcomers up.
Reverting for now (in ) as we sort out some problems.
THANK YOU for this discussion. I was battling with an Invariant Violation bug for half the day yesterday and then came across this ticket this morning. My setup was using a browserify-shimmed version of React and react-router loaded from CDN. After reading this discussion I just opted to use the npm versions of these libs and the error went away. This is my first React project so debugging this problem was a pretty big headache. Thanks again for this discussion as it lead me to figure out the problem and move forward.

Leaving details of my case for future searchers: I got the error "Invariant Violation: Could not find the drag and drop manager in the context of Card. Make sure to wrap the top-level component of your app with configureDragDropContext" Also turned out I had two React versions loaded. The problem was Webpack. I was using "npm link <folder" for one of my packages, which also depends on React. Seems webpack has problems handling symbolic links, or it's my fault configuring it improperly. Anyway, the problem was fixed by installing the package into my local node_modules directory.
Thanks for this, I'm gonna add it to the relevant explanation gist for React DnD.
Would like to have this too. Haven't figured out a way to get GitHub cc'd (rather than bcc'd) without explicitly participating, sorry for the noise.
There's a button :)
I think that still doesn't CC you but only BCC, sadly. Moreover, I'm watching the repo already, but I have a different inbox for when GitHub CCs me.
Fyi: Ongoing PR
Fixed by , hopefully.
If it helps the next person googling, is yet another sign of this problem.
and counting... I've got this one: I'm looking everywhere for the sneaky react twin, but no luck. doesn't show any duplicates The other possibilities I've read about are double-loading the react script, webpack double-bundling, or react/addons causing trouble, so those are what I'm working on now. Insidious.
As you've hopefully set up correctly, then simply remove and reinstall everything, that usually fixes it unless there's some incorrectly configured module.
I tried to git clone the repo and reinstall, but that wasn't the issue. Eventually I noticed that the error was only happening after the first navigation (similar to this ) and started taking apart my navigation menu. Turns out that for some reason putting a from react-router inside a from react-boostrap was causing react to go nuts. I posted my findings on .
I think it also might have had something to do with my not using the generated from react-router as the root of my component hierarchy. I was wrapping it in a higher level-component that accepts my flux instance and passes it on as context.

Isolating the issue into gave me the following error:
The nested links thing is due to invalid HTML and we have a new warning for that in 0.14.
By the way I got that new warning a few days ago and it's beautiful, great work. :+1:
I'm getting this error: when using npm link to require a module I'm working on. I can't be 100% sure that it's caused by having multiple versions of React, but the error does go away when I just paste the npm module directly into my app instead of using it via npm link. I don't get this error when using my npm module the normal way (react is a dev dependency so I don't think it gets installed in node modules). Has anyone else run into this issue and come up with a fix? Thanks!
I got this error while running 0.14-rc1 and 0.14-beta3 together
Please do not report random problems in this issue. File new issues.
Seriously. This has taken me 3 days to figure out that my random error about unmounting the _mouseMoveTracker twice in fixed-data-table is caused by two reacts... This is not good that this bug seemingly can't be fixed? Why can React not just put the version number on the window object and never add itself again if it's there already? This is better than the hours and hours wasted by many people with this!
I thought we fixed this in 0.14 (); is it not displaying a warning?
Yep, I just upgraded to 0.14.2 everywhere (including inside the module) and somehow deleting react from nodemodules/react-datatable/nodemodules/ fixed my bug! (see here ). Maybe there is something wrong with my webpack config? It's weird that this fixed it. Is this having two of the identical version included a subtle variant on this bug?
Part of the problem is react-datatable having as a non-peer dependency (cc which can cause NPM to fetch a separate react installation for just that module.
Okay - thanks - I'll try adding this as a peer dep, however when I want to run the build for my module if developing the datatable from within my main project, what is the best way to accomplish this without issues?
you might try upgrading to , then .

has improvements in how it handles dependencies and is better about avoiding multiple instances of a given package, since it installs with a flat structure instead of nesting dependencies within packages. This, along with moving from to in a library I am writing, solved my similar problems.
Another 4 hours lost. My webpack config now is:
Can you say what symptom you experienced? Also, if you are using the prebuilt I would recommend using the prebuilt react- as well and using in your webpack config since the secret property is unstable and will change in the next version (hence its name).
yes, the problem was in prebuild version of React. The second instance of React came from require('react'). It did work somehow until React 0.14 migration. And even more: It work after partial code removal! This lead me to wrong way of long debugging. I agree, this is my fault. But I still expect something like: every time, instead of rare warning: after which I spent hours to find out whats wrong with my refs... It seems like it is very common problem, and it is have to be more detailed and have better documentation.
same issue with webpack and loading manually.
Is it still an issue to load more than one version of React on a page, even if those instances are managing totally separate DOM trees and aren't being explicitly instantiated as globals? Like if, say, I had a package with and as dependencies, and they both depended on different versions of React, with npm as the dependency manager, could they be used together on one page?
No, that should work now if both are on a recent version of React.
Could you please point me out what would be the behavior of React if , let say , we want to introduce a widget including React in a host page that has an older version of it and the possible workaround to make it work? Thanks
Old versions of React are probably only tripped up by data-reactid IDs in the DOM that it didn't generate. If you're doing only client-side rendering with your widget, it should only have a data-reactroot attribute and no data-reactid so there shouldn't be any conflict.
Just ran into problems again today when I accidentally had 16.4.2 and 16.5.0 installed in a project, no warning from React.

To make matters worse, the duplicate versions were caused by a bug in that ...
Was there any resolution as to whether or not this is possible and/or a good idea? It seems like it'd provide developers with useful information.
Project A uses React 16 wherein Project B uses React 15, Lets say Project A is package got used in Project B - can that work?
Would Preact and React have the same issue described here? I’m asking because I’m using single-spa for a platform play at a large company of distributed teams.
It sounds to me like there are two separate issues here: you have two different copies of the library loaded and in use anywhere on a page in separate components that don't interact with each other? you have components from two different bundles, each with their own copy of the library, interact with each other (eg. the function from one library receiving an element created with from the other library) I don't know about the status with modern versions of React. In the case of Preact (1) should be fine but since it does have some global state you could run into problems in situation (2). Please file an issue in the repository if you'd like to discuss further.
This appears to be a bad link.
For someone encountering this at the moment - does anyone have any tips on identifying the cause and debugging the issue? I've used the check from the hooks page (how I discovered this) which confirms I've got 2 instances loaded: I believe I'm doing things by the book, in a monorepo react, react-dom etc are all always . What steps would you recommend after this?


Question: // but this seems kind of awkward and expensive. return 'array_buffer'; } else if (typeof data[Symbol.iterator] === 'function') { <del> return data[Symbol.iterator]() === data ? 'opaque_iterator' : 'iterator'; </del> <ins> const iterator = data[Symbol.iterator](); if (!iterator) { // Proxies might break assumptoins about iterators. // See github.com/facebook/react/issues/21654 } else { return iterator === data ? 'opaque_iterator' : 'iterator'; } </ins> } else if (data.constructor && data.constructor.name === 'RegExp') { return 'regexp'; } else {

Provided is a code sandbox with a very simplified version of the code which triggered this bug. the code sandbox app in a new window developer tools the "Components" tab on the "App" component Observe that devtools crashed, and the console prints out an error similar to this: This happens in both Firefox and Chrome. Every time react-devtools-extensions 13.5- Could not inspect element with id 2 No response
I see a slightly different error than the one reported: I can repro this though so that's good. I can fix this.
Fix will go out with the next release.
Not sure what your release cycle is, but I'm using the extension built from source in the meantime. Works fine now, thanks!
I have a similar issue. I created a PR that should fix the crash: To reproduce: clone into install dependencies run application: open the -Tab in click on the component you should see following error: !
I would appreciate if you could make a reduced repro that didn't import other frameworks (like this i18n framework). Seems like the core of this problem is related, but I'm having to dig through unfamiliar (TypeScript) code trying to narrow down why it's still throwing in .
thanks for your help! I simplified the example a bit and marked the key-part. Just replace the file with following content: jsx import React from 'react' export const getFallbackProxy = (prefixKey?: string): any =new Proxy((prefixKey ? () =prefixKey : {}) as any, { get: (_target, key: string) =getFallbackProxy(prefixKey ?

: key), }) export const initI18nReact = () ={ const context = React.createContext({} as any) const Component: React.FunctionComponent<{ initialLocale: string }= (props) ={ const [isLoadingLocale, setIsLoadingLocale] = React.useState<boolean(false) const [currentLocale, setCurrentLocale] = React.useState<string | null(null) const [LL, setLL] = React.useState(getFallbackProxy()) const setLocale = async (newLocale: string): Promise<void={ setIsLoadingLocale(true) setLL( //
// KEY-PART BEGIN --------------------------------------------------------------------- //
new Proxy( {}, { get: (target: any, key: string) ={ (, key) return () =key }, }, ) as any, //
// KEY-PART END --------------------------------------------------------------------- //
) setCurrentLocale(newLocale) setIsLoadingLocale(false) } !currentLocale && !isLoadingLocale && setLocale((props as any).initialLocale 'en') if (!isLoadingLocale && !LL) { return null } const ctx = { setLocale, isLoadingLocale, locale: currentLocale, LL } return <context.Provider value={ctx}{props.children}</context.Provider} return { component: Component, context } } //
const { component: TypesafeI18n, context: I18nContext } = initI18nReact() export { I18nContext } export default TypesafeI18n and then run When you look at the console output you can see all access-attempts to the proxy being logged: ! The uppercased names come from the application-code itself. Then it gets interesting.. React Dev Tools tries to access that proxy with a lot of different keys, the Proxy can not handle (and should not handle). Not so sure where this gets called and I currently don't have a lot time to dig deeper.. I assume this PR is 'fixing' the wrong thing since the problem lays somewhere else.
I'm seeing a different error from the repro you shared above: The error I was seeing on the PR was:
But you see all the accesses to the Proxy from React Dev Tools? Forget the error for now. If we can tell React Dev Tools to not access the Proxy, the error should be gone.
It's not as simple as that.

When an element is inspected, DevTools must serialize its props/state/hooks (using ) to send values from the "backend" (running in the page with your app) to the "frontend" (DevTools extension UI). (These are in separate memory spaces, so we can't just share the value directly.) As a side note, it also needs to avoid deeply cloning objects because that can add a lot of overhead and slow things down, so instead it shallowly clones them before serializing. The main utility that does this is here: The code path that's triggering all of the accesses you're pointing out is here: Which calls this function to loop over props: Then eventually this method throws when trying to stringify a property: More specifically, this line: Calling with the proxy value throws. Replacing that method of mapping keys with a that pushes to an array also throws. You can reproduce this error with the following stripped down code: Q: Why can't you just treat this Proxy object differently? A: Because (to my knowledge) there is no way to determine if a value is a . Q: Is there a workaround for this? A: You could make your detectable using the operator, but it would require custom work on your side to support. You could also defined a custom accessor to limit the values that were iterated over. Q: Is there something (hacky) that DevTools could do to detect this case. A: Maybe? Maybe we could check something like to detect an edge case like this, but I'm not sure if this would have other negative consequences. I'm also not sure what we would do with it once we had detected it. Just show a special shallow "[[Proxy]]" string or something? It wouldn't be inspectable.
thanks for your detailed analysis. In my opinion the best solution would be to define the method on the proxy-handler. I tested it with the current React Dev Tools but it seems you don't jet check the available properties with am I right? So work on both ends would be required.
This sounds like a reasonable approach. That's right. I don't think it's generally desirable that we limit the values displayed to being only properties found directly on the object. That being said, maybe we could do something like this as a fallback.

However, even after doing something like this, I'm seeing a different runtime error. I would welcome proposals/contributions from you to improve the way DevTools works with edge case objects like the type of Proxy this library uses.
not so sure if detecting a proxy by the content of the error-message is a good solution. the wording could change different browsers may have different wording I recently saw a localized DevTool environment, so maybe also the error-messages are not english Is there another way to check if we access an object? Maybe use something like:
I don't think that approach makes sense. If it's already an array, we wouldn't need to convert it. The purpose of calling is to simplify handling different types of iterables. That being said, I think even if we solve the iteration issue (which the error message check does, even if not in a very robust way) I think we'll still have other issues.
Ah, sorry, I didn't check the context of that array example. This code is here to display a graphical representation of an object somewhere inside the React Dev Tools? I think a better solution would be to change this to and add a new case inside the function that uses (data)
I don't think the above code works, because it would hit false positives for HTML collectins or regular expressions. The only way I know of to check this would be to use the non-standard property (which seems like not a great idea).
in other words: we are not able to find a solution to the problem? So also HTML collections and regular expressions throw an error in the same line as a Proxy? But looking at the function you have already a way to detect these two types. So I don't see why the code mentioned above should not work. It could indeed create false positives, but at least it will not throw an error.
That is correct. They would if you tried to invoke . Look at the surrounding code: We only enter the code path for "iterator" (and "opaque_iterator"). Your proposal, seemingly, was to enter it always and interpret a as a Proxy detection. This would break the other types I mentioned. Alternately, if we left this check in place, then the / would never run for Proxies:
I just created a PR that shows the implementation I would imagine. It has no side-effect on the detection of regular expressions and collections.

It just handles cases, where accessing and executing e.g. the property of a proxy throws an error.
I tried an approach very similar and it didn't work for me (in Node) until I removed the check above. That's interesting. can you add a failing test to
yes, just give me a few days to find time for that
Sounds good!


Question: ); }); <del> it('gives a helpful error when passing null or undefined', function() { </del> <ins> it('gives a helpful error when passing null, undefined, boolean, or number', () => { </ins> spyOn(console, 'error'); React.createElement(undefined); React.createElement(null); <del> expect(console.error.calls.length).toBe(2); </del> <ins> React.createElement(true); React.createElement(123); expect(console.error.calls.length).toBe(4); </ins> expect(console.error.calls[0].args[0]).toBe( <del> 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' </del> <ins> 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' </ins> ); expect(console.error.calls[1].args[0]).toBe( <del> 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' </del> <ins> 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' ); expect(console.error.calls[2].args[0]).toBe( 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' ); expect(console.error.calls[3].args[0]).toBe( 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' </ins> ); React.createElement('div'); <del> expect(console.error.calls.length).toBe(2); </del> <ins> expect(console.error.calls.length).toBe(4); </ins> }); <del> it('includes the owner name when passing null or undefined', function() { </del> <ins> it('includes the owner name when passing null, undefined, boolean, or number', () => { </ins> spyOn(console, 'error'); var ParentComp = React.createClass({ render: function() {

The following code: produces deep into React.
Yea, we can do better than that. On the plus side, looks like this error will actually log as in the near future (does for me in my browsers: Firefox Nightly, Chrome beta). We should be able to catch this in . Strings are ok. Functions are ok (I think, or will be). Objects with certain characteristics are ok (has a render function?)
No objects, just functions that return objects with a render function. I thought we had a warning for this already though.
We just look for .
Sorry for all the references above. Let me know how looks.
I'm still getting this error (I just installed the latest react version). Any ideas why it happens? Everything else bundles rather alright with browserify but the main client script doesn't run and flags with this error.
It's a long shot, but I just had the same error, and it turned out to be a component that I was including with further up the component hierarchy than it was actually being used. Once I removed the extra it ran just fine again. If it helps to narrow down the component, the hierarchy was Ancestor ChildList Child ChildList Child... (recursive). The Ancestor component was unnecessarily including the Child component. But again this is pure speculation since the error message was in no way indicative of the solution I found, so the problem in your case may be completely different :) Cheers
Yep, you are right, it was totally my own error. The error reporting should be better though. It seems like frontend scripts are better at this than bundling everything using browserify.
Thanks you saved me a lot of time ;) I had simply forgotten to add the on a react component. I agree that this error is pretty confusing, even with the message (which is what I got).
I just had the same issue that cosmith had. The TypeError really isn't very helpful. The real error is only tangentially related to types...
Did you see a warning in the console logged before the exception was thrown? There should be one.
good question. It was probably there, but I don't recall now. Why would that be a warning and not an exception itself?
For this case specifically, it's because we want to be able to inline calls to React.createElement () without changing runtime behavior which we can do only if createElement never throws.

Can it be made to only throw when not in ? Granted, even I don't like that idea very much... I'm not sure there's a better solution than just emitting a warning before everything explodes. At the end of the day the dev is just going to Google the error because it's completely opaque. Then they'll find this thread or something similar and move on with their lives.
Not sure if this will help someone in the future, but another way to get this same error ( ) is by referencing a component that hasn't been to module exports. So this will throw the error mentioned: This will fix it:
Hopefully we can make the toUpperCase error a little less cryptic. Just posted .
very nice :+1:
I was trying to do and was getting this error. Later found that, Element has inline css entry at its root <div. After Removing the entry it has been fixed.
I'm struggling with this error too. Any pointers? Here is my main app: And here is my I'm using the latest version of rect, reactify and browserify to compile
In your file check the exports line , there is a typo I guess, It should be
Thank you! You saved me much frustration :)
Thank you, that was the source of my bug too.
I had the same error trying to include a component inside the same component Error :
In 0.14, you'll get something like this message:
hey kinda late on this, but would it be possible to get the name of the invalid component? Let's say I try to use but is wrong. Would it be possible to say that it's that is failing the test? Would help finding and fixing the errors
This isn't possible without changing the transform, no. You can look at the stack trace to see where the error was.
the error is so confused, and difficult to trace the error
:+1:
Thank you do much! What a terrible error message!


Question:
}, );  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...']); }   expect(Scheduler).toFlushAndYield(['Started loading', 'Loading...']);  expect(root).not.toMatchRenderedOutput(
AB
); await Promise.resolve();

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.


Question: "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" },

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


Question: 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', () => {

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 :-)


Question: declare var chrome: any; import {__DEBUG__} from 'react-devtools-shared/src/constants'; <ins> import {getBrowserName} from './utils'; </ins> import { EXTENSION_INSTALL_CHECK, EXTENSION_INSTALLATION_TYPE,

React DevTools v4.20.0 in Firefox in Firefox Firefox DevTools error in console ! Every time


Question: }; onProfilingStatus: (isProfiling: boolean) => void = isProfiling => { <ins> if (this._isProfiling === isProfiling) { return; } </ins> if (isProfiling) { this._dataBackends.splice(0); this._dataFrontend = null;

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


Question: // 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(

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


Question: }, "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"

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.


Question: <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>

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.


Question: ```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> ]; } ```

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.


Question: 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; /**

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 )


Question: throwOnInvalidObjectType(returnFiber, newChild); } <ins> if (__DEV__) { const disableNewFiberFeatures = ReactFeatureFlags.disableNewFiberFeatures; if (!disableNewFiberFeatures && typeof newChild === 'function') { warnOnFunctionType(); } } </ins> return null; }

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.


Question: { "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": {

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.


Question: * @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),

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.


Question:
expect(stubStyle.lineHeight).toBe(''); });  it('should warn when mutating style', function() { spyOn(console, 'error'); var style = {border: '1px solid black'}; var App = React.createClass({ getInitialState: function() { return {style: style}; }, render: function() { return
asd
; } }); var stub = ReactTestUtils.renderIntoDocument(<App />); style.position = 'absolute'; stub.setState({style: style}); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toEqual( 'Warning: `div` was passed a style object that has previously been ' + 'mutated. Mutating `style` will be deprecated. Consider cloning it ' + 'beforehand. Check the `render` of `App`. Previous style: ' + '{"border":"1px solid black"}. Mutated style: ' + '{"border":"1px solid black","position":"absolute"}.' ); style = {background: 'red'}; stub = ReactTestUtils.renderIntoDocument(<App />); style.background = 'green'; stub.setState({style: {background: 'green'}}); // already warned once for the same component and owner expect(console.error.argsForCall.length).toBe(1); style = {background: 'red'}; var div = document.createElement('div'); React.render(, div); style.background = 'blue'; React.render(, div); expect(console.error.argsForCall.length).toBe(2); });  it("should update styles if initially null", function() { var styles = null; var container = document.createElement('div');

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.