Question: "rootDir": "", "scriptPreprocessor": "jest/preprocessor.js", "setupEnvScriptFile": "jest/environment.js", <del> "modulePathIgnorePatterns": ["/build/", "/node_modules/", "/.module-cache/"], "testPathIgnorePatterns": ["/build/", "/node_modules/"], "unmockedModulePathPatterns": [""] </del> <ins> "modulePathIgnorePatterns": [ "/build/", "/node_modules/", "/.module-cache/" ], "testPathIgnorePatterns": [ "/build/", "/node_modules/" ], "unmockedModulePathPatterns": [ "" ] </ins> } }

Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. 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: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed.

Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond


Question: ): null | Fiber { if (current === null) { let type = Component.type; <del> if (isSimpleFunctionComponent(type) && Component.compare === null) { </del> <ins> if ( isSimpleFunctionComponent(type) && Component.compare === null && // SimpleMemoComponent codepath doesn't resolve outer props either. Component.defaultProps === undefined ) { </ins> // If this is a plain function component without default props, // and with only the default shallow comparison, we upgrade it // to a SimpleMemoComponent to allow fast path updates.

With this: If I render again after it resolves, it won't get the default prop value. This is a bug.


Question: } } <ins> function warnOnFunctionType() { warning( false, 'Functions are not valid as a React child. This may happen if ' + 'you return a Component instead of <Component /> from render. ' + 'Or maybe you meant to call this function rather than return it.%s', getCurrentFiberStackAddendum() || '', ); } </ins> // This wrapper function exists because I expect to clone the code in each path // to be able to optimize each path individually by branching early. This needs // a compiler or we can do it manually. Helpers that don't need this branching

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: ); ``` <del> A nice feature of mixins is that if a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. </del> <ins> A nice feature of mixins is that if a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. Methods defined on mixins run in the order mixins were listed, followed by a method call on the component. </ins>

Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.


Question: } var visitorList = visitors.getVisitorsBySet(visitorSets); <ins> if (options.sourceFilename) { options.filename = options.sourceFilename; } </ins> return transform(visitorList, input, options); }

Hey guys, I know there are a lot of issues here so I'll try to make this quick and clear. The issue is that when you generate a sourcemap using the node module by calling , it will always output in the property of the sourcemap that is generated, there is no way to specify the actual source file. I thought that perhaps the option would allow you to change this, but unfortunately it does not -- no matter what you set to, the property always returns as an array with in it only. A small snippet of code to quickly verify this:
Thanks guys for the quick fix! :beers:


Question: Notice the use of `bind(this, arg1, arg2, ...)`: we're simply passing more arguments to `handleClick`. This is not a new React concept; it's just JavaScript. <del> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. </del> <ins> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. [Flux](https://facebook.github.io/flux/) pattern is one of the possible ways to arrange this. </ins>

'For communication between two components that don't have a parent-child relationship, you can set up your own global event system.' So far I've really enjoyed React. It's conducive to modularize your components. However, as you modularize your components, it gets harder to communicate. A global event system doesn't scale and essentially couples components that shouldn't be coupled. A simple example, a faceted navigation sidebar containing two subviews. Some filters and a search bar, and a list of things: SibebarView | -- Filters -- Search Input -- Filter Button | -- List View In essence, an event stream from your search input should update the list. By the advice above, it seems like you'd say create a singleton EventEmitter which the search input : As you can see, this is a very specific event which the SidebarView has to know about. Also let's say you have a global search input. Over time it seems like you have to be increasingly specific about event names. I have a feeling Flux is supposed alleviate this problem somehow, but if so is there any way we can give some more detail here and/or point people in the right direction? Seems like a common use case.
Flux is indeed one way of solving this problem. I created a PR to mention it.
thanks! for others' reference:
one step further might be nice to throw in a quick if-you-understand-a-little-about-flux example.


Question: react: 'react', // TODO: Once this package is published, remove the external // 'react-debug-tools': 'react-debug-tools', <del> 'react-devtools-feature-flags': resolveFeatureFlags('inline'), </del> 'react-dom': 'react-dom', 'react-is': 'react-is', scheduler: 'scheduler', }, <ins> resolve: { alias: { 'react-devtools-feature-flags': resolveFeatureFlags('inline'), }, }, </ins> optimization: { minimize: false, },

Published has the following piece of code in : :roll_eyes:
FYI
Huh. That's no good.
This is because I accidentally put the module map in an map rather than a map. Oops.
Fix published in 4.11.1
Thanks!


Question: case HostPortal: case HostText: case Fragment: <ins> case LegacyHiddenComponent: </ins> case OffscreenComponent: return true; case HostRoot:

did profiling on a list, that gets updated on each pagination api call. the profiling was done, I moved around in the Profiler to view the Flamegraph to second capture, the Profiler crashed. DevTools version: 4.6.0-
What does this mean? Can you repro this bug? And if so, could you share steps for repro with us?
Sorry for not providing enough details, but even I don't have enough details. This error just popped up when I was profiling my app in React Devtools. I was profiling a normal () list, and it broke when I clicked next button on DevTools, to see the recorded profile. <img width="1149" alt="Screenshot 2020-05-08 at 11 12 50 AM" src="https://user-"About having a repro, I couldn't replicate it myself after that one occurrence, again. Anyways, my assumption is (it could be wrong), one of the list item in the flame graph is getting duplicated somehow, either due to the app it was profiling or due to something else.
Okay. Thanks for clarifying.
If no-one is working on this, I would like to assign myself to investigate and fix the issue (since multiple people have referenced it). Also, If you assign me, Can you please also help me with where to look?
If you'd like to dig into this, we'd be happy to have the help. I don't really have the bandwidth to guide you on it though. Some places you'd want to look at for starters:    And for a general overview of how DevTools works, you can check out this:
This error remains the highest reported DevTools bug but we still don't have a repro case so that I can fix it. Do you remember how to repro the error you saw above? Can you share the steps with me if so? It would be very helpful! Thank you
Hi Will try to replicate it again... It's been a long time since I used the Profiler, so I don't remember much.
Okay, understood! Either way, thanks for checking.
I've got a repro for this over on : When I run this project, I see an error in DevTools: This is very promising! Looks like there's a problem with Suspense and LegacyHidden.

I think the case I'm seeing is this: initial render, a Suspense component is mounted. has an Offscreen child, b'c of how Suspense is implemented internally, but DevTools hides this implementation detail to avoid confusion. (What this actually means is that the DevTools backend never even tells the frontend that the Offscreen component exists.) login, stuff is updated and for some reason, the backend thinks it needs to unmount the Offscreen component (even though the frontend never knew about it). This causes an error to be thrown. Unfortunately this thrown error is not surfaced in the UI so things go on until later, when it causes a downstream error in the Profiler. First step is making that first error visible (done via ). Second step is to figure out why it's happening. Interestingly, if I trim down the repro a to the minimal repro case, then copy that into the React DevTools test harness (with a bleeding edge build of react and react-dom) the bug no longer happens. Edit 1: If I copy it instead into a project created by – with the same major versions of react and react-dom, I can repro the bug. So that's good. Seems like something may have changed on the React side between 17.0.2 and HEAD? Edit 2: One (possibly) significant difference between the two versions is that 17 uses the component beneath but HEAD uses the newer component. I can also repro the same error in the DevTools test shell by swapping with so...
Oooh looks like this may have just been an oversight in our filtering logic. (We filter but not components. Eventually we'll not want to filter but for now, that seems an easy fix.
This bug fix has been released as 4.13.1


Question: localClearTimeout(timeoutId); }; } else { <ins> if (__DEV__) { if (typeof requestAnimationFrameForReact !== 'function') { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } let localRequestAnimationFrame = typeof requestAnimationFrameForReact === 'function' ? requestAnimationFrameForReact : function(callback: Function) { invariant( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); }; </ins> let headOfPendingCallbacksLinkedList: CallbackConfigType | null = null; let tailOfPendingCallbacksLinkedList: CallbackConfigType | null = null;

<!-- 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? <!-- If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in


Question: ); } }); <ins> JQueryMobileButton = React.createFactory(JQueryMobileButton); </ins> /** jQuery Mobile page content component. */ var JQueryMobileContent = React.createClass({

When I run the in examples jquery-mobile in the chromium browser, I get: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of (anonymous function)
I can confirm. Works fine with React version “0.12.2", but "0.13.0-alpha.2" gives: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of undefined ReactClass.createClass.Constructor (anonymous function) The jquery-mobile example is using component constructors in a way which makes the new version explode. gaearon lays is out here:
We'll make sure all the examples are working before we release 0.13 final but until then there's a non-trivial change they'll be broken at any point in time. Check out the latest stable branch for the working examples.


Question: useState(); } `, <ins> ` // Valid because exceptions abort rendering function RegressionTest() { if (page == null) { throw new Error('oh no!'); } useState(); } `, </ins> ], invalid: [ {

I believe this should be a valid case, because throw.
Hmm, I just realized throw should not be used for valid business case (GraphQL endpoint was updated). Render nothing (and request app update) is the correct approach.
I think we shouldn't warn on this.


Question: 1 Note that at this time, an _experimental_ build is required because DevTools depends on the `createRoot` API.  To install all necessary dependencies, run the following command from the root of the repository: ```sh yarn install ```  #### Build from source To build dependencies from source, run the following command from the root of the repository: ```sh

When trying to build the [(]) locally: react yarn build-for-devtools from the root repo node version: v16.16.0.
This is the result of :
Yarn is the package manager of choice in this repository. Did you run from the root first?
I did not do that as I dont usually work with yarn. I will try now. Please reject my bug and thanks for your time. I feel a bit stupid.
Im trying it now, and it looks like its working. It would be great if someone adds this to the readme of the extension repo.
Sorry to hear. We definitely want to avoid that. You're absolutely right. I'm on it.
Please note also that they ask to do: . The command has , which doesnt work for windows and should be replaced by . This is the command:


Question: expect(stubStyle.display).toEqual(''); }); <del> it('should skip child object attribute on web components', function() { </del> <ins> it('should skip reserved props on web components', function() { </ins> var container = document.createElement('div'); <del> // Test initial render to null ReactDOM.render(<my-component children={['foo']} />, container); </del> <ins> ReactDOM.render( <my-component children={['foo']} suppressContentEditableWarning={true} />, container ); </ins> expect(container.firstChild.hasAttribute('children')).toBe(false); <ins> expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); </ins> <del> // Test updates to null ReactDOM.render(<my-component children={['foo']} />, container); </del> <ins> ReactDOM.render( <my-component children={['bar']} suppressContentEditableWarning={false} />, container ); </ins> expect(container.firstChild.hasAttribute('children')).toBe(false); <ins> expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); }); it('should skip dangerouslySetInnerHTML on web components', function() { var container = document.createElement('div'); ReactDOM.render( <my-component dangerouslySetInnerHTML={{__html: 'hi'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); ReactDOM.render( <my-component dangerouslySetInnerHTML={{__html: 'bye'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); }); it('should skip reserved props on SVG components', function() { var container = document.createElement('div'); ReactDOM.render( <svg children={['foo']} suppressContentEditableWarning={true} />, container ); expect(container.firstChild.hasAttribute('children')).toBe(false); expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); ReactDOM.render( <svg children={['bar']} suppressContentEditableWarning={false} />, container ); expect(container.firstChild.hasAttribute('children')).toBe(false); expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); }); it('should skip dangerouslySetInnerHTML on SVG components', function() { var container = document.createElement('div'); ReactDOM.render( <svg dangerouslySetInnerHTML={{__html: 'hi'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); ReactDOM.render( <svg dangerouslySetInnerHTML={{__html: 'bye'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); </ins> }); it('should remove attributes', function() {

See for a basic example. I'm assuming there's some step in the new SVG code that we just need to remove the key if we consume it as a React prop.
Going to leave this open to ensure we block even though wrote fix before I finished submitting (do you ever sleep Dan!?)
I sleep incrementally. FWIW the fix is in


Question: if (shouldUpdate) { if (typeof this._instance.componentWillUpdate === 'function') { <del> if (__DEV__) { if (warnAboutDeprecatedLifecycles) { const componentName = getName(element.type, this._instance); if (!didWarnAboutLegacyWillUpdate[componentName]) { lowPriorityWarning( false, '%s: componentWillUpdate() is deprecated and will be ' + 'removed in the next major version. Read about the motivations ' + 'behind this change: ' + 'https://fb.me/react-async-component-lifecycle-hooks' + 'nn' + 'As a temporary workaround, you can rename to ' + 'UNSAFE_componentWillUpdate instead.', componentName, ); didWarnAboutLegacyWillUpdate[componentName] = true; } } } </del> // In order to support react-lifecycles-compat polyfilled components, // Unsafe lifecycles should not be invoked for any component with the new gDSFP. if (typeof type.getDerivedStateFromProps !== 'function') {

For consideration. These warnings are already covered by renderers based on react-reconciler. Maybe we don't gain that much by mirroring them in the shallow renderer? Maybe it's not worth the complexity? Particularly with more complicated warnings like the ones being for and .


Question: unmountComponent: function() { this.unmountChildren(); ReactBrowserEventEmitter.deleteAllListeners(this._rootNodeID); <del> ReactMount.purgeID(this._rootNodeID); </del> <ins> ReactComponentBrowserEnvironment.unmountIDFromEnvironment(this._rootNodeID); </ins> this._rootNodeID = null; }

Logging and reveals: Which doesn't make sense (to me at least).
Can you log the too and something to distinguish the two renderComponent calls?
Updated, that makes more sense,


Question: args: $ReadOnlyArray<any>, ): void { const message = format(...args); <del> // Note that by calling these functions we may be creating the ID for the first time. // If the Fiber is then never mounted, we are responsible for cleaning up after ourselves. // This is important because getOrGenerateFiberID() stores a Fiber in a couple of local Maps. // If the Fiber never mounts and we don't clean up after this code, we could leak. // Fortunately we would only leak Fibers that have errors/warnings associated with them, // which is hopefully only a small set and only in DEV mode– but this is still not great. // We should clean up Fibers like this when flushing; see recordPendingErrorsAndWarnings(). const fiberID = getOrGenerateFiberID(fiber); </del> if (__DEBUG__) { debug('onErrorOrWarning', fiber, null, `${type}: "${message}"`); } // Mark this Fiber as needed its warning/error count updated during the next flush. <del> fibersWithChangedErrorOrWarningCounts.add(fiberID); </del> <ins> fibersWithChangedErrorOrWarningCounts.add(fiber); </ins> <del> // Update the error/warning messages and counts for the Fiber. const fiberMap = type === 'error' ? fiberToErrorsMap : fiberToWarningsMap; const messageMap = fiberMap.get(fiberID); </del> <ins> // Track the warning/error for later. const fiberMap = type === 'error' ? pendingFiberToErrorsMap : pendingFiberToWarningsMap; const messageMap = fiberMap.get(fiber); </ins> if (messageMap != null) { const count = messageMap.get(message) || 0; messageMap.set(message, count + 1); } else { <del> fiberMap.set(fiberID, new Map([[message, 1]])); </del> <ins> fiberMap.set(fiber, new Map([[message, 1]])); </ins> } <del> // If this Fiber is currently being inspected, mark it as needing an udpate as well. updateMostRecentlyInspectedElementIfNecessary(fiberID); </del> // Passive effects may trigger errors or warnings too; // In this case, we should wait until the rest of the passive effects have run, // but we shouldn't wait until the next commit because that might be a long time.

the block to inspect "Component" in DevTools : "Could not inspect element with id 5" Originally reported in https://user- Every time
Here's another Chrome extension build with the fix from :
Everything fixed. Awesome :+1:
FYI just published as 4.13.4


Question: expect(ReactIs.isValidElementType({type: 'div', props: {}})).toEqual(false); }); <del> it('should identify async mode', () => { </del> <ins> it('should identify concurrent mode', () => { </ins> expect(ReactIs.typeOf(<React.unstable_ConcurrentMode />)).toBe( ReactIs.ConcurrentMode, );

It seems like react-is v16.6 no longer is compatible with React v16.3 - v16.5, in that React v16.3 - v16.5 will use , but 's export will instead be . It seems like the async mode symbol needs to remain the same in react-is 16.6+, and the function would need to check both the AsyncMode and ConcurrentMode symbols.
(Note that this blocks full enzyme support of react v16.6)
Can you explain more about the case in which it’s breaking?
sure - the enzyme react 16 adapter needs to maintain support for all versions of React 16. It provides a "getDisplayNameOfNode" function, which needs to be able to return the string in React 16.3-16.5 (for ), and the string in React 16.6+ (for ). It does this by comparing the to the or symbol exports from . In the 16.3-specific adapter, this isn't an issue, but it does have to lock the version of to (which is the breaking change part) - it should be able to keep working with react v16.3 and 16.anything. If v16.6+ had an symbol export that matched what React 16.3-16.5 did, then I think this wouldn't be a problem.
If react-is v16.6+ had an AsyncMode symbol export that matched what React 16.3-16.5 did, then I think this wouldn't be a problem. I think that sounds okay, we could do it. PR?
Sure, I'll try my hand at it!
This is our mistake because we should have prefixed isAsyncMode with unstable which the actual api was. Or not included it at all. We’re treating unstable effectively as private and will break between minors. Are you ok with not supporting calls that are unstable_ in the future? Because we’ll break them several times between releases and don’t want to keep them all around in bundles.
Prefix or not, renaming things is still going to break consumers. However, I understand react decides to accept this breakage in minor versions. Either way, the value of is that it abstracts over these kind of changes. "Not including it at all" would have meant I had to hardcode this stuff inside enzyme, which defeats the whole purpose of in the first place.

In this case, the bundle size difference is negligible - when this is the case, it seems worth trying to keep back compat, even on things react has decided are effectively private.
The alternative is that we put it behind a feature flag and don’t expose the featur at all. But then it’s much harder for people to try it out for cases where breakages are ok. It’s really hard for people in many environments to use alpha builds.
I understand the dilemma. In this case, the functionality hasn't changed, and I'm not sure why it was renamed - iow i'm not sure how it helps people try it out to have the name change now, when it's still going to have to change again when it gets promoted to being stable. The tradeoffs seem to be somewhere between "difficult for people to try it out", "cause breakage in some amount of downstream tooling", or "incur a tiny additional bundle cost to maintain back compat". It's a tough call, and I'm not asking for a policy change - but in this case, the bundle size increase of seems pretty close to zero (i can't imagine it's more than a handful of bytes), and the benefit is that enzyme (and presumably other downstream tools) will be able to continue using without having to hardcode things.


Question: React.unmountComponentAtNode(container); expect(innerUnmounted).toBe(true); <del> // <Component />, <Inner />, and both <div /> elements and their wrappers // each call unmountIDFromEnvironment which calls purgeID, for a total of 6. </del> <ins> // The text and both <div /> elements and their wrappers each call // unmountIDFromEnvironment which calls purgeID, for a total of 3. </ins> // TODO: Test the effect of this. E.g. does the node cache get repopulated // after a getDOMNode call? <del> expect(ReactMount.purgeID.callCount).toBe(6); </del> <ins> expect(ReactMount.purgeID.callCount).toBe(3); </ins> }); it('should warn when shouldComponentUpdate() returns undefined', function() {

Logging and reveals: Which doesn't make sense (to me at least).
Can you log the too and something to distinguish the two renderComponent calls?
Updated, that makes more sense,


Question: if (!context) { context = emptyObject; } <del> var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(true); this._render(element, transaction, context); ReactUpdates.ReactReconcileTransaction.release(transaction); </del> <ins> ReactUpdates.batchedUpdates(_batchedRender, this, element, context); </ins> return this.getRenderOutput(); }; <ins> function _batchedRender(renderer, element, context) { var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(true); renderer._render(element, transaction, context); ReactUpdates.ReactReconcileTransaction.release(transaction); } </ins> ReactShallowRenderer.prototype.getRenderOutput = function() { return ( (this._instance && this._instance._renderedComponent &&

Calling on in a component being Shallow Rendered will result in the error being thrown. I set up a test case:
Who would be best to answer this one?
Seems like a valid bug report — thanks and the test case is rad. I may not be able to look at this for a while, unfortunately.
no worries let me know if you need any more info from me. This was on React 14 beta btw (not sure if that matters)
I have the same issue. A simpler example that throws the error:
Any way of getting around this issue? I am currently running into it.
Sorry about the slow response from us (FB) here. I'm the principal author of the shallow render feature, but React core isn't my main gig and I've been swamped with product work. I don't have an offhand answer for you, but I've just put time on my calendar to look into this next week. Jim, Ben, Paul — if by chance one of you happened to take care of this before then, I wouldn't be mad :)
An update on my end. I think that my problem actually went away when I deduped my npm dependencies to remove an extra react version that was causing issues. If this error pops up again I'll let you know. Thanks for the response! On Fri, Aug 28, 2015, 9:38 PM Scott Feeney wrote:
Hmm I am still able to reproduce this issue in my test case after running npm dedupe
Just to clarify, my previous comment wasn't supposed to mean that the issue has gone away. I think I was seeing a separate issue caused by multiple react versions that I misidentified as this issue (I hope that makes sense).
I am getting this error, too. I'm using react v0.14.0-rc1. Looking at the code : Apparently .
Note that shallow rendered components override to return a instead of whatever it normally returns. That still shouldn't be undefined and should have a attribute, though.
I'm experiencing this issue too - your suggestion gets me past the initial error & on to in
Pretty sure this breaks many other things outside of , but I noticed moving to be directly above in fixed this for me.
We are also affected by this issue.

I think shallow rendering is a really cool feature for testing, but unfortunately I can't use it for some of our components due to this bug.
I created pull request with a fix that works for me. Can someone else verify?
Any workaround for this issue?
:+1: Having same issue
Just ran into this too :/
Any update on this? I see that 0.14.3 was released, but these kind of tests are still failing.
I think I have to add a test to my pull request before it can be merged, but I did not get around to do it yet.
Closing in favor of which should merge soon.


Question: var ReactMount = require('ReactMount'); var ReactPerf = require('ReactPerf'); <del> var getTextContentAccessor = require('getTextContentAccessor'); </del> var invariant = require('invariant'); /**

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: `); }); <ins> // See github.com/facebook/react/issues/21654 it('should support Proxies that dont return an iterator', async () => { const Example = () => null; const proxy = new Proxy( {}, { get: (target, prop, receiver) => { target[prop] = value => {}; return target[prop]; }, }, ); const container = document.createElement('div'); await utils.actAsync(() => ReactDOM.render(<Example proxy={proxy} />, container), ); const inspectedElement = await inspectElementAtIndex(0); expect(inspectedElement.props).toMatchInlineSnapshot(` Object { "proxy": Object { "$$typeof": Dehydrated { "preview_short": ƒ () {}, "preview_long": ƒ () {}, }, "Symbol(Symbol.iterator)": Dehydrated { "preview_short": ƒ () {}, "preview_long": ƒ () {}, }, "constructor": Dehydrated { "preview_short": ƒ () {}, "preview_long": ƒ () {}, }, }, } `); }); </ins> describe('$r', () => { it('should support function components', async () => { const Example = () => {

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: } if (styleValue != null) { serialized += processStyleName(styleName) + ':'; <del> serialized += dangerousStyleValue(styleName, styleValue) + ';'; </del> <ins> serialized += dangerousStyleValue(styleName, styleValue, component) + ';'; </ins> } } return serialized || null;

It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.


Question: nearestMountedAncestor: Fiber | null, error: mixed, ) { <ins> if (__DEV__) { setIsRunningInsertionEffect(false); } </ins> if (sourceFiber.tag === HostRoot) { // Error was thrown at the root. There is no parent, so the root // itself should capture it.

Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?


Question: var Constructor = ConvenienceConstructor.type; var proto = Constructor.prototype; <ins> // By handling mixins before any other properties, we ensure the same // chaining order is applied to methods with DEFINE_MANY policy, whether // mixins are listed before or after these methods in the spec. if (spec.hasOwnProperty(MIXINS_KEY)) { RESERVED_SPEC_KEYS.mixins(ConvenienceConstructor, spec.mixins); } </ins> for (var name in spec) { <del> var property = spec[name]; </del> if (!spec.hasOwnProperty(name)) { continue; } <ins> if (name === MIXINS_KEY) { // We have already handled mixins in a special case above continue; } var property = spec[name]; </ins> validateMethodOverride(proto, name); if (RESERVED_SPEC_KEYS.hasOwnProperty(name)) {

Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.


Question: * Specifies the order in which each transform should run. */ var transformRunOrder = [ <ins> 'reserved-words', </ins> 'es6-arrow-functions', 'es6-object-concise-method', 'es6-object-short-notation',

When I run: The following error is thrown: I'm trying to use a library called in an isomorphic app, which needs server-side rendering. The module works fine client-side, but the JSX/ES6 isn't playing nice on the server even though the server's already set up to render React components and other JSX code. As stated , it seems there's a transformation supported in (via its flag) which isn't supported in . I say "seems" because I have a hard time believing can't do the same thing. What am I missing?


Question: const nodeRequire = module && module[requireString]; // assuming we're in node, let's try to get node's // version of setImmediate, bypassing fake timers if any. <del> enqueueTaskImpl = nodeRequire('timers').setImmediate; </del> <ins> enqueueTaskImpl = nodeRequire.call(module, 'timers').setImmediate; </ins> } catch (_err) { // we're in a browser // we can't use regular timers because they may still be faked

React version: 16.13.1 This code works fine when using plain , but fails: when is enabled: The warning is caused by an exception happened in this block: This is happening because module brings its own implementation of the object with slightly different behavior which requires context to be properly preserved. This one-line change should do the fix: This issue has also been reported to React-testing-library, which has similar code: Why should this be a fix in React and not in ESM? React relied on undocumented behavior of Node modules loader. It was never guaranteed that it will work without proper context. In fact, it will not work as expected if you try it with any non built-in module The current code in React may break in future if module will be replaced with anything else, or if changes their internal implementation.
Do you want to submit a PR It sounds like a reasonable thing for us to fix.
I could, however I am not sure about testing part. What kind of tests would you expect for this?


Question: jest.runOnlyPendingTimers(); data = [ <del> await getErrorsAndWarningsForElement(1), await getErrorsAndWarningsForElement(2), </del> <ins> await getErrorsAndWarningsForElementAtIndex(0), await getErrorsAndWarningsForElementAtIndex(1), </ins> ]; expect(data).toMatchInlineSnapshot(` Array [

the block to inspect "Component" in DevTools : "Could not inspect element with id 5" Originally reported in https://user- Every time
Here's another Chrome extension build with the fix from :
Everything fixed. Awesome :+1:
FYI just published as 4.13.4


Question: var ReactTransitionGroup = require('ReactTransitionGroup'); var ReactUpdates = require('ReactUpdates'); <del> var cx = require('cx'); </del> var cloneWithProps = require('cloneWithProps'); var shallowCompare = require('shallowCompare'); var update = require('update');

Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors


Question: ### Getting started <del> For this tutorial, we'll use prebuilt JavaScript files on a CDN. Open up your favorite editor and create a new HTML document: </del> <ins> For this tutorial, we'll use prebuilt JavaScript files on a CDN. Open up `public/index.html` in your favorite editor, which should contain the following: </ins> ```html <!-- index.html -->

Not reporting a bug or issue. I just wanted to let you know I found this part of the walk-through to be unclear and confusing and others may, too: It took me a while to figure out whether I was supposed to be editing in the file provided when I cloned the repo or whether I should make a new file and how to link the two files if they were both necessary. I'm new to React and pretty new to programming overall, but I do have some Javascript and Javascript framework experience. I really enjoyed the walk-through because it was simple to get started, so thanks for the helpful resource!!
Good catch & thanks for the heads up! I'd definitely call that a bug :) We really need to go through the tutorial and make sure it's all cohesive. After 2 years of ad hoc updating it's definitely showing its age. If you have any other feedback (especially as somebody who is relatively new to programming), we'd definitely appreciate it.
No problem! I'm happy to help. Will definitely let you know if I see anything else. Thanks again for the great resources!
I've opened a PR with a minor change to make the bit that mentioned a little easier to follow. +1 on making sure the tutorial is cohesive. What are your thoughts on bringing the actual tutorial as a sub-directory of the React project as opposed to being in a separate repository? I am not even sure myself if that's the best way to go about it, but at least things wouldn't be going out of sync as they are now. If you look at the source code for the tutorial and compare it to the tutorial instructions in the React repo there are some striking differences which might catch people out. The major drawback with this approach would be having to clone the entire React source when you want to get just the tutorial, but I actually don't think that's a bad idea. It might even encourage people to have a poke about the source code, which is always a good thing.


Question:
expect(aUpdated).toBe(true); });  it('should flush updates in the correct order', function() { var updates = []; var Outer = React.createClass({ getInitialState: function() { return {x: 0}; }, render: function() { updates.push('Outer-render-' + this.state.x); return
<Inner x={this.state.x} ref="inner" />
; }, componentDidUpdate: function() { var x = this.state.x; updates.push('Outer-didUpdate-' + x); updates.push('Inner-setState-' + x); this.refs.inner.setState({x: x}, function() { updates.push('Inner-callback-' + x); }); } }); var Inner = React.createClass({ getInitialState: function() { return {x: 0}; }, render: function() { updates.push('Inner-render-' + this.props.x + '-' + this.state.x); return
; }, componentDidUpdate: function() { updates.push('Inner-didUpdate-' + this.props.x + '-' + this.state.x); } }); var instance = ReactTestUtils.renderIntoDocument(<Outer />); updates.push('Outer-setState-1'); instance.setState({x: 1}, function() { updates.push('Outer-callback-1'); updates.push('Outer-setState-2'); instance.setState({x: 2}, function() { updates.push('Outer-callback-2'); }); }); expect(updates).toEqual([ 'Outer-render-0', 'Inner-render-0-0', 'Outer-setState-1', 'Outer-render-1', 'Inner-render-1-0', 'Inner-didUpdate-1-0', 'Outer-didUpdate-1', 'Inner-setState-1', 'Inner-render-1-1', 'Inner-didUpdate-1-1', 'Inner-callback-1', 'Outer-callback-1', 'Outer-setState-2', 'Outer-render-2', 'Inner-render-2-1', 'Inner-didUpdate-2-1', 'Outer-didUpdate-2', 'Inner-setState-2', 'Inner-render-2-2', 'Inner-didUpdate-2-2', 'Inner-callback-2', 'Outer-callback-2' ]); }); it('should queue nested updates', function() { // See https://github.com/facebook/react/issues/1147 var X = React.createClass({ getInitialState: function() { return {s: 0}; }, render: function() { if (this.state.s === 0) { return
 0
; } else { return
1
; } }, go: function() { this.setState({s: 1}); this.setState({s: 0}); this.setState({s: 1}); } }); var Y = React.createClass({ render: function() { return
 <Z />
; } }); var Z = React.createClass({ render: function() { return
; }, componentWillUpdate: function() { x.go(); } }); var x; var y; x = ReactTestUtils.renderIntoDocument(<X />); y = ReactTestUtils.renderIntoDocument(<Y />); expect(x.getDOMNode().textContent).toBe('0'); y.forceUpdate(); expect(x.getDOMNode().textContent).toBe('1'); }); it('should queue updates from during mount', function() { // See https://github.com/facebook/react/issues/1353 var a; var A = React.createClass({ getInitialState: function() { return {x: 0}; }, componentWillMount: function() { a = this; }, render: function() { return
A{this.state.x}
; } }); var B = React.createClass({ componentWillMount: function() { a.setState({x: 1}); }, render: function() { return
; } }); ReactUpdates.batchedUpdates(function() { ReactTestUtils.renderIntoDocument(

 ); }); expect(a.state.x).toBe(1); expect(a.getDOMNode().textContent).toBe('A1'); }); it('calls componentWillReceiveProps setState callback properly', function() { var callbackCount = 0; var A = React.createClass({ getInitialState: function() { return {x: this.props.x}; }, componentWillReceiveProps: function(nextProps) { var newX = nextProps.x; this.setState({x: newX}, function() { // State should have updated by the time this callback gets called expect(this.state.x).toBe(newX); callbackCount++; }); }, render: function() { return
{this.state.x}
; } }); var container = document.createElement('div'); React.renderComponent(, container); React.renderComponent(, container); expect(callbackCount).toBe(1); });  });

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: var instance; var Component = createReactClass({ displayName: 'MyComponent', <ins> mixins: [ { componentWillMount() { this.log('mixin.componentWillMount'); }, componentDidMount() { this.log('mixin.componentDidMount'); }, componentWillUpdate() { this.log('mixin.componentWillUpdate'); }, componentDidUpdate() { this.log('mixin.componentDidUpdate'); }, componentWillUnmount() { this.log('mixin.componentWillUnmount'); }, }, ], </ins> log(name) { ops.push(`${name}: ${this.isMounted()}`); },

Do you want to request a feature or report a bug? Bug What is the current behavior? Calling in in prior versions would return . Now it returns . I believe this was untested behavior before, but the new tests that were may check the wrong value: Changing this line to test for will exhibit the behavior. The fix would be to defer setting the flag to until after all mixins and the method were called on the component. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? and anything using is broken. Working correctly in 15.4.x with .
I fixed this locally by splitting the IsMountedMixin into two: Then installing the Post after the spec has been mixed in: For the life of me I can't find the right repo to PR this against though.
This should be fixed with . Can you please verify?
I don't see that version published yet.
It's not set to (still an RC) but it exists: Will turn into 15.6.0 tomorrow.
Ah indeed. It's probably our internal registry being slow. I'll try it out soon.
Confirmed working correctly in .
Great. Thanks for sending the fix!


Question: "/.module-cache/" ], "testPathDirs": [ <del> "<rootDir>/src" </del> <ins> "<rootDir>/src", "<rootDir>/eslint-rules" </ins> ], "unmockedModulePathPatterns": [ ""

using npm mocha is not necessarily at (thanks to hoisting). (eg it's actually at for me)
We've found out that it's possible to use eslint-tester with jest, so we should just do that.


Question: toggleParseHookNames(); }; <ins> const hookParsingFailed = parseHookNames && hookNames === null; let toggleTitle; if (hookParsingFailed) { toggleTitle = 'Hook parsing failed'; } else if (parseHookNames) { toggleTitle = 'Parsing hook names ...'; } else { toggleTitle = 'Parse hook names (may be slow)'; } </ins> const handleCopy = () => copy(serializeHooksForCopy(hooks)); if (hooks === null) {

The named hooks cache returns The first (mixed array of string and null) indicates an overall success, even if some names couldn't be inferred. The second indicates an error (e.g. couldn't locate or load source map). In the event of the 2nd response type, the UI currently does nothing (falls back to default) but we should show an error badge (maybe a disabled but red icon with a tooltip saying there was an error) since it's a confusing user experience to just do nothing.


Question: expect(summary).toEqual([]); }); <ins> it('should not fail on input change events', function() { var container = document.createElement('div'); var onChange = () => {}; var input = ReactDOM.render( <input checked={true} onChange={onChange} />, container ); expectNoWaste(() => { ReactTestUtils.Simulate.change(input); }); }); </ins> it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => {

Calling results in: (this is on a page internally at Facebook so I assume it's a fairly recent React version)
Are you still experiencing this issue internally? If so, can you create an internal task with details and repro steps? Assign to the oncall, cc the React team. Our internal configuration is a bit different, and we don't want to discuss internal code/details/configurations on github. I'm going to close this out, and we can help you debug using internal tools if you're still running into problems.
Small note for anyone experiencing a similar error message who arrived here by Googling: I got bit by this because I updated and without updating at the same time.
I'm getting this issue after upgrading to react 15.0.1. All my React packages (including perf) is 15.0.1. printExclusive() etc. works, but printWasted gives the exception shown above.
Are you running before using it?
Yes. , and the rest of the Perf API works, for example , but not . I changed over to my 0.14.7 branch, and there everything works like it should, and I double checked that both ReactPerf and React was on 15.0.1. ! I can dig around a bit more if this isn't anything known.
Let’s reopen until we hear more.
I had it working for a few minutes and then it started failing without me doing anything strange.
Thanks for the info, do you also have the same stack trace and error message as the first post?
Yes. I was exposing the object as . I tried again exposing it as and it's working again. Puzzling. I'm using the full 15.0.1 ecosystem, on Babel 6, Webpack and Webpack dev server, testing on Chrome.
Any chance you have a public project where you can more or less consistently reproduce this?
Technically this means there was for which there was no . This code is super fragile so it’s hard to pin it down without having a specific component hierarchy that happens to cause this.
If someone wants to spend some effort tracking it down, I would recommend: just before in . just before in . Then please share the relevant logs that correspond to the ID you see in the message.
Thanks Dan, I'll try setting up that to see if I can help.

Unfortunately I cannot share my project right now because of client terms.
Yeah, I thought this might be the case. Thanks for taking the time to investigate.
OK I the lines and I managed to also reproduce the error. . FYI, my app is a SPA, I captured this on a route where I have a long list of items that can be filtered by certain criteria and doing before filtering and after some of those items were removed because of the filtering.
Thank you, this is very helpful! I’ll dig into it and see if I can repro this given the new info.


Question: export const REACT_CONTEXT_TYPE = hasSymbol ? Symbol.for('react.context') : 0xeace; <ins> export const REACT_ASYNC_MODE_TYPE = hasSymbol ? Symbol.for('react.async_mode') : 0xeacf; </ins> export const REACT_CONCURRENT_MODE_TYPE = hasSymbol ? Symbol.for('react.concurrent_mode') : 0xeacf;

It seems like react-is v16.6 no longer is compatible with React v16.3 - v16.5, in that React v16.3 - v16.5 will use , but 's export will instead be . It seems like the async mode symbol needs to remain the same in react-is 16.6+, and the function would need to check both the AsyncMode and ConcurrentMode symbols.
(Note that this blocks full enzyme support of react v16.6)
Can you explain more about the case in which it’s breaking?
sure - the enzyme react 16 adapter needs to maintain support for all versions of React 16. It provides a "getDisplayNameOfNode" function, which needs to be able to return the string in React 16.3-16.5 (for ), and the string in React 16.6+ (for ). It does this by comparing the to the or symbol exports from . In the 16.3-specific adapter, this isn't an issue, but it does have to lock the version of to (which is the breaking change part) - it should be able to keep working with react v16.3 and 16.anything. If v16.6+ had an symbol export that matched what React 16.3-16.5 did, then I think this wouldn't be a problem.
If react-is v16.6+ had an AsyncMode symbol export that matched what React 16.3-16.5 did, then I think this wouldn't be a problem. I think that sounds okay, we could do it. PR?
Sure, I'll try my hand at it!
This is our mistake because we should have prefixed isAsyncMode with unstable which the actual api was. Or not included it at all. We’re treating unstable effectively as private and will break between minors. Are you ok with not supporting calls that are unstable_ in the future? Because we’ll break them several times between releases and don’t want to keep them all around in bundles.
Prefix or not, renaming things is still going to break consumers. However, I understand react decides to accept this breakage in minor versions. Either way, the value of is that it abstracts over these kind of changes. "Not including it at all" would have meant I had to hardcode this stuff inside enzyme, which defeats the whole purpose of in the first place.

In this case, the bundle size difference is negligible - when this is the case, it seems worth trying to keep back compat, even on things react has decided are effectively private.
The alternative is that we put it behind a feature flag and don’t expose the featur at all. But then it’s much harder for people to try it out for cases where breakages are ok. It’s really hard for people in many environments to use alpha builds.
I understand the dilemma. In this case, the functionality hasn't changed, and I'm not sure why it was renamed - iow i'm not sure how it helps people try it out to have the name change now, when it's still going to have to change again when it gets promoted to being stable. The tradeoffs seem to be somewhere between "difficult for people to try it out", "cause breakage in some amount of downstream tooling", or "incur a tiny additional bundle cost to maintain back compat". It's a tough call, and I'm not asking for a policy change - but in this case, the bundle size increase of seems pretty close to zero (i can't imagine it's more than a handful of bytes), and the benefit is that enzyme (and presumably other downstream tools) will be able to continue using without having to hardcode things.


Question: *    React Core     .  General Purpose Event Plugin System */ <ins> var hasEventPageXY; </ins> var alreadyListeningTo = {}; var isMonitoringScrollValue = false; var reactTopListenersCounter = 0;

React adds a scroll listener that tracks and caches the scroll position (I assume for some undocumented internal purpose). Additionally, the scroll listener forces a synchronous layout (see screenshot). This seems wasteful, especially considering that the values tracked are never exposed in the API. What is the scroll listener used for? Can it be removed? !
ViewportMetrics is used to normalize pageX and pageY on mouse events: . Perhaps ironically, it was created to prevent synchronous layouts during mouse event handlers.
I wish these values (as well as the event) were somehow exposed.
:+1:
BTW you can obviously have this if you use a Webpack-like bundler:
Well, is only used for IE8 and possibly other very old browsers (), so we should be able to just disable it for all other browsers and everyone is happy right? (Could still be optimized slightly for IE8... if anyone cares) Also, That makes no sense at all to me, does not take an argument, yet we get the scroll position and provide it as an argument. Instead, gets the scroll position internally and uses that? So we call twice, but only use the result once (also, this should be broken for events inside iframes, for IE8). Also2, I'm pretty sure any browsers that supports touch, also supports . cc
I agree that we shouldn't be tracking it in other browsers if we don't need it. I don't know if there's a way to predict whether we'll have .pageX and .pageY before mouse events actually come in.
:)
Another idea being just let resize/scroll set a flag, when a mouse event is created, if the flag is set, update viewport metrics. That way we only update it when needed, but could potentially cause a reflow if there are other events before it (very unlikely though I imagine).
This issue causes React based longer lists unusable on mobile.
Is there any progress on this issue? I’m not sure if this is the root-cause for pages rendered with react scrolling extremely slow with firefox mobile on android (e.g. this react website ).
Is that your site? If so, you can try commenting out the logic in refreshScrollValues to see if it makes a difference. If it does, I'm happy to prioritize and try to get it in.

No, that is not my site, it is an example react & fluxible page (see: ), but we have exactly the same issues with scrolling on firefox mobile. I’ve applied the changes in manually and it doesn’t solves the problem, so this issue might be unrelated to my problem. I will investigate further. Thanks for considering to prioritize this. Much appreciated.


Question: var initialState = this.getInitialState ? this.getInitialState() : null; if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. <del> if (typeof initialState === 'undefined' && </del> <ins> if (initialState === undefined && </ins> this.getInitialState._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience.

Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.


Question: ); }); <ins> it('should allow {__html: null}', function() { expect(function() { mountComponent({dangerouslySetInnerHTML: {__html: null} }); }).not.toThrow(); }); </ins> it("should warn about contentEditable and children", function() { spyOn(console, 'error'); mountComponent({contentEditable: true, children: ''});

In following JSX fragment I should guarantee that will never be or : Otherwise throws an error although construction is correct: Should instead of check for ?
Someone else mentioned this being surprising to me too.
I've been experiencing the same issues recently
As far as I understand it, the idea is that is basically the equivalent of a HTML-type. You're not meant to use it as , but as so that you cannot accidentally pass unsafe data. So should be or , in this model it does not make sense to have .
That doesn't mean that people won't write it as – doing so is even pretty reasonable if you're careful about naming your vars/props and do .
The simplest workaround is to coerce into an empty string with . +1 for having React do this internally.
Got surprised by this today, upgrading from to . Was it a "bug" in (i.e. it shouldn't have accepted ), or is it a bug in ? Anyway, will use as suggested by just wanted to point out that it seemed to "work" in .


Question: // Should be document order, not mount order (which would be purple, orange) expect(log).toEqual(['orangepurple', 'orange', 'purple']); }); <ins> it('does not warn for getDOMNode on ES6 classes', function() { var Foo = React.createClass({ render: function() { return <div />; } }); class Bar extends React.Component { render() { return <div />; } } spyOn(console, 'warn'); var foo = ReactTestUtils.renderIntoDocument(<Foo />); expect(ReactTestUtils.isDOMComponent(foo)).toBe(false); var bar = ReactTestUtils.renderIntoDocument(<Bar />); expect(ReactTestUtils.isDOMComponent(bar)).toBe(false); var div = ReactTestUtils.renderIntoDocument(<div />); expect(ReactTestUtils.isDOMComponent(div)).toBe(true); expect(console.warn.calls.length).toBe(0); }); </ins> });

TestUtils.isDOMComponent(...) uses deprecated Element.getDOMNode(), resulting in console warnings when running tests. In my case, running 175 unit tests results in 700+ such warnings, drowning the output of the tests.
How are what tests are you running?
The tests are standard unit tests for custom React components. For example, I have a Toggle component that dispatches an event with type '' when clicked.
I'm also seeing the same issue testing under karma and mocha.
it looks like you this TODO? Can we get this fixed? Happy to help, but not sure what the right heuristic is.
This is unfortunate. I don't quite know what the right heuristic should be for 0.13, but we're changing it for 0.14 anyway since refs on DOM component will just be regular DOM nodes so I think we'll just power through. :/
Maybe we can do ?
I was thinking that we can reuse string types for ART and React Native too. We wouldn't want a React Native node to hit this.
maybe then?
It is not an own property. (And will be deprecated anyway so not a great heuristic.)
Lets just move fast on the ref === real DOM node stuff instead of spending time figuring this out.


Question: ReactCache = require('react-cache'); Suspense = React.Suspense; container = document.createElement('div'); <ins> document.body.appendChild(container); </ins> TextResource = ReactCache.unstable_createResource(([text, ms = 0]) => { return new Promise((resolve, reject) =>

<!-- 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? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. 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.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens.

~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.


Question: } else if (expectedMessages.length === 1) { errorMessage = 'Unexpected warning recorded: ' + <del> jestDiff(normalizedMessage, expectedMessages[0]); </del> <ins> jestDiff(expectedMessages[0], normalizedMessage); </ins> } else { errorMessage = 'Unexpected warning recorded: ' + <del> jestDiff([normalizedMessage], expectedMessages); </del> <ins> jestDiff(expectedMessages, [normalizedMessage]); </ins> } // Record the call stack for unexpected warnings.

Do you want to request a feature or report a bug? bug What is the current behavior? calls as and :  where by default is annotated as (green), as (red). What is the expected behavior? should pass the expected values into , the actual (received) values into of :


Question: topError: null, topFocus: null, topInput: null, <ins> topInvalid: null, </ins> topKeyDown: null, topKeyPress: null, topKeyUp: null,

Ref:
I'm taking a look at this as a first bug - from the docs and some testing, the event seems to be fired at the form element level rather than the form itself. That is to say: will not log on submit, but: will log on submit. Does this match the expected behaviour, and if so do we want the handler to be on the individual React.DOM form elements (i.e. so it is called when that element is invalid), or do we want it to bubble up to the parent (i.e. so it is called whenever at least one element in that form is invalid)?
We should match the DOM and fire it on the element (not the form). We already have support for these events which don't bubble. Most of our events are at the document level and then delegated but the ones which don't bubble need to be to specific elements on creation. Here's how we're doing it for forms and the submit & reset events: Thanks for taking this on! Feel free to get a PR up before it's completely ready if you have questions / need help.
Thanks Paul, good to know I was looking in the right place! Will update when I have had time to create a PR or if I need any help :) Cheers Tom
Hey, I've put together a PR at - it would be great to get your feedback on it. A couple of specific questions I had: should I handle automated testing of this? There's a lot of test code to look at and I'm unfamiliar with the React codebase, so I'm unsure if/how this should be tested. the splitting out of the logic make sense? Or do you think it would be better to have a separate statement for this bit, preceeding the other in , matching all the elements which need this setup, and then keep the other as is (minus the first ) Any feedback appreciated, this does seem to work but I'm totally new to the React code so not sure if the way I've gone about it is suitable or not! Cheers, Tom
Awesome!


Question:
 --- title: JSFiddle Integration layout: post author: Vjeux --- [JSFiddle](http://jsfiddle.net) just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this **[base React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)**, fork it and share it! A [fiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) is also available .

React (by Facebook) is now available on JSFiddle. facebook.github.io/react/
— JSFiddle (@jsfiddle) June 2, 2013

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


Question: onHookOperations = (operations: Array<number>) => { if (__DEBUG__) { <del> debug('onHookOperations', operations); </del> <ins> debug( 'onHookOperations', `(${operations.length}) [${operations.join(', ')}]`, ); </ins> } // TODO:

did profiling on a list, that gets updated on each pagination api call. the profiling was done, I moved around in the Profiler to view the Flamegraph to second capture, the Profiler crashed. DevTools version: 4.6.0-
What does this mean? Can you repro this bug? And if so, could you share steps for repro with us?
Sorry for not providing enough details, but even I don't have enough details. This error just popped up when I was profiling my app in React Devtools. I was profiling a normal () list, and it broke when I clicked next button on DevTools, to see the recorded profile. <img width="1149" alt="Screenshot 2020-05-08 at 11 12 50 AM" src="https://user-"About having a repro, I couldn't replicate it myself after that one occurrence, again. Anyways, my assumption is (it could be wrong), one of the list item in the flame graph is getting duplicated somehow, either due to the app it was profiling or due to something else.
Okay. Thanks for clarifying.
If no-one is working on this, I would like to assign myself to investigate and fix the issue (since multiple people have referenced it). Also, If you assign me, Can you please also help me with where to look?
If you'd like to dig into this, we'd be happy to have the help. I don't really have the bandwidth to guide you on it though. Some places you'd want to look at for starters:    And for a general overview of how DevTools works, you can check out this:
This error remains the highest reported DevTools bug but we still don't have a repro case so that I can fix it. Do you remember how to repro the error you saw above? Can you share the steps with me if so? It would be very helpful! Thank you
Hi Will try to replicate it again... It's been a long time since I used the Profiler, so I don't remember much.
Okay, understood! Either way, thanks for checking.
I've got a repro for this over on : When I run this project, I see an error in DevTools: This is very promising! Looks like there's a problem with Suspense and LegacyHidden.

I think the case I'm seeing is this: initial render, a Suspense component is mounted. has an Offscreen child, b'c of how Suspense is implemented internally, but DevTools hides this implementation detail to avoid confusion. (What this actually means is that the DevTools backend never even tells the frontend that the Offscreen component exists.) login, stuff is updated and for some reason, the backend thinks it needs to unmount the Offscreen component (even though the frontend never knew about it). This causes an error to be thrown. Unfortunately this thrown error is not surfaced in the UI so things go on until later, when it causes a downstream error in the Profiler. First step is making that first error visible (done via ). Second step is to figure out why it's happening. Interestingly, if I trim down the repro a to the minimal repro case, then copy that into the React DevTools test harness (with a bleeding edge build of react and react-dom) the bug no longer happens. Edit 1: If I copy it instead into a project created by – with the same major versions of react and react-dom, I can repro the bug. So that's good. Seems like something may have changed on the React side between 17.0.2 and HEAD? Edit 2: One (possibly) significant difference between the two versions is that 17 uses the component beneath but HEAD uses the newer component. I can also repro the same error in the DevTools test shell by swapping with so...
Oooh looks like this may have just been an oversight in our filtering logic. (We filter but not components. Eventually we'll not want to filter but for now, that seems an easy fix.
This bug fix has been released as 4.13.1


Question: expect(typeof Component.specialType.isRequired).toBe('function'); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('is indistinguishable from a plain object', function() { var element = React.createElement('div', {className: 'foo'}); var object = {}; expect(element.constructor).toBe(object.constructor); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('should use default prop value when removing a prop', function() { var Component = React.createClass({ getDefaultProps: function() {

The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.


Question: onChange={this.handleCodeChange} codeText={compiledCode} readOnly={true} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXContent =

is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !


Question: It is a good idea to avoid spamming the console with duplicate warnings: <del> ````js </del> <ins> ```js </ins> var warning = require('warning'); var didWarnAboutMath = false;

There appears to be a typo on line 116 of "codebase-". Specifically, I see one "" symbol. This results in all text after line 116 appearing as one large block of code. See the screenshot below, with the markdown code on the left and the stylized code rendered on the right: <img width="1389" alt="screen shot 2017-01-09 at 2 38 51 pm" src=""Based on the content of the subsequent text after line 116, I would expect it to appear as the following: <img width="1436" alt="screen shot 2017-01-09 at 2 42 08 pm" src=""If this is indeed something that should be fixed, I'd like to fix it, and can submit a PR immediately.
I think you're right, please do submit a PR.
(For future reference, feel free to send PRs for small fixes like this without creating an issue.)


Question: | `tabIndex=(array with string)`| (initial)| `<number: -1>` | | `tabIndex=(empty array)`| (initial)| `<number: -1>` | | `tabIndex=(object)`| (initial)| `<number: -1>` | <del> | `tabIndex=(numeric string)`| (initial, ssr mismatch)| `<number: -1>` | </del> <ins> | `tabIndex=(numeric string)`| (changed)| `<number: 42>` | </ins> | `tabIndex=(-1)`| (initial)| `<number: -1>` | <del> | `tabIndex=(0)`| (initial, ssr mismatch)| `<number: -1>` | | `tabIndex=(integer)`| (initial, ssr mismatch)| `<number: -1>` | </del> <ins> | `tabIndex=(0)`| (changed)| `<number: 0>` | | `tabIndex=(integer)`| (changed)| `<number: 1>` | </ins> | `tabIndex=(NaN)`| (initial, warning)| `<number: -1>` | <del> | `tabIndex=(float)`| (initial, ssr mismatch)| `<number: -1>` | </del> <ins> | `tabIndex=(float)`| (changed)| `<number: 99>` | </ins> | `tabIndex=(true)`| (initial, warning)| `<number: -1>` | | `tabIndex=(false)`| (initial, warning)| `<number: -1>` | | `tabIndex=(string 'true')`| (initial)| `<number: -1>` | | `tabIndex=(string 'false')`| (initial)| `<number: -1>` | | `tabIndex=(string 'on')`| (initial)| `<number: -1>` | | `tabIndex=(string 'off')`| (initial)| `<number: -1>` | <del> | `tabIndex=(symbol)`| (initial, warning)| `<number: -1>` | </del> <ins> | `tabIndex=(symbol)`| (initial, warning, ssr error, ssr mismatch)| `<number: -1>` | </ins> | `tabIndex=(function)`| (initial, warning)| `<number: -1>` | | `tabIndex=(null)`| (initial)| `<number: -1>` | | `tabIndex=(undefined)`| (initial)| `<number: -1>` |

See the original report in The problem is that SVG is case sensitive, and so naïvely setting and relying on insensitivity won't work with it. The good news is it seems like is the only valid with this problem. We just missed it because it applies both to HTML and SVG. I think the fix is to add it back to the whitelist.
simple example where tabbing works & doesn't work depending on case Note that the console does not state the error did you mean not being Not really sure why this is but it does display in our app.
Thanks for confirming this issue, I've been struggling to identify the reason my svg component stopped working after the update. A component made of clickable <circleshave lost both focus and blur functionality, because "tabIndex" is rendered in the camelCase style and then ignored by the browser. I've tried adding the property "tabindex" to the <circletag in the jsx, but it was swallow by React and not rendered to the final component.
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
apologies just seeing this message now. Yes. The issue is resolved with the beta, rc & 16.1