Question:
expect(console.error.argsForCall.length).toBe(2); });  it('should warn about styles with numeric string values for non-unitless properties', function() { spyOn(console, 'error'); var div = document.createElement('div'); var One = React.createClass({ render: function() { return this.props.inline ?  :
; }, }); var Two = React.createClass({ render: function() { return
; }, }); ReactDOM.render(<One inline={false} />, div); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toBe( 'Warning: a `div` tag (owner: `One`) was passed a numeric string value ' + 'for CSS property `fontSize` (value: `1`) which will be treated ' + 'as a unitless number in a future version of React.' ); // Don't warn again for the same component ReactDOM.render(<One inline={true} />, div); expect(console.error.calls.length).toBe(1); // Do warn for different components ReactDOM.render(<Two />, div); expect(console.error.calls.length).toBe(2); expect(console.error.argsForCall[1][0]).toBe( 'Warning: a `div` tag (owner: `Two`) was passed a numeric string value ' + 'for CSS property `fontSize` (value: `1`) which will be treated ' + 'as a unitless number in a future version of React.' ); // Really don't warn again for the same component ReactDOM.render(<One inline={true} />, div); expect(console.error.calls.length).toBe(2); });  it('should warn semi-nicely about NaN in style', function() { spyOn(console, 'error');

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: "manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Microsoft Edge Developer Tools.", <del> "version": "5.3.1", "version_name": "5.3.1", </del> <ins> "version": "6.0.0", "version_name": "6.0.0", </ins> "minimum_chrome_version": "102", "icons": { "16": "icons/16-production.png",

development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0


Question: ); } else { warningWithoutStack( <del> render.length === 2, 'forwardRef render functions accept two parameters: props and ref. ' + 'Did you forget to use the ref parameter?', </del> <ins> // Do not warn for 0 arguments because it could be due to usage of the 'arguments' object render.length === 0 || render.length === 2, 'forwardRef render functions accept exactly two parameters: props and ref. %s', render.length === 1 ? 'Did you forget to use the ref parameter?' : 'Any additional parameter will be undefined.', </ins> ); }

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? A feature (an improvement) What is the current behavior? When defining more than two parameters for a React.forwardRef render function a warning message stating "forwardRef render functions accept two parameters: props and ref. Did you forget to use the ref parameter?" gets logged. 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? Option 1 Overall the message could be more explicit on accepting exactly two parameters. Also, when the arity is greater than 2 the second part of the message may be omitted. For instance: ""forwardRef render functions accept exactly two parameters: props and ref" Option 2 If defining more than 2 arguments to the function is ok, which may be the case since the real goal for this warning is just to make sure people use the ref parameter, I think the message could not be shown for arity 2, therefore chaging the condition of to . Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0 which is the one that includes this new warning
Happy to take a PR for “option 1”. The purpose of accepting more arguments is not clear to me because they’d never get filled in.
Cool. I will make a PR tonight
We might want to add a note about an argument rest as well? also warning in a confusing manor since it's transpiled to use directly
I think it shouldn't warn about 0 arguments.
Should be fixed in 16.5.1
This warning is still visible in react 17.0.1
I've just got this error after running npm update. (React v17)
Just put a debugger and saw that these errors ar comming from MUI
Me too
Yes, I am reporting this issue as well. Will create a ticket for MUI if there isn't one already.

Hey all, if you're receiving this from MUI, do you happen to be using the x-date-picker imported from mui/lab? If so, switch to the separated mui/x-date-picker npm package. The date picker from mui/lab has been deprecated and it's improperly using forwardRef: <img width="1326" alt="Screen Shot 2022-06-15 at 10 04 42 AM" src="https://user-"
yes, that was the reason, already switched. Thanks for letting others know
Hello all, in my own component (Reactjs+TypeScript) I want to use forwarded ref optionally. I have achieved this with a default value - it works fine. The second param looks like this: Unfortunatelly in browser Im getting this irritating warning, even if I pass the ref from the top component. Can I suppress the warning or is there another solution with TypeScript in such cases? Especially the warning is very annoying in jest logs.


Question:
author: vjeux ---  [JSFiddle](https://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](https://jsfiddle.net/vjeux/kb3gN/)**, fork it and share it! A [fiddle without JSX](https://jsfiddle.net/vjeux/VkebS/) is also available.   [JSFiddle](https://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

The Post gave an example of reconciliation by this . but It's not working, If I understand correctly, it should be something like . Should I create a PR by change the url to fix it?
The problem is that it is a https link for a fiddle that only supports http. There are actually more links with the same bug. Updating the fiddles would be one way to fix it, but that is a lot of work. And since the fiddles are part of old blog posts, it would be kind of like rewriting history. In my opinion the best way to fix it is reverting the links back to http. See for my proposed solution.
I see, thank u
I feel like the more 'correct'/'ideal' solution is to have the fiddle authors update their fiddles. That said, I don't feel too strongly, and will let make the decision on this.


Question: }, "engines": { "node": ">=0.10.0" <ins> }, "devDependencies": { "react-16-8": "npm:react@16.8.0", "react-dom-16-8": "npm:react-dom@16.8.0" </ins> } <del> } </del> <ins> } </ins>  No newline at end of file

When I use DevTools to select an element on the page, it can't jump/find it. It also doesn't show it in the Components page. This was checked by finding its parent and checking the children, non of the newly generated ones are there. As a probably related bug Profiler doesn't show/record the changes. React version: 16.13.1 React-dom version: 16.13.1 Parcel: 2.0.0-beta.1 a parent element a child element (A) conditional rendering () "hide" A now shows and select B using Chrome Dev Tools's "Select an element in the page to inspect it" nowhere/Can't find it manually in the list. ! In this example, I demonstrate that it works on the Search Bar (light grey bar) which is the TextField=InputBase tree, and the Container that contains the search & images and how hovering over the image doesn't do anything. I then click on the image and nothing happens & the state panel on the right of Dev Tools empties itself. Can't find newly rendered components in React Dev Tools Components panel Being able to find the newly rendered components in React Dev Tools Components panel
It doesn't look like this bug report has enough info for one of us to reproduce it. Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. Screenshots or videos can also be helpful if they help provide context on how to repro the bug. Here are some tips for providing a minimal example:
how "complex"/big of a repo is allowed for me to link to? As so far I have had 0 luck replicating a basic example on codesandbox as it behaves as it should.
The smaller it is, the better chance someone will be able to look at it and find/fix the problem.
So it appears the issue is Google-Analytics. If I remove the code it is fine, add it, and it breaks. As such I have created a branch where I have removed basically all of the code except what is really needed to show this breaking.

In order to repo repo i start to HTTP://localhost:1234 into Chrome Dev Tools (Ctrl+Shift+i) to components (Figure 1) page that only App/Homepage/OfficialServers/Guilds show (Figure 1) to lines 10 to 23 aka the GA stuff will rebuild and reload page back to Chrome Dev Tools there is a lot more content (Figure 2) Figure 1 ! Figure 2 ! Hopefully, this is more helpful :)
Thanks for the info :) I'll tag this as "needs investigation" in case anyone has bandwidth to dig in.
Thanks man :)
I can't reproduce the broken behavior your screenshot shows using this repo. For me, the nested and components are visible with GA or without. Passing the issue back to you for more repro instructions. You might need to dig in and see if any errors are being thrown by DevTools. There might also be another web extension you have installed that is making this happen.
Interesting note, when I just swapped branch to it, it worked fine (aka didn't break), but after running a it broke again properly. I had a range of extensions (not mentioning as it currently doesn't seem needed), so I disabled them all except React Dev Tools to obviously show the results. But it still broke. I then swapped to checking the Console, below you can see the results of it. This was after clearing the console then F5. ! I am not going to link the files as they are massive, but they start with (top down) Hope this helps
I don't really see anything useful in that console. Am I suppose to? The source map warning is unrelated. Also not sure I understand how those JSON files are supposed to be related, sorry.
Honestly same, I was just praying that something in there made sense for what or why this is happening at the moment. I am currently unsure of what to test tbh. Could it be browser dependant? I am currently testing this all in Chrome: 86.0.4240.75 maybe it doesn't occur in other browsers?
Sorry, what I meant was that I don't really understand your latest comment. I don't think the JSON files are useful/usable by me in any way to reproduce this issue? And the console warnings are definitely not related to what you're reporting.

I am testing on OS X with Chrome 86.0.4240.111.
I was able to repro this with a fresh install of the linked repo. It seems that any script tag after the one that loads the react app module will cause this issue, in this case . I removed GA entirely and just a simple console log. Example here: And the issue still occurred. Moving the script above resolves it: I know that the React documentation recommends putting the , but I don't think this is expected behavior for the dev tools since the rest of the application works fine. But it's worth noting that putting or with the script tag will make browsers load that script last. I also removed the API call and had it load the data by default, and could see everything in the components tree. So this probably isn't an issue related conditional rendering, but rather it's ability to catch re-renders and updates when the react module isn't the last script the browser loads.
I'm confused by this statement. The docs section you linked to just shows loading React before loading your component code that uses React– and that's only applicable if you're using UMD builds (loading code into the global/window namespace). I am not aware of any reason why additional tags being present in the page should have any impact on React DevTools (and I don't see the behavior being described when running the repro app).
Update, I was using Firefox 81.0.2 and same issue. Also I am on Windows, but I doubt that is the issue. Doing a was able to trigger it. I was also able to mirror the fix that had, by moving the under the GA code.
You're right, my apologies! It really shouldn't, I was just reporting what I was experiencing when trying to reproduce the issue. It so far has consistently worked when no other script follows in execution order, but fails when one does. I am on macOS with Chrome 86.0.4240.111. Also tried it on Windows, experienced the same issue. I tried to recreate the issue on codesandbox, but was unable to. I did notice that the version of React DevTools available on codesandbox is , while I'm using , so that could be why it's difficult to get this behavior on there!
Just tried the steps again and I still can't repro the issue.

Might be worth pointing out that my app doesn't look anything like yours. Your screenshot shows: But when I run the repro app, I see: I assume this is expected because it's just a reduced repro case, but just wanted to clarify. I'm going to need one of you to dig into this and provide some more info. I can't trigger the problem, so there's not much I can do on this end to help. Does the console show any errors that might be related? (None of the ones in the screenshot above looked related but are there others?) If you detach the browser DevTools panel and open a second DevTools– does that DevTools have any errors (coming from one of your installed extensions) that might be related? !
I think the link they shared for the repo included a specific commit that they put the reduced code, instead of it being in master. Did you checkout the commit they shared @ ? Just wondering since your example looks different from what I got when trying to repro as well! For me, there were no related errors in the console or the devtools.
I followed the repro steps above, exactly: I assume that you did as well? If you have to do something else to repro this, that would be helpful to know.
They mentioned in their comment they created a new branch, so I guess I expanded step 1 from their steps into: - -
Thanks Let me try that.
Ah! That was the missing step. This is interesting. Checking out that branch: If I load the page, then open DevTools, it looks fine. If I open DevTools and then (re)load the page, some components are missing.
Interesting to note that I stepped all the way back to DevTools v4.0.0 and this bug still happens. This is definitely not a recent regression.
It's also interesting to note that I can't repro this with the DevTools extension detached (and logging debug info) only when it's docked to the bottom and I reload the page after it was already open. That's going to make it a little harder to track down.
I've been able to reduce the repro to the following: Unfortunately I have not been able to reproduce the failing behavior in one of our integration tests. Still, a small repro is very promising.

Going to dig into the actual code now and see what's breaking :smile:
Very nice work :D Glad I wasn't losing the plot, weird how picky it is in regards to the DevTools behaviour
I think this bug is actually being caused by Fast Refresh bailing out without calling the decorated DevTools hook: Although it seems sensitive to timing so I'm having trouble catching it in the debugger.
Conceptually, it's possible for Fast Refresh to intercept a renderer that it isn't compatible with: In which case, subsequent commits from react-dom will effectively block DevTools entirely: This looks wrong. FR should always pass through to DevTools.
Thanks for the fix :)


Question: // Mount const create = effect.create; <ins> if (__DEV__) { if ((flags & HookInsertion) !== NoHookEffect) { setIsRunningInsertionEffect(true); } } </ins> effect.destroy = create(); <ins> if (__DEV__) { if ((flags & HookInsertion) !== NoHookEffect) { setIsRunningInsertionEffect(false); } } </ins> if (enableSchedulingProfiler) { if ((flags & HookPassive) !== NoHookEffect) {

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: <ins> // Copyright 2009-2012 by contributors, MIT License // vim: ts=4 sts=4 sw=4 expandtab //Add semicolon to prevent IIFE from being passed as argument to concated code. ; // Module systems magic dance (function (definition) { // RequireJS if (typeof define == "function") { define(definition); // YUI3 } else if (typeof YUI == "function") { YUI.add("es5-sham", definition); // CommonJS and <script> } else { definition(); } })(function () { var call = Function.prototype.call; var prototypeOfObject = Object.prototype; var owns = call.bind(prototypeOfObject.hasOwnProperty); // If JS engine supports accessors creating shortcuts. var defineGetter; var defineSetter; var lookupGetter; var lookupSetter; var supportsAccessors; if ((supportsAccessors = owns(prototypeOfObject, "__defineGetter__"))) { defineGetter = call.bind(prototypeOfObject.__defineGetter__); defineSetter = call.bind(prototypeOfObject.__defineSetter__); lookupGetter = call.bind(prototypeOfObject.__lookupGetter__); lookupSetter = call.bind(prototypeOfObject.__lookupSetter__); } // ES5 15.2.3.2 // http://es5.github.com/#x15.2.3.2 if (!Object.getPrototypeOf) { // https://github.com/es-shims/es5-shim/issues#issue/2 // http://ejohn.org/blog/objectgetprototypeof/ // recommended by fschaefer on github Object.getPrototypeOf = function getPrototypeOf(object) { return object.__proto__ || ( object.constructor ? object.constructor.prototype : prototypeOfObject ); }; } //ES5 15.2.3.3 //http://es5.github.com/#x15.2.3.3 function doesGetOwnPropertyDescriptorWork(object) { try { object.sentinel = 0; return Object.getOwnPropertyDescriptor( object, "sentinel" ).value === 0; } catch (exception) { // returns falsy } } //check whether getOwnPropertyDescriptor works if it's given. Otherwise, //shim partially. if (Object.defineProperty) { var getOwnPropertyDescriptorWorksOnObject = doesGetOwnPropertyDescriptorWork({}); var getOwnPropertyDescriptorWorksOnDom = typeof document == "undefined" || doesGetOwnPropertyDescriptorWork(document.createElement("div")); if (!getOwnPropertyDescriptorWorksOnDom || !getOwnPropertyDescriptorWorksOnObject ) { var getOwnPropertyDescriptorFallback = Object.getOwnPropertyDescriptor; } } if (!Object.getOwnPropertyDescriptor || getOwnPropertyDescriptorFallback) { var ERR_NON_OBJECT = "Object.getOwnPropertyDescriptor called on a non-object: "; Object.getOwnPropertyDescriptor = function getOwnPropertyDescriptor(object, property) { if ((typeof object != "object" && typeof object != "function") || object === null) { throw new TypeError(ERR_NON_OBJECT + object); } // make a valiant attempt to use the real getOwnPropertyDescriptor // for I8's DOM elements. if (getOwnPropertyDescriptorFallback) { try { return getOwnPropertyDescriptorFallback.call(Object, object, property); } catch (exception) { // try the shim if the real one doesn't work } } // If object does not owns property return undefined immediately. if (!owns(object, property)) { return; } // If object has a property then it's for sure both `enumerable` and // `configurable`. var descriptor =  { enumerable: true, configurable: true }; // If JS engine supports accessor properties then property may be a // getter or setter. if (supportsAccessors) { // Unfortunately `__lookupGetter__` will return a getter even // if object has own non getter property along with a same named // inherited getter. To avoid misbehavior we temporary remove // `__proto__` so that `__lookupGetter__` will return getter only // if it's owned by an object. var prototype = object.__proto__; object.__proto__ = prototypeOfObject; var getter = lookupGetter(object, property); var setter = lookupSetter(object, property); // Once we have getter and setter we can put values back. object.__proto__ = prototype; if (getter || setter) { if (getter) { descriptor.get = getter; } if (setter) { descriptor.set = setter; } // If it was accessor property we're done and return here // in order to avoid adding `value` to the descriptor. return descriptor; } } // If we got this far we know that object has an own property that is // not an accessor so we set it as a value and return descriptor. descriptor.value = object[property]; descriptor.writable = true; return descriptor; }; } // ES5 15.2.3.4 // http://es5.github.com/#x15.2.3.4 if (!Object.getOwnPropertyNames) { Object.getOwnPropertyNames = function getOwnPropertyNames(object) { return Object.keys(object); }; } // ES5 15.2.3.5 // http://es5.github.com/#x15.2.3.5 if (!Object.create) { // Contributed by Brandon Benvie, October, 2012 var createEmpty; var supportsProto = Object.prototype.__proto__ === null; if (supportsProto || typeof document == 'undefined') { createEmpty = function () { return { "__proto__": null }; }; } else { // In old IE __proto__ can't be used to manually set `null`, nor does // any other method exist to make an object that inherits from nothing, // aside from Object.prototype itself. Instead, create a new global // object and *steal* its Object.prototype and strip it bare. This is // used as the prototype to create nullary objects. createEmpty = function () { var iframe = document.createElement('iframe'); var parent = document.body || document.documentElement; iframe.style.display = 'none'; parent.appendChild(iframe); iframe.src = 'javascript:'; var empty = iframe.contentWindow.Object.prototype; parent.removeChild(iframe); iframe = null; delete empty.constructor; delete empty.hasOwnProperty; delete empty.propertyIsEnumerable; delete empty.isPrototypeOf; delete empty.toLocaleString; delete empty.toString; delete empty.valueOf; empty.__proto__ = null; function Empty() {} Empty.prototype = empty; // short-circuit future calls createEmpty = function () { return new Empty(); }; return new Empty(); }; } Object.create = function create(prototype, properties) { var object; function Type() {}  // An empty constructor. if (prototype === null) { object = createEmpty(); } else { if (typeof prototype !== "object" && typeof prototype !== "function") { // In the native implementation `parent` can be `null` // OR *any* `instanceof Object`  (Object|Function|Array|RegExp|etc) // Use `typeof` tho, b/c in old IE, DOM elements are not `instanceof Object` // like they are in modern browsers. Using `Object.create` on DOM elements // is...err...probably inappropriate, but the native version allows for it. throw new TypeError("Object prototype may only be an Object or null"); // same msg as Chrome } Type.prototype = prototype; object = new Type(); // IE has no built-in implementation of `Object.getPrototypeOf` // neither `__proto__`, but this manually setting `__proto__` will // guarantee that `Object.getPrototypeOf` will work as expected with // objects created using `Object.create` object.__proto__ = prototype; } if (properties !== void 0) { Object.defineProperties(object, properties); } return object; }; } // ES5 15.2.3.6 // http://es5.github.com/#x15.2.3.6 // Patch for WebKit and IE8 standard mode // Designed by hax <hax.github.com> // related issue: https://github.com/es-shims/es5-shim/issues#issue/5 // IE8 Reference: //     http://msdn.microsoft.com/en-us/library/dd282900.aspx //     http://msdn.microsoft.com/en-us/library/dd229916.aspx // WebKit Bugs: //     https://bugs.webkit.org/show_bug.cgi?id=36423 function doesDefinePropertyWork(object) { try { Object.defineProperty(object, "sentinel", {}); return "sentinel" in object; } catch (exception) { // returns falsy } } // check whether defineProperty works if it's given. Otherwise, // shim partially. if (Object.defineProperty) { var definePropertyWorksOnObject = doesDefinePropertyWork({}); var definePropertyWorksOnDom = typeof document == "undefined" || doesDefinePropertyWork(document.createElement("div")); if (!definePropertyWorksOnObject || !definePropertyWorksOnDom) { var definePropertyFallback = Object.defineProperty, definePropertiesFallback = Object.defineProperties; } } if (!Object.defineProperty || definePropertyFallback) { var ERR_NON_OBJECT_DESCRIPTOR = "Property description must be an object: "; var ERR_NON_OBJECT_TARGET = "Object.defineProperty called on non-object: " var ERR_ACCESSORS_NOT_SUPPORTED = "getters & setters can not be defined " + "on this javascript engine"; Object.defineProperty = function defineProperty(object, property, descriptor) { if ((typeof object != "object" && typeof object != "function") || object === null) { throw new TypeError(ERR_NON_OBJECT_TARGET + object); } if ((typeof descriptor != "object" && typeof descriptor != "function") || descriptor === null) { throw new TypeError(ERR_NON_OBJECT_DESCRIPTOR + descriptor); } // make a valiant attempt to use the real defineProperty // for I8's DOM elements. if (definePropertyFallback) { try { return definePropertyFallback.call(Object, object, property, descriptor); } catch (exception) { // try the shim if the real one doesn't work } } // If it's a data property. if (owns(descriptor, "value")) { // fail silently if "writable", "enumerable", or "configurable" // are requested but not supported /* // alternate approach: if ( // can't implement these features; allow false but not true !(owns(descriptor, "writable") ? descriptor.writable : true) || !(owns(descriptor, "enumerable") ? descriptor.enumerable : true) || !(owns(descriptor, "configurable") ? descriptor.configurable : true) ) throw new RangeError( "This implementation of Object.defineProperty does not " + "support configurable, enumerable, or writable." ); */ if (supportsAccessors && (lookupGetter(object, property) || lookupSetter(object, property))) { // As accessors are supported only on engines implementing // `__proto__` we can safely override `__proto__` while defining // a property to make sure that we don't hit an inherited // accessor. var prototype = object.__proto__; object.__proto__ = prototypeOfObject; // Deleting a property anyway since getter / setter may be // defined on object itself. delete object[property]; object[property] = descriptor.value; // Setting original `__proto__` back now. object.__proto__ = prototype; } else { object[property] = descriptor.value; } } else { if (!supportsAccessors) { throw new TypeError(ERR_ACCESSORS_NOT_SUPPORTED); } // If we got that far then getters and setters can be defined !! if (owns(descriptor, "get")) { defineGetter(object, property, descriptor.get); } if (owns(descriptor, "set")) { defineSetter(object, property, descriptor.set); } } return object; }; } // ES5 15.2.3.7 // http://es5.github.com/#x15.2.3.7 if (!Object.defineProperties || definePropertiesFallback) { Object.defineProperties = function defineProperties(object, properties) { // make a valiant attempt to use the real defineProperties if (definePropertiesFallback) { try { return definePropertiesFallback.call(Object, object, properties); } catch (exception) { // try the shim if the real one doesn't work } } for (var property in properties) { if (owns(properties, property) && property != "__proto__") { Object.defineProperty(object, property, properties[property]); } } return object; }; } // ES5 15.2.3.8 // http://es5.github.com/#x15.2.3.8 if (!Object.seal) { Object.seal = function seal(object) { // this is misleading and breaks feature-detection, but // allows "securable" code to "gracefully" degrade to working // but insecure code. return object; }; } // ES5 15.2.3.9 // http://es5.github.com/#x15.2.3.9 if (!Object.freeze) { Object.freeze = function freeze(object) { // this is misleading and breaks feature-detection, but // allows "securable" code to "gracefully" degrade to working // but insecure code. return object; }; } // detect a Rhino bug and patch it try { Object.freeze(function () {}); } catch (exception) { Object.freeze = (function freeze(freezeObject) { return function freeze(object) { if (typeof object == "function") { return object; } else { return freezeObject(object); } }; })(Object.freeze); } // ES5 15.2.3.10 // http://es5.github.com/#x15.2.3.10 if (!Object.preventExtensions) { Object.preventExtensions = function preventExtensions(object) { // this is misleading and breaks feature-detection, but // allows "securable" code to "gracefully" degrade to working // but insecure code. return object; }; } // ES5 15.2.3.11 // http://es5.github.com/#x15.2.3.11 if (!Object.isSealed) { Object.isSealed = function isSealed(object) { return false; }; } // ES5 15.2.3.12 // http://es5.github.com/#x15.2.3.12 if (!Object.isFrozen) { Object.isFrozen = function isFrozen(object) { return false; }; } // ES5 15.2.3.13 // http://es5.github.com/#x15.2.3.13 if (!Object.isExtensible) { Object.isExtensible = function isExtensible(object) { // 1. If Type(O) is not Object throw a TypeError exception. if (Object(object) !== object) { throw new TypeError(); // TODO message } // 2. Return the Boolean value of the [[Extensible]] internal property of O. var name = ''; while (owns(object, name)) { name += '?'; } object[name] = true; var returnValue = owns(object, name); delete object[name]; return returnValue; }; } }); </ins>

Should be as simple as making sure we include the polyfills we document
Somehow I assumed it was intentional that the polyfills weren't included, now I feel silly.
Eh, not really intentional, just never bothered to do it. Looking back it's a bit silly for us to say that we work in IE8 but not prove it.
It's ok guys, don't blame yourself for that IE8 story :) (this post is related to : !topic/reactjs/Z2jNf7za7cM) Meanwhile, I've just replied to Paul. Maybe you can help there because I'm stuck :+1: Thanks for your support and the work you've accomplished.
Hmm, it would appear this won't be possible so long as we use JSXTransform on the site. We could fix the NodeList -array issue, but we won't (and shouldn't try to) make changes to esprima to make it work (I think it's mostly using "reserved" words as keys. I guess we can turn this bug into "include polyfills, make sure things works as well as possible, provide some warnings if using IE8 about the problem"
So basically (tell me if I'm wrong) JSXTransform is not compatible with IE8.0 ? But ReactJS should be compatible, right ?
Correct. I just tested this myself with the zip I emailed to you - it's online for now at
Thanks zpao (you can remove it from your server if you wish I downloaded the srcs). I would recommend to add the non JSXTransformed example to git or the tutorial maybe ? Again thanks Paul and Spicyj for you help.
This should be easy now that has landed.
8 is out with , so this should be even easier to jump into.


Question: PureRenderMixin: ReactComponentWithPureRenderMixin, TransitionGroup: ReactTransitionGroup, <del> batchedUpdates: ReactUpdates.batchedUpdates, </del> <ins> batchedUpdates: function() { if (__DEV__) { warning( warnedAboutBatchedUpdates, 'React.addons.batchedUpdates is deprecated. Use ' + 'ReactDOM.unstable_batchedUpdates instead.' ); warnedAboutBatchedUpdates = true; } return ReactUpdates.batchedUpdates.apply(this, arguments); }, </ins> cloneWithProps: cloneWithProps, createFragment: ReactFragment.create, shallowCompare: shallowCompare,

We shipped this in 0.13 but then exposed it as (or ) in master. We should deprecate the usage in (separately from other deprecation notices because we aren't shipping this as a standalone addon).
I can't find any information regarding this decision, if goes away, how are we supposed to batch setStates in non-dom event handlers?
. As of right now, the batching is a part of the reconciler which lives in , even if it's used by non-dom event handlers.


Question: } var callback = scheduledRAFCallback; scheduledRAFCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(rafTime); } }; <del> rAF = function(callback: (time: number) => void): number { // This assumes that we only schedule one callback at a time because that's // how Fiber uses it. scheduledRAFCallback = callback; if (!isAnimationFrameScheduled) { // If rIC didn't already schedule one, we need to schedule a frame. isAnimationFrameScheduled = true; requestAnimationFrame(animationTick); } return 0; }; </del> rIC = function(callback: (deadline: Deadline) => void): number { // This assumes that we only schedule one callback at a time because that's // how Fiber uses it.

We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.


Question: "files": [ "LICENSE", "README.md", <del> "build-info.json", </del> "index.js", "cjs/", "umd/",

This is not published to npm.
This is a left over artifact from the way our release script used to work. It shouldn't cause any problems, but if you'd like to submit a PR removing this entry that'd be okay too.


Question: renderCode={true} transformer={transformer.bind(null, this.state.harmony)} showCompiledJSTab={false} <ins> showLineNumbers={true} </ins> /> <label className="compiler-option"> <input

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: <del> /** * Copyright (c) 2015-present, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule ReactNativeGlobalInteractionHandler * @flow */ 'use strict'; var InteractionManager = require('InteractionManager'); // Interaction handle is created/cleared when responder is granted or // released/terminated. var interactionHandle = null; var ReactNativeGlobalInteractionHandler = { onChange: function(numberActiveTouches: number) { if (numberActiveTouches === 0) { if (interactionHandle) { InteractionManager.clearInteractionHandle(interactionHandle); interactionHandle = null; } } else if (!interactionHandle) { interactionHandle = InteractionManager.createInteractionHandle(); } }, }; module.exports = ReactNativeGlobalInteractionHandler; </del>

Can't send ArrayBuffer to Server Action despite saying that you can. I'm not sure if this is an error or my part or the documentation. I retrieved the arrayBuffer from file of formData, then pass it through the parameter of the Server Action. It seems like it doesn't get sent to the server because it can't be parsed due to ArrayBuffer being serializable but not iterable. However this is somewhat confusing because you can attach File in FormData in the form of Blob and send it to the Server Action. I understand that FormData is but I'm not sure I understand why it can't be done the same with ArrayBuffer. I understand that I can just pass the FormData to send files but In my case I needed to transform the Files first before uploading and it ends up with a Blob. <!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: form, input, submit button, and also onSubmit function using Client Action the arrayData from the formData then pass it to server action <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: -- Throws client-side error ArrayBuffer gets sent to the server The documentation: <img width="583" alt="image" src=""Please let me know if I fail to understand the documentation or if it's something wrong in the documentation
I'm having the same issue.
Wokraround: I've tested multiple react/nextjs version combinations and now found working one. For me it's nextjs 13.5.6 and react 18.2.0. Reply pls when you try it out)
I will test.

I'm using and
The workaround i have for now is to wrap the data with FormData first and append the file before sending it to the server action
It seems that shipping as parameters of the server action is enabled, but returning from the server action is still not enabled.
as per the documentation, that is the intended behavior
They're supported as return values in Server Actions in React's Experimental release channel. Sending to Server Actions is currently not supported but we want to achieve parity eventually. I'll file a PR updating the docs accordingly.
Will be supported by
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!


Question: "version": "0.15.0-alpha", "description": "React package for working with the DOM.", "main": "index.js", <del> "repository": { "type": "git", "url": "git+https://github.com/facebook/react.git" }, </del> <ins> "repository": "facebook/react", </ins> "keywords": [ "react" ],

Follow-up for : The react-addons-* packages should have a entry in their files.


Question: }); }).toThrow( 'Invariant Violation: ReactCompositeComponent: You are attempting to ' + <del> 'define `abc` on your component more than once, but that is only ' + 'supported for functions, which are chained together. This conflict ' + 'may be due to a mixin.' </del> <ins> 'define `abc` on your component more than once. This conflict may be ' + 'due to a mixin.' ); }); it("should throw if mixins override functions in statics", function() { expect(function() { var Mixin = { statics: { abc: function() { console.log('foo'); } } }; React.createClass({ mixins: [Mixin], statics: { abc: function() { console.log('bar'); } }, render: function() { return <span />; } }); }).toThrow( 'Invariant Violation: ReactCompositeComponent: You are attempting to ' + 'define `abc` on your component more than once. This conflict may be ' + 'due to a mixin.' </ins> ); });

This logs both and : This seems weird to me and inconsistent with the behavior for non-static functions. Can we change this to give an error too?


Question: function getCommandArgs() { // Add the correct Jest config. const args = ['./scripts/jest/jest.js', '--config']; <del> if (argv.build) { </del> <ins> if (argv.project === 'devtools') { args.push(devToolsConfig); } else if (argv.build) { </ins> args.push(buildConfig); } else if (argv.persistent) { args.push(persistentConfig); <del> } else if (argv.project === 'devtools') { args.push(devToolsConfig); </del> } else if (isWWWConfig()) { args.push(wwwConfig); } else if (isOSSConfig()) {

This doesn't actually run any DevTools tests. It runs the main React tests. Console output shows that it's choosing the wrong config: I wonder if this is also happening for other targets?
It's because of this: DevTools uses both and


Question: ); }); <ins> it('gives a helpful error when passing null or undefined', function() { spyOn(console, 'warn'); React.createElement(undefined); React.createElement(null); expect(console.warn.calls.length).toBe(2); expect(console.warn.calls[0].args[0]).toBe( 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' ); expect(console.warn.calls[1].args[0]).toBe( 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' ); React.createElement('div'); expect(console.warn.calls.length).toBe(2); expect(() => React.createElement(undefined)).not.toThrow() }); </ins> it('should check default prop values', function() { spyOn(console, 'warn');

I spent the last hour trying to fix an issue that was caused by me trying to render a when the actual variable was undefined. The root cause was me misinterpreting that would return the whole instead of just (which is my bad), but the error itself and the stack trace were extremely cryptic and it took me a while to even get a clue that the reason why it wasn't working was that I was just trying to render an undefined type. This is the actual exception: And here's the stack trace: ! You can see that, ultimately, execution comes crashing down when React tries to look at on my undefined type, which of course raises an exception. The reason why this was confusing to me is that the exception happened quite far away from the source cause and, as a secondary factor, this code worked completely fine before I started porting it to Browserify and made my mistake with . This lead me to a wild set of hypotheses as to why it wasn't working, such as assuming it might be due to a regression in React 0.12 (since it's been migrating from to and I thought might have been lagging behind), to thinking it could be a problem with itself. The reason why I raise this issue is that, since passing an type won't work anyway, it would make sense if React could check for and warn about it or maybe even raise an exception (since it would crash soon after anyway). My instance was a bit more extreme and if something like this happens to someone else they'll probably know where they screwed up in the first place, but some help from React would always be welcome!
Actually returns the whole react lib + the addons. The addons are just to the object you'd get if you did . I've been using browserify the whole time and this error just came up, after updating to 0.12.1. It was working fine before, so it seems kind of weird that it's throwing an error right now. If a dev could comment on this, that'd be great.
Yea, seems like it wouldn't be a bad idea to have a check in createElement. What was working fine before? createElement didn't really exist (it was in 0.11.x but would likely not have been used). And react/addons has always been the full React object with addons inserted.
Talked it through with on IRC, same cause just not via addons.

An undefined component was being used.
Yeah, I became aware of that when I figured out what the issue is, I was just thinking it would have been way more helpful if React had told me straight away that I was passing an undefined component to .
+1, I also had this issue (albeit for a different reason)
Thanks! :+1:
If you are giving the whole JSX code under the script tag of the HTML page, then the order of declaration of the components could cause this issue. When the inbuilt compiler sees a component which you've later declared in the code, it'll throw an error. However in plain terms, this just means that the component is missing.
Getting this Uncaught TypeError: Cannot read property 'createElement' of undefined Any solutions
Please ask on StackOverflow; this is hard to answer without seeing your complete code.
here is my code ...
is incorrect, should be There is no named export named . It is confusing because React is a CommonJS module, and since you’re using ES6 imports, Babel tries to map the semantics but they don’t match exactly. actually grabs from itself so you might just and use instead if it’s less confusing.
Woah, thank you for a nice clarification.


Question: "engines": { "node": ">=0.10.0" }, <del> "preferGlobal": true </del> <ins> "preferGlobal": true, "commonerConfig": { "version": 1 } </ins> }

I'd rather do it , if you don't mind.
I think we should do both. I think a forced clean should force clean all of the build artifacts (of which .module-cache is a part of).
can we distinguish between and ?
In what situation would you want to clean but not remove ?
I'm actually not aware of any other use cases for so maybe this is fine. But it still means we need to tell people to do if they encounter problems that might be fixed by doing so, whereas gives us a way to get the same effect with no verbal communication.
I'm going to do it. I think we should probably also do .
Closed by .


Question: const map: HookNames = new Map(); hooksList.map(hook => { <del> // TODO (named hooks) We should probably filter before this point, // otherwise we are loading and parsing source maps and ASTs for nothing. if (isNonDeclarativePrimitiveHook(hook)) { if (__DEBUG__) { console.log('findHookNames() Non declarative primitive hook'); } // Not all hooks have names (e.g. useEffect or useLayoutEffect) return null; } </del> // We already guard against a null HookSource in parseHookNames() const hookSource = ((hook.hookSource: any): HookSource); const fileName = hookSource.fileName;

Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.


Question: inspectElement, } from 'react-devtools-shared/src/inspectedElementCache'; import {loadHookNames} from 'react-devtools-shared/src/hookNamesCache'; <del> import {ElementTypeFunction} from 'react-devtools-shared/src/types'; </del> import LoadHookNamesFunctionContext from 'react-devtools-shared/src/devtools/views/Components/LoadHookNamesFunctionContext'; import {SettingsContext} from '../Settings/SettingsContext';

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: case ContextConsumer: case MemoComponent: case SimpleMemoComponent: <ins> case ForwardRef: </ins> // For types that execute user code, we check PerformedWork effect. // We don't reflect bailouts (either referential or sCU) in DevTools. // eslint-disable-next-line no-bitwise

profiling "a" into the input profiling ! Every time No response 24.3- No response No response No response No response
Hey, I tried the steps you mentioned with the same version of Dev Tools and it works for me (image attached) on Chrome (Version 100.0.4896.127 (Official Build) (64-bit)), could you also mention the browser and its version along with your operating system and version. !
I linked the wrong codesandbox. Let me update it. If you wrap ValueReader in forwardRef you should be able to reproduce
Updated codesandbox. should reproduce


Question: import {enableHookNameParsing} from 'react-devtools-feature-flags'; import LRU from 'lru-cache'; import {SourceMapConsumer} from 'source-map'; <del> import {getHookName, isNonDeclarativePrimitiveHook} from './astUtils'; </del> <ins> import {getHookName} from './astUtils'; </ins> import {areSourceMapsAppliedToErrors} from './ErrorTester'; import {__DEBUG__} from 'react-devtools-shared/src/constants'; import {getHookSourceLocationKey} from 'react-devtools-shared/src/hookNamesCache';

Hooks like or will never have names, so if a the only hooks for a given source file are these "unnamed" built-in hooks, we should skip loading the source code.


Question: > [Listening Scroll Event](https://groups.google.com/forum/#!topic/reactjs/l6PnP8qbofk) > <del> >  * [JSFiddle](https://jsfiddle.net/aabeL/1/): Basically I've given you two mixins. The first lets you react to global scroll events. The second is, IMO, much more useful: it gives you scroll start and scroll end events, which you can use with setState() to create components that react based on whether the user is scrolling or not. </del> <ins> >  * [JSFiddle](http://jsfiddle.net/aabeL/1/): Basically I've given you two mixins. The first lets you react to global scroll events. The second is, IMO, much more useful: it gives you scroll start and scroll end events, which you can use with setState() to create components that react based on whether the user is scrolling or not. </ins> > > [Fade-in Transition](https://groups.google.com/forum/#!topic/reactjs/RVAY_eQmdpo) > <del> >  * [JSFiddle](https://jsfiddle.net/ufe8k/1/): Creating a new `<FadeInWhenAdded>` component and using jQuery `.fadeIn()` function on the DOM node. >  * [JSFiddle](https://jsfiddle.net/R8f5L/5/): Using CSS transition instead. </del> <ins> >  * [JSFiddle](http://jsfiddle.net/ufe8k/1/): Creating a new `<FadeInWhenAdded>` component and using jQuery `.fadeIn()` function on the DOM node. >  * [JSFiddle](http://jsfiddle.net/R8f5L/5/): Using CSS transition instead. </ins> > > [Socket.IO Integration](https://groups.google.com/forum/#!topic/reactjs/pyUZBRWcHB4) >

The Post gave an example of reconciliation by this . but It's not working, If I understand correctly, it should be something like . Should I create a PR by change the url to fix it?
The problem is that it is a https link for a fiddle that only supports http. There are actually more links with the same bug. Updating the fiddles would be one way to fix it, but that is a lot of work. And since the fiddles are part of old blog posts, it would be kind of like rewriting history. In my opinion the best way to fix it is reverting the links back to http. See for my proposed solution.
I see, thank u
I feel like the more 'correct'/'ideal' solution is to have the fiddle authors update their fiddles. That said, I don't feel too strongly, and will let make the decision on this.


Question: } async function createBundle(bundle, bundleType) { <del> if (shouldSkipBundle(bundle, bundleType)) { return; } </del> const filename = getFilename(bundle, bundleType); const logKey = chalk.white.bold(filename) + chalk.dim(` (${bundleType.toLowerCase()})`);

Please make "requireable" npm release, already fixed and only new version on npm is needed. I've developed a source transform for JSX for browserify — which doesn't work properly because of
1 pushed to npm:


Question: inputArgs === undefined || inputArgs === null || inputArgs.length === 0 || <ins> typeof inputArgs[0] !== 'string' || </ins> // Matches any of %c but not %%c <del> (typeof inputArgs[0] === 'string' && inputArgs[0].match(/([^%]|^)(%c)/g)) || </del> <ins> inputArgs[0].match(/([^%]|^)(%c)/g) || </ins> style === undefined ) { return inputArgs;

For checking whenever my project will work correctly, when I run a command , errors which are shown below occurred. ! When I pass a first argument which is an object to , , , I can repro the errors. for example, Before a few days, the errors had never occured. When I disable DevTools, the errors calm down. I think, the errors may be caused by the codes which are shown below. Every time No response No response No response No response No response No response
The same error happens in my case. Basically I cant use becasue it shows the same error. I think it is a bug. Extension was updated just yesterday.
Experiencing the same issue while having the React Developer Tools extension enabled. Disabling the extension prevents the error from occurring.
Sounds like this is only on the latest extension release (4.24.5). What's your browser and its version? Edit: NVM I can reproduce now. Looking into this.
This is a bug. We’ll be releasing a fix asap.
Hey! I have a similar issue. I can use console log for printing string, but putting any functionality or variables causes the error
Hey! Thanks for reporting this bug and sorry for the inconvenience! If you are experiencing this issue, there are 3 temporary solutions: on "Hide logs during second render in Strict Mode" in the DevTools settings (click the gear button in the Components tab) <img width="439" alt="image" src="https://user-"for now a string argument to your For now, I've unpublished the extension on the Chrome Web Store to prevent people from installing the buggy version. We've submitted a new version with the bugfix to the Chrome Web Store, and the extension will come back online once the review process is done. Firefox and Microsoft Edge has not been affected, and an extension without this bug is still available for and .
Thank you so much!
updated my comment above with more and better workarounds!
A new version with the bug fix is on Chrome Web Store now:


Question: var childrenToRender = object.children.filter(function(child) { return !(child.type === Syntax.Literal && typeof child.value === 'string' <del> && child.value.match(/^[ t]*[rn][ trn]*$/)); </del> <ins> && child.value.match(/^[ t]*[rn][ trn]*$/) || child.type === Syntax.XJSExpressionContainer && child.expression.type === Syntax.XJSEmptyExpression); </ins> }); if (childrenToRender.length > 0) { utils.append(', ', state);

Is transformed to: Note the trailing - this results in a syntax error. The problem seems to be with comma insertion in and related functions (e.g, ). See IRC discussion below for my findings. Relevant parts of an IRC discussion:
The root of the issue is that is a special-case in JSX, but it apparently does not take into account . Should be an easy fix. We should also look into adding I feel, just to be able to easily comment out code. EDIT: I was wrong, the special-case is handled correctly, I'll have a PR up shortly.


Question: > lightweight description of what the DOM should look like. We call this process **reconciliation**. Check out <del> [this jsFiddle](https://jsfiddle.net/fv6RD/3/) to see an example of </del> <ins> [this jsFiddle](http://jsfiddle.net/fv6RD/3/) to see an example of </ins> reconciliation in action. Because this re-render is so fast (around 1ms for TodoMVC), the developer

The Post gave an example of reconciliation by this . but It's not working, If I understand correctly, it should be something like . Should I create a PR by change the url to fix it?
The problem is that it is a https link for a fiddle that only supports http. There are actually more links with the same bug. Updating the fiddles would be one way to fix it, but that is a lot of work. And since the fiddles are part of old blog posts, it would be kind of like rewriting history. In my opinion the best way to fix it is reverting the links back to http. See for my proposed solution.
I see, thank u
I feel like the more 'correct'/'ideal' solution is to have the fiddle authors update their fiddles. That said, I don't feel too strongly, and will let make the decision on this.


Question: }) .replace(/:/g, '-'); downloadFile( <ins> downloadRef.current, </ins> `profiling-data.${dateString}.${timeString}.json`, JSON.stringify(profilingDataExport, null, 2), );

Hi, long time user, first time issuer. I think I found a bug with the Profiler component. When I click on the button at the top nothing happens and there appears to be no new files in my Downloads folder. I think it might be silently failing and that's why I am not getting any response. Has anyone else ran into this issue? Another thing I would like to mention is that I haven't looked through all of the documentation material about the new Profiler. I only read , so if this issue is addressed elsewhere I apologize and also request the source to that solution. Thank you for your time! Versions: *
It seems that this is happening because of the call in the util function. I'll investigate this further.
I fixed the issue. I'll open a PR later today :)


Question: }, unmountComponent: function() { <del> // TODO: Is this necessary? </del> ReactComponentBrowserEnvironment.unmountIDFromEnvironment(this._rootNodeID); }

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: var selection = window.getSelection(); var length = node[getTextContentAccessor()].length; var start = Math.min(offsets.start, length); <del> var end = typeof offsets.end === 'undefined' ? </del> <ins> var end = offsets.end === undefined ? </ins> start : Math.min(offsets.end, length); // IE 11 uses modern selection, but doesn't support the extend method.

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> /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @providesModule Rectangle.art * @typechecks * * Example usage: * <Rectangle *   width={50} *   height={50} *   stroke="green" *   fill="blue" * /> * * Additional optional properties: *   (Number) radius *   (Number) radiusTopLeft *   (Number) radiusTopRight *   (Number) radiusBottomLeft *   (Number) radiusBottomRight * */ 'use strict'; var assign = require('object-assign'); var PropTypes = require('prop-types'); var React = require('react'); var ReactART = require('react-art'); var createReactClass = require('create-react-class'); var Shape = ReactART.Shape; var Path = ReactART.Path; /** * Rectangle is a React component for drawing rectangles. Like other ReactART * components, it must be used in a <Surface>. */ var Rectangle = createReactClass({ displayName: 'Rectangle', propTypes: { width: PropTypes.number.isRequired, height: PropTypes.number.isRequired, radius: PropTypes.number, radiusTopLeft: PropTypes.number, radiusTopRight: PropTypes.number, radiusBottomRight: PropTypes.number, radiusBottomLeft: PropTypes.number, }, render: function render() { var width = this.props.width; var height = this.props.height; var radius = this.props.radius ? this.props.radius : 0; // if unspecified, radius(Top|Bottom)(Left|Right) defaults to the radius // property var tl = this.props.radiusTopLeft ? this.props.radiusTopLeft : radius; var tr = this.props.radiusTopRight ? this.props.radiusTopRight : radius; var br = this.props.radiusBottomRight ? this.props.radiusBottomRight : radius; var bl = this.props.radiusBottomLeft ? this.props.radiusBottomLeft : radius; var path = Path(); // for negative width/height, offset the rectangle in the negative x/y // direction. for negative radius, just default to 0. if (width < 0) { path.move(width, 0); width = -width; } if (height < 0) { path.move(0, height); height = -height; } if (tl < 0) { tl = 0; } if (tr < 0) { tr = 0; } if (br < 0) { br = 0; } if (bl < 0) { bl = 0; } // disable border radius if it doesn't fit within the specified // width/height if (tl + tr > width) { tl = 0; tr = 0; } if (bl + br > width) { bl = 0; br = 0; } if (tl + bl > height) { tl = 0; bl = 0; } if (tr + br > height) { tr = 0; br = 0; } path.move(0, tl); if (tl > 0) { path.arc(tl, -tl); } path.line(width - (tr + tl), 0); if (tr > 0) { path.arc(tr, tr); } path.line(0, height - (tr + br)); if (br > 0) { path.arc(-br, br); } path.line(-width + (br + bl), 0); if (bl > 0) { path.arc(-bl, -bl); } path.line(0, -height + (bl + tl)); return React.createElement(Shape, assign({}, this.props, {d: path})); }, }); module.exports = Rectangle; </ins>

It seems like those were intended to be public APIs () but they’re not published on npm because folder is not in the whitelist.


Question: <ins> ## 4.5.0 * Fix false positive error with large number of branches. ([@scyron6](https://github.com/scyron6) in [#24287](https://github.com/facebook/react/pull/24287)) </ins> ## 4.4.0 * No changes, this was an automated release together with React 18.

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --This may be the same kind of , but I can't figure out the changes from CHANGELOG (I'm not sure if this is a bug). If there are no changes, it would be helpful to note that in the CHANGELOG. React version: N/A <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: N/A <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --Changes since v4.5.0 of eslint-plugin-react-hooks are not listed in CHANGELOG. Changes since v4.5.0 of eslint-plugin-react-hooks are listed in CHANGELOG.


Question: return ( <div> <button onClick={this.handleAdd}>Add Item</button> <del> <ReactCSSTransitionGroup transitionName="example"> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </ins> {items} </ReactCSSTransitionGroup> </div>

When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..


Question: /** <del> * Copyright (c) Facebook, Inc. and its affiliates. </del> <ins> * Copyright (c) Meta Platforms, Inc. and its affiliates. </ins> * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree.

react/packages/react says Copyright (c) Facebook Platforms, Inc. and affiliates, but should be Copyright (c) Meta Platforms, Inc. and affiliates as it is more consistent
Hello! This is my first time contributing to open source. Is anyone already working on this issue?
Hi, I would like to contribute in this. if anyone already working on this issues?
Hello, I would like to contribute to this assign it to me.
<bHi,</bI would like to contribute in this. if anyone already working on this issues?
This issue is already fixed. by


Question: opacity: true, order: true, orphans: true, <ins> tabSize: true, </ins> widows: true, zIndex: true, zoom: true,

The  CSS property should not be getting a suffix automatically because a unit-less value can represent the number of spaces that make up the width in a tab. The JS name for this property is . See in the React docs.
A solution for now is to use the which is pretty much equivalent.
Sounds like a good idea. Are you interested in creating a PR to add it?
Yes, the only thing I don't know is whether there needs to be anything special done to also include and handle object already in place
We autogenerate the vender-prefixed styles there (which you might have seen below where you changed code) so that's all you need to do! Thanks again.


Question: export const enableUseEffectEventHook = true; export const enableHostSingletons = true; export const enableClientRenderFallbackOnTextMismatch = false; <del> export const enableTrustedTypesIntegration = false; </del> // Logs additional User Timing API marks for use with an experimental profiling tool. export const enableSchedulingProfiler: boolean =

This is a weird one. Basically, if you add an event listener to the document in an effect that was triggered by an event. e.g. toggles some state, which triggers an effect, which adds a handler to the document. In the normal case the new event handler will "miss" the triggering event, e.g. the click handler won't respond to the click event that triggered it being (omg). HOWEVER, if you render a portal first, the timing changes slightly and the event handler will see the current event. React version: 17 the "show Message" button to see a message toggle in and out the "Render Portal" button (see a portal rendered into the body) the "show Message" button again and notice nothing happens The reason for the final behavior is the click event both opens and closes the message, (calls set state twice) <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: That they be consistent
17 only?
17 only! downstream issue
well tbh maybe this was present but not observable since before 17 you couldn't attach an event listener "higher up" so there wasn't any way to get in front of the current event
What sounds like a bug here is that is called synchronously at all. It should normally be deferred — which would avoid this issue. So it sounds like there's an unexpected effect flush. Would be nice to dig into why.
I'm sooo confused. I can't reproduce this anymore. The only thing I did was to update Chrome...
Can you still repro it?
bah sorry i was goofing around trying to find a workaround and didn't realize it was saving instead of forking. It should be back to being reproducible
Ok at least I can still sleep at night
What happens here is that the native event bubbles: On the root container On the body (portal target) This is why we get into dispatchEvent twice. Root container pass schedules an effect, and body pass flushes it. Seems like a bug that we flush the effect in this case.
To follow up on this — it does seem like a bug but we can't commit to prioritizing it at the moment.

There will be a bunch of work done to clean up and simplify related parts of the code in the coming months so we'll likely address it then. Have you found any userland workaround, or is this a hard blocker for you?
We've got a workaround that's simple and effective in theory . Need to let folks test it out a bit though. Alternatively I think adding listeners in a would work albeit pretty annoying to manage in an effect. For anyone looking, our current workaround is
What I noticed is that for an everything works fine but an actual user click causes the issue described: Edit: I think I'm try attaching a capture listener as well and then check in the bubble event listener if I also captured the event. That fixes the problem at least for mounts in the bubble phase. That looks promising so far: Edit2: Bisecting releases leads to good: 0.0.0-experimental- bad: 0.0.0-experimental- I used experimental releases since the release channel was released less often in that time. So the bug got introduced in Edit3: I don't think the timing of effects changed between 16 and 17. Looks like the timing of events changed due to the changes to the event delegation system. If you add the native listener to instead of , the code works fine. Edit4: ~When the portal is rendered into react attaches its event delegator onto the If I remove that event handler the message can be displayed again.~ See Edit5: Last bit: What makes this bug hard to track down with tests is that you naturally use but within React does not flush discrete updates. Though this is already documented in I'm generally suprised that passive effects are flushed synchronously at all but this does seem to be intended
It seems to me that the assertions in are not correct. The update that is scheduled in the passive effect is deferred as intended when flushing sync but the effect itself should not run when flushing synchronously. IMO would make more sense here. The test comment acknowledges that this is the opposite order and it seems to me that this issue is a good example why this order is problematic: Any side-effect that touches the DOM directly is out-of-order.

Not sure about the intended behaviour but it seems like having the following solve your issue (at least temporarely): On step 3, it displays the message correctly
You can also fix the issue by wrapping in a , like so:
Is there a fix in progress, for upcoming versions, for this bug? I am facing this issue , which cant be resolved because of this.
Could you explain in the Material-UI issue why this can't be resolved for you? We were under the impression that we worked around this bug for our specific usage. For updates on a fix, is the latest update. From what I gather the team is already experimenting with potential fixes. You can subscribe to this () github issue to get notified about updates. Asking for updates does not speed up delivery of said update.
The team has taken a closer look at this now that the related refactors are landing. We can't fix it in a general case without relying on some heuristic. Making all effects synchronous would be bad. Making all of them asynchronous also doesn't work because sometimes we need to flush earlier. The need to flush earlier relates to handling discrete events (like click) that need to be able to observe the already flushed state. A reasonable compromise is to make them synchronous at the end of discrete events (such as click), but asynchronous in other cases. This mirrors the recent changes we've made to state updates in Concurrent Mode to make it easier to adopt. So we this heuristic in Concurrent Mode: I checked that this issue in Concurrent Mode with the latest master commit and now consistently does not show the message (because clicks lead to synchronous effects). We've considered backporting this behavior to React 17. But at this point it's very risky because it's such a subtle change. It's also risky because it would be the first time that we rely on -based heuristics outside of Concurrent Mode. So it's kind of a new territory. Given that it's easy to work around, it doesn't seem like this risk is warranted in React 17. So we've concluded that, while unfortunate, it is safer to not try to fix it in React 17. But Concurrent Mode will have a more predictable behavior here. (Note that it's also quite likely that React 16 also had cases with over-flushing, but triggered under different conditions.)

I know this isn't the resolution that most people were hoping for.
Bug; Still clickAwayListener tests fails using React testing library. It seems because of react18.


Question: ReactDebugTool.onTestEvent(); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isProfiling state', () => { expect(ReactDebugTool.isProfiling()).toBe(false); ReactDebugTool.beginProfiling(); expect(ReactDebugTool.isProfiling()).toBe(true); ReactDebugTool.endProfiling(); expect(ReactDebugTool.isProfiling()).toBe(false); }); </ins> });

I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR


Question: if (options && options.sourceMap) { result.sourceMap = output.sourceMap.toJSON(); } <ins> if (options && options.sourceFilename) { result.sourceMap.sources = [options.sourceFilename]; } </ins> return result; } };

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: var newFn = function() { warning( warned, <del> `${namespace}.${oldName} will be deprecated in a future version. ` + `Use ${namespace}.${newName} instead.` </del> <ins> '%s.%s will be deprecated in a future version. ' + 'Use %s.%s instead.', namespace, oldName, namespace, newName </ins> ); warned = true; return fn.apply(ctx, arguments);

Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks


Question: } /** <del> * (For old IE.) Handles a propertychange event, sending a `change` event if </del> <ins> * (For IE <=11) Handles a propertychange event, sending a `change` event if </ins> * the value of the active element has changed. */ function handlePropertyChange(nativeEvent) {

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

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


Question: const config = { default: { patterns: ['src/**/*.js', 'www/**/*.js'], <del> ignore: ['**/third_party/**', '**/node_modules/**'], </del> <ins> ignore: [ '**/third_party/**', '**/node_modules/**', '**/jsfiddle-integration*.js', ], </ins> }, scripts: { patterns: ['scripts/**/*.js', 'fixtures/**/*.js'],

no longer works, and this causes all old fiddles like to break. We should fix it.
I've also noticed fiddles[1][2] linking to being broken. I assume they were/are linking to the same place, but it's something to keep in mind. [1] [2] (All the examples seem to be broken)
It will take a few minutes to deploy the site but hopefully this should be fixed now.
Unfortunately Recharts examples are broken because they don't specify the React version. So they accidentally "updated" to React 16 that has different file names. We could potentially fix this on our side by providing a fallback. But then, one of the most commonly used builds () doesn't even exist anymore. So this has to be fixed on their side anyway.


Question: ); }); <ins> it('should generate comment markup for component returns null', function() { var NullComponent = React.createClass({ render: function() { return null; }, }); var response = ReactServerRendering.renderToString(<NullComponent />); expect(response).toBe('<!-- react-empty: 1 -->'); }); </ins> it('should not register event listeners', function() { var EventPluginHub = require('EventPluginHub'); var cb = jest.genMockFn();

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: }); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> shallowRenderer.unmount(); expect(componentWillUnmount).toBeCalled();

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


Question: ); } <del> function batchedUpdates(callback, param) { </del> <ins> var NESTED_UPDATES = { initialize: function() { this.dirtyComponentsLength = dirtyComponents.length; }, close: function() { if (this.dirtyComponentsLength !== dirtyComponents.length) { // Additional updates were enqueued by componentDidUpdate handlers or // similar; before our own UPDATE_QUEUEING wrapper closes, we want to run // these new updates so that if A's componentDidUpdate calls setState on // B, B will update before the callback A's updater provided when calling // setState. dirtyComponents.splice(0, this.dirtyComponentsLength); flushBatchedUpdates(); } else { dirtyComponents.length = 0; } } }; var UPDATE_QUEUEING = { initialize: function() { this.callbackQueue.reset(); }, close: function() { this.callbackQueue.notifyAll(); } }; var TRANSACTION_WRAPPERS = [NESTED_UPDATES, UPDATE_QUEUEING]; function ReactUpdatesFlushTransaction() { this.reinitializeTransaction(); this.dirtyComponentsLength = null; this.callbackQueue = CallbackQueue.getPooled(null); this.reconcileTransaction = ReactUpdates.ReactReconcileTransaction.getPooled(); } mixInto(ReactUpdatesFlushTransaction, Transaction.Mixin); mixInto(ReactUpdatesFlushTransaction, { getTransactionWrappers: function() { return TRANSACTION_WRAPPERS; }, destructor: function() { this.dirtyComponentsLength = null; CallbackQueue.release(this.callbackQueue); this.callbackQueue = null; ReactUpdates.ReactReconcileTransaction.release(this.reconcileTransaction); this.reconcileTransaction = null; }, perform: function(method, scope, a) { // Essentially calls `this.reconcileTransaction.perform(method, scope, a)` // with this transaction's wrappers around it. return Transaction.Mixin.perform.call( this, this.reconcileTransaction.perform, this.reconcileTransaction, method, scope, a ); } }); PooledClass.addPoolingTo(ReactUpdatesFlushTransaction); function batchedUpdates(callback, a, b) { </ins> ensureInjected(); <del> batchingStrategy.batchedUpdates(callback, param); </del> <ins> batchingStrategy.batchedUpdates(callback, a, b); </ins> } /**

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

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

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


Question: The examples in the React repository are declared a bit differently than a third-party renderer would be. In particular, the `HostConfig` object mentioned above is never explicitly declared, and instead is a *module* in our code. However, its exports correspond directly to properties on a `HostConfig` object you'd need to declare in your code: * [React ART](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactART.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactARTHostConfig.js) <del> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOMHostConfig.js) </del> <ins> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom-bindings/src/client/ReactDOMHostConfig.js) </ins> * [React Native](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeRenderer.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeHostConfig.js) If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving. If you have more questions please file an issue and we’ll try to help!

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: main branch "" in " and its " <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --The page is 404. The page should exist.
Fixed by


Question: HostText, IncompleteClassComponent, IndeterminateComponent, <ins> LegacyHiddenComponent, </ins> MemoComponent, OffscreenComponent, SimpleMemoComponent,

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: } }); <ins> TestComponentWithReverseSpec = React.createClass({ render: function() { return <div />; }, componentDidMount: function() { this.props.listener('Component didMount'); }, mixins: [MixinBWithReverseSpec, MixinC, MixinD] }); </ins> TestComponentWithPropTypes = React.createClass({ mixins: [MixinD], propTypes: {

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: // For quickly matching children type, to test if can be treated as content. var CONTENT_TYPES = {'string': true, 'number': true}; <del> var CHILDREN = keyOf({children: null}); </del> var STYLE = keyOf({style: null}); var HTML = keyOf({__html: null}); <ins> var RESERVED_PROPS = { children: null, dangerouslySetInnerHTML: null, suppressContentEditableWarning: null, }; </ins> function getDeclarationErrorAddendum(internalInstance) { if (internalInstance) {

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