Question: outfile: './build/react-with-addons.js', debug: false, standalone: 'React', <del> transforms: [envify({NODE_ENV: 'development'})], </del> packageName: 'React (with addons)', <del> after: [es3ify.transform, simpleBannerify] </del> <ins> transforms: [envify({NODE_ENV: 'development'})], after: [es3ify.transform, derequire, simpleBannerify] </ins> }; <del> var addonsMin = _.merge({}, addons, { </del> <ins> var addonsMin = { entries: [ './build/modules/ReactWithAddons.js' ], </ins> outfile: './build/react-with-addons.min.js', debug: false, <ins> standalone: 'React', packageName: 'React (with addons)', </ins> transforms: [envify({NODE_ENV: 'production'}), uglifyify], <del> after: [minify, bannerify] }); </del> <ins> after: [es3ify.transform, derequire, minify, bannerify] }; </ins> var withCodeCoverageLogging = { entries: [

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: newState = workInProgress.memoizedState; if ( <del> oldProps === newProps && </del> <ins> unresolvedOldProps === unresolvedNewProps && </ins> oldState === newState && !hasContextChanged() && !checkHasForceUpdateAfterProcessing()

<!-- 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? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is


Question: * in `next` in a reasonable order. */ mergeKeySets: function(prev, next) { <ins> prev = prev || {}; next = next || {}; </ins> var keySet = {}; var prevKeys = Object.keys(prev).concat([MERGE_KEY_SETS_TAIL_SENTINEL]); var nextKeys = Object.keys(next).concat([MERGE_KEY_SETS_TAIL_SENTINEL]);

Consider this example: If is false or undefined, will be and will throw
Want to take a go at fixing this? I think it would be a good opportunity to learn a bit more about a constrained subset of internals.
yea - i'll give it a shot :)


Question: ); var CodeMirrorEditor = React.createClass({ <ins> propTypes: { lineNumbers: React.PropTypes.bool, onChange: React.PropTypes.func }, getDefaultProps: function() { return { lineNumbers: false }; }, </ins> componentDidMount: function() { if (IS_MOBILE) return; this.editor = CodeMirror.fromTextArea(this.refs.editor.getDOMNode(), { mode: 'javascript', <del> lineNumbers: false, </del> <ins> lineNumbers: this.props.lineNumbers, </ins> lineWrapping: true, smartIndent: false,  // javascript mode does bad things with jsx indents matchBrackets: true,

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:
expect(summary).toEqual([]); });  it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => { ReactDOM.render(
hey
, container); }); spyOn(console, 'table'); ReactDefaultPerf.printOperations(measurements); expect(console.table.calls.length).toBe(1); expect(console.table.argsForCall[0][0]).toEqual([{ 'data-reactid': '', type: 'set innerHTML', args: '{"node":"<not serializable>","children":[],"html":null,"text":null}', }]); });  it('warns once when using getMeasurementsSummaryMap', function() { var measurements = measure(() => {}); spyOn(console, 'error');

Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.


Question: <![endif]--> <script type="text/javascript" src="/react/js/codemirror.js"></script> <script type="text/javascript" src="/react/js/javascript.js"></script> <del> <script type="text/javascript" src="/react/js/react.min.js"></script> </del> <ins> <script type="text/javascript" src="/react/js/react.js"></script> </ins> <script type="text/javascript" src="/react/js/JSXTransformer.js"></script> <script type="text/javascript" src="/react/js/live_editor.js"></script> <script type="text/javascript" src="/react/js/showdown.js"></script>

Sometimes it's helpful for to have a playground for grokking React's features, and I like to use the live editor on the docs site to sketch out ideas and see how my code is called by the library. It'd be a huge help if the site's React source was served unminified so it's more apparent what's going on under the covers.
I think this would be helpful:
I think I'd be okay with this. Want to send a PR?


Question: icon: null, id: MUST_USE_PROPERTY, inputMode: MUST_USE_ATTRIBUTE, <ins> integrity: null, </ins> is: MUST_USE_ATTRIBUTE, keyParams: MUST_USE_ATTRIBUTE, keyType: MUST_USE_ATTRIBUTE,

defines the "integrity" attribute. This attribute is not defined in HTMLDOMPropertyConfig so it is not included in HTML rendered on a server.
+1 here. Modern browsers have supported this feature. Bootstrap tell me to use the following from CDN: Here is the MDN introduction:
cc Contrary to popular belief, we do get these fairly frequently. Related to
Related in that there should be a good way of replacing whitelisting attributes, but it's not a custom attribute in the same sense as .
Yea "related", the underlying goal of that issue is to really get of the whitelist as much as possible, entirely would be good. I don't know that we called that out explicitly but they're mostly the same problem.
Yeah, my comment was directed at a conversation we had at our last team meeting when figuring out our priorities for the remainder of the year. Basically, there are a whole ton of attributes that we keep adding one-at-a-time, and I was/am pushing for us to solve and wipe them all out (past present and future) with a single swipe. But is a slightly non-trivial change with several dependencies and was thus demoted off the prioirty list :P.


Question: componentDidUpdate(object prevProps, object prevState) ``` <del> Invoked immediately after updating occurs. This method is not called for the initial render. </del> <ins> Invoked immediately after the component's updates are flushed to the DOM. This method is not called for the initial render. </ins> Use this as an opportunity to operate on the DOM when the component has been updated.

is unclear on when it is called with regards to the function. The docs state that it's "Invoked immediately after updating occurs" but it is unclear what is meant with updating in this case: it can refer to either the component as a whole updating (meaning post-render), or it can refer to setState() having been processed (which might mean pre-render). It would be good to explicitly state when this function fires in its documentation (even if somewhere else on the site this is described in text or graphic form already).
I think this part makes it clear it happens after DOM is updated (post-render): However, overall I agree more descriptive (visual?) lifecycle explanation would be welcome.
That's not clear enough, though. React does a good job making sure you normally don't work on the DOM, so in this case I really need explicit text that says "Use this as an opportunity to operate on the DOM after has finished" - without that, it still entirely possible that it's offering a way to mess with the DOM before updates from subsequent render calls are worked in.
This wouldn't be entirely correct though. doesn't do anything per se, it just builds the virtual DOM tree.
componentDidUpdate (and componentDidMount) is always called after the DOM has been updated – we can update the docs. Want to send a pull request?
I'll have to read through your CLA carefully before I can file any PRs. In the mean time, any clarification you deem addresses this issue is fine by me.
The fact that it lets you operate on the updated DOM implies that it's post-render.
sure, but I'd love to know you get that from the actual words used in the text, rather than from the text you read paired with your knowledge of React. In this case, three people went "it's after the DOM updates", so: sweet! Let's change the text from to and now it's no longer implied, now it's explicit, and new users don't scratch their head going "what do they mean with updated? The tutorials mostly talk about updating in the sense of the state and props changing, but the text also talks about working on the DOM... this isn't clear enough".
looks like PR material to me :) :+1:
indeed, and I'm not filing one until I've read that CLA.

I have issues with CLAs, which is why I'm filing this as an issue instead, and hopefully other people working on the code find opening the docs file on github, hitting "edit", and dropping that in, not too much work.
I saw that this had been closed but it appears that the documentation remains unchanged. PR seems to have been merged but I'm not sure what ever became of that since it was over 3 years ago. Perhaps the language was reverted to its original form? I think the most important takeaway from original post is that documentation should always be as explicit as possible. The fact that two people from the React team responded by saying things along the lines of "The fact that it lets you operate on the updated DOM implies that it's post-render" highlights the problem. Nothing in documentation—especially for such a widely used library—should ever be implied because it lends to assuming that the reader has the same knowledge and understanding of the code as the people who wrote it.
To chime in: is componentDidUpdate called regardless of whether there are DOM changes? In the case when render runs And there is no change between the DOM and virtual DOM, does componentDidUpdate still fire? Sorry if this should be obvious.
I'd like to know this as well. In my case, I change state, render is called, my component and it's child component both invoke their own render, but the parent's componentDidUpdate() is never fired. So, does this only file if the real DOM actually changed, or does it fire post-render, whether or not the real dom changed? FYI: my real dom did change, but the method was never called! Inquiring minds want to know!!
As pointed out, the clarification in the docs seems to have been reverted and this issue should be re-opened
If there is an issue with documentation, please file it in the documentation repository: Then we or somebody else can address it. We're not reading closed issues (it's hard enough to keep up with open ones!) so your feedback is unfortunately going into the void. Thank you!


Question: const beforeState = this._newState; if (typeof this._instance.componentWillMount === 'function') { <del> if (__DEV__) { // Don't warn about react-lifecycles-compat polyfilled components if ( warnAboutDeprecatedLifecycles && this._instance.componentWillMount.__suppressDeprecationWarning !== true ) { const componentName = getName(element.type, this._instance); if (!didWarnAboutLegacyWillMount[componentName]) { lowPriorityWarning( false, '%s: componentWillMount() 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_componentWillMount instead.', componentName, ); didWarnAboutLegacyWillMount[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 element.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: topLevelType, topLevelTarget, topLevelTargetID, <del> nativeEvent) { </del> <ins> nativeEvent, nativeEventTarget) { </ins> var getTargetIDFunc, handleEventFunc; if (shouldUseChangeEvent(topLevelTarget)) {

I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.


Question: * components with the class name matching `className`. * @return {array} an array of all the matches. */ <del> scryRenderedDOMComponentsWithClass: function(root, className) { </del> <ins> scryRenderedDOMComponentsWithClass: function(root, classNames) { if (!Array.isArray(classNames)) { classNames = classNames.split(/s+/); } </ins> return ReactTestUtils.findAllInRenderedTree(root, function(inst) { if (ReactTestUtils.isDOMComponent(inst)) { <del> var instClassName = ReactDOM.findDOMNode(inst).className; return ( instClassName && (('' + instClassName).split(/s+/)).indexOf(className) !== -1 ); </del> <ins> var classList = ReactDOM.findDOMNode(inst).className.split(/s+/); return classNames.every(function(className) { return classList.indexOf(className) !== -1; }); </ins> } return false; });

The function isn't quite working for me anymore after upgrading from 0.14-rc1 and 0.14. The error stack looks something like this:
Can you post a minimal repro case please?
The minimal repro for me is this: If I use an element -- I get the error reported above. If I use a element -- there is no error. I tried dropping this as a Jest test in the React source code -- but it passed. However, running this exact same test in my local project -- it fails. I've confirmed that all React libs are 0.14. Could there be some kind of build process that's causing the issue? The line that fails is this when is the element.
Sounds like what mentioned here:
Indeed. Looks like this is the same issue. I hope you can push that out fix in 0.14.1 soon as this is a blocking issue for my team for upgrading to 0.14. Thanks for the fast response.
We'll try. In the meantime, you could copy the definition from here since it doesn't rely on any React internals:


Question: <ins> /** * Copyright 2014 Facebook, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. * * @providesModule camelizeStyleName * @typechecks */ "use strict"; var camelize = require('camelize'); var msPattern = /^-ms-/; /** * Camelcases a hyphenated CSS property name, for example: * *   > camelizeStyleName('background-color') *   < "backgroundColor" *   > camelizeStyleName('-moz-transition') *   < "MozTransition" *   > camelizeStyleName('-ms-transition') *   < "msTransition" * * As Andi Smith suggests * (http://www.andismith.com/blog/2012/02/modernizr-prefixed/), an `-ms` prefix * is converted to lowercase `ms`. * * @param {string} string * @return {string} */ function camelizeStyleName(string) { return camelize(string.replace(msPattern, 'ms-')); } module.exports = camelizeStyleName; </ins>

We happen to "support" hyphenated keys to the style object on initial render (because we attempt to hyphenate camelcased keys) but those styles will never be updated on subsequent renders because we never attempt to unhyphenate. So we should warn when we see a hyphenated style.
Some browsers support assigning with hyphenated keys, but probably not all do.
AFAIK only Webkit does. (And I guess by association, Blink)
Perhaps another one for you!
OK
Sorry for the long delay, been busy. I'll try to do this today.
No problem, whenever you have time.
Curious: why do we not want to hyphenate names on subsequent updates, and instead show a warning? Because there should be “one way to do that”?
Yes, this matches our existing practice of requiring camel-cased attributes in general, which makes it easier to make warpper components that modify props in some way because you only need to look in one place to find the original value. In addition, you don't need to worry about what happens if someone were to specify both and in the same style block. (One last advantage: if the warnings happen only in the dev version, then there's no runtime cost in the production build.)
Do you think it's worth adding for the sake of providing a suggestive warning? (e.g. )
There you go! I also updated the docs about prefix, since it's not clear right now.
A warning would be very helpful, this just sucked up a lot of my time. If anyone is interested, chrome seems to handle hyphenated CSS props OK but FF doesn't


Question: var adler32 = require('adler32'); var TAG_END = //?>/; <ins> var COMMENT_START = /^<!--/; </ins> var ReactMarkupChecksum = { CHECKSUM_ATTR_NAME: 'data-react-checksum',

Run this: Get this: Not sure if this is a bug but I thought and friends are gone in , no? Also when testing with an old project using - which has a much complex scenario, returned following causing a blank page: Just wondering is the behavior for server rendering changing in ? Thanks.
is gone for client-side rendering, but still exists for server-side rendering. This is expected behavior. However, is NOT desired output. Can you provide an example component/render that generates this output?
This happens when a root composite component returns .
I spent all day trying to trace the root cause of the issue and ended up confirmed it's a false alarm, it was caused by lib which returns a null root component while rendering on the server. I'm currently working on different approaches to implement universal apps on both server and client, will report back if I hit any other issues with v15.
But, to be clear, this is a valid bug in React.
Update: just confirmed that is working fine with other apps in regard to server rendering once removed . One thing to note though I saw a lot of comments for text like this, just wondering is it necessary?
Right, but the use case that mentioned clearly demonstrates the bug. It's necessary for tracking separating the text elements in order to apply updates/diffs.
Understood, thanks for the explanation.


Question: expect(stubStyle.fontFamily).toEqual(''); }); <ins> // TODO: (poshannessy) deprecate this pattern. </ins> it("should update styles when mutating style object", function() { <ins> // not actually used. Just to suppress the style mutation warning spyOn(console, 'error'); </ins> var styles = {display: 'none', fontFamily: 'Arial', lineHeight: 1.2}; var container = document.createElement('div'); React.render(<div style={styles} />, container);

Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.


Question: outfile: './build/JSXTransformer.js', debug: false, standalone: 'JSXTransformer', <del> after: [es3ify.transform, simpleBannerify] </del> <ins> transforms: [], after: [es3ify.transform, derequire, simpleBannerify] </ins> }; var addons = {

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: ); } }); <ins> App = React.createFactory(App); </ins> /** jQuery Mobile button component. */ var JQueryMobileButton = 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: return undefined; } <del> // AsyncMode alias is deprecated along with isAsyncMode export const AsyncMode = REACT_CONCURRENT_MODE_TYPE; </del> <ins> // AsyncMode is deprecated along with isAsyncMode export const AsyncMode = REACT_ASYNC_MODE_TYPE; </ins> export const ConcurrentMode = REACT_CONCURRENT_MODE_TYPE; export const ContextConsumer = REACT_CONTEXT_TYPE; export const ContextProvider = REACT_PROVIDER_TYPE;

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: "local-storage-fallback": "^4.1.1", "lodash.throttle": "^4.1.1", "memoize-one": "^3.1.1", <del> "react-virtualized-auto-sizer": "^1.0.2", </del> <ins> "react-virtualized-auto-sizer": "^1.0.6", </ins> "semver": "^6.3.0" } }

devtools "Components" tab At first the component tree won't appear. Once I'm at the "Components" tab, I then have to also refresh the page to make the tree render. And when it does render, it still doesn't work properly. As a note, this issue started happening after I had to forcibly restart my computer. Since then I have tried reinstalling the extension, restarting Chrome, restarting my pc, all of which haven't worked. I'd like to avoid reinstalling Chrome completely but that's the only thing I haven't yet tried. Using Windows 10, btw. Here is what the broken component tree looks like. It's very narrow and the components cannot be selected: ! Every time No response No response No response No response No response No response
Same issue, Chrome v 92.0.4515.107
Same here: ! The Profiler tab seems unaffected Workarounds that don't help: Reloading the page Docking the devtools on the side/bottom Undocking the devtools (a.k.a. open in a window) Resizing the window Fiddling with the setting Resizing the right pane of the component tab
Looks like a CSS issue. I managed to work around it by fiddling with the styles as shown in this video: https://user- Besides the css tweaks to make the tree not so squished, the mouse selection issue has to be worked around separately The nodes are initially selectable with the mouse, but mouse selection breaks permanently if you attempt to use the element picker (I'm guessing it adds and doesn't remove it?) Using other methods of selecting nodes (i.e. searching, keyboard, using the / buttons, etc) still work For anyone curious on how to do what I did in the video: the devtools in undocked mode this will open an "inspector inspector" the properties as shown in the video
Doesn't seem to occur on mac os for me on extension (both from chrome extension store and running from main branch). Could this be os specific?

Version 14.0 (7/16/2021) <img width="1674" alt="Screenshot 2021-07-30 at 00 05 56" src="https://user-"
reproduces for me on: MacOS X 10.14 Chrome Version 92.0.4515.107 (Official Build) (x86_64) (latest) DevTools 4.14.0 (7/16/2021)
Mine is: Windows 10 21H1 (OS Build .1110) Chrome Version 92.0.4515.107 (Official Build) (64-bit) DevTools version 4.14.0- If any developer is unable to reproduce, let me know and I can get you whatever you need (a snapshot of the dom, the css ruleset, a memory dump, of specific nodes, heck even a css fiddle if that's what you need, anything that might help you) Also I know you guys know this but just in case: what I did in the video is by no means a suggestion of what should be done in order to fix the problem. Randomly changing CSS around without understanding what it does is a good way to introduce more bugs
reproduces for me on: Windows 10 Pro (10.0. Build ) Edge Version 92.0.902.62 (Official Build) (64-bit) (latest) DevTools 4.14.0 (7/16/2021)
I also have this problem: MacOS 11.4 Chrome version: Version 92.0.4515.131 (Official Build) (x86_64) DevTools version: 4.14.0 (7/16/2021) Sometimes component tree doesn't show at all, have to reload a page. Even after reloading tree is too narrow and clicks are not coming through. Tried every sane approach to fix (reinstall, reload etc) — nothing helps.
Occurs for me as well: Ubuntu 20.04.2 LTS Chrome: 92.0.4515.107 - also occurs on: 92.0.4515.131 DevTools: 4.14.0 While Chrome is affected for me - FireFox continues to work.

Another report in
I suspect the bug may be caused by this component (which we use in DevTools to auto-expand the Components tree to fill the width and height of the viewport):
Me too. OSX Chrome (the latest) ReactDevTools: Interestingly, the issue is not present in (Brave ).
Tanks As another data point: OS X 11.4 (20F71) Chrome 92.0.4515.131 DevTools (built from HEAD of ) FWIW I've never seen or been able to reproduce this bug myself (and I use DevTools daily). Maybe others can share their configurations and we can spot a pattern.
@ bvaughn So you can't reproduce? What would be helpful for you to track this down?
I have the same issues and also using chrome with latest version and dev tools version on windows 10. Weird thing, is my co-worker with the same versions, it works fine on his end on the same app/site. So no idea what is causing it to not work on my computer.
Could be helpful if you and your coworker could try to further narrow down what the difference is between the two of your setups.
I checked with him quickly and we have pretty much the same extensions. I also did a test in Edge and in Edge it works fine, it only seems to affect my chrome. I also tried to disable all extensions and even did a complete reset of the chrome settings to default values and cleared all cache. The problem still persists. I even thought of disabling hardware acceleration and checked if my settings differed from edge, but no go.
I have a suspicion at whats going on here. I know react-virtualized ~shims ~ has resize detection using scroll event handlers, when it does this, it schedules a to be notified after the layout updates. In this case, if I debug this script, I can see that scheduling any raf in of the devtool will never fire. I suspect a finch trial is being used by the Chromium team to attempt to throttle rAFs in hidden s. This experiment looks the most suspicious, these will show as "Default" for everyone unfortunately. !
Awesome work, this pretty much confirms it. Changing that flag from to solves the issue on my end. Changing it to makes it happen again
Couldn't find the throttle setting mentioned by and where to change it.

But I uninstalled chrome completely and reinstalled it (fresh copy, wiping out all settings) and it fixed it for me.
Could be worth opening a Chromium ticket, but from similar experience this is likely by design. Maybe they could exclude devtools extensions here? I think the fact that this is deep in the ~ polyfill~ resize detection might make it painful to fix in the short term. Maybe it's best to create a branch off of thats used for the plugin that from the scheduler array Alternatively it feels like that ~polyfill~ detection deserves a naive check around and preferring over when hidden.
Fantastic find, Seems like could detect this case (no rAF firing by a certain time) and maybe fallback to using a timer or other debounce technique.
I saw you just picked this up if you have issues in development I have seen Chromium make timers minute aligned when doing background throttling. It's possible it may do the same in this case. If that's the case I know setImmediate polyfills have a trick with a self that could be used.
Thanks for the pointer, Happen to have a code pointer?
Sure! Here's the strategy I was thinking of and here is a reference to the timer alignment I've seen mentioned (not 100% sure it will apply here)
Super helpful. Thanks!
I'm overlooking some important detail here. Enabling/disabling the "Throttle non-visible cross-origin iframes" flag does indeed trigger/fix the bug, but even when this is disabled– animation frames still get called based on my testing, unlike what reported above: (So my idea to detect this case and fallback to a timeout doesn't work.) That being said, just replacing with (and not trying to detect support) fixes the broken behavior.
ah interesting. Just to validate are you registering those callbacks from the context of or . I believe they will only fail to fire from (which is the hidden iframe)
I logging to the feature detection code I wrote (which runs in the same context as the script).
Fixed it by adding a fallback timeout when rAF is used Doesn't feel great but...
Thanks a ton for the info and
This fix has landed. We'll probably release it next week because we're also waiting on another bugfix to unblock the Firefox release.
Related CR bug: