Question: .openProfiler(); } <del> const link = $('#rn-help-link'); link.addEventListener('click', event => { event.preventDefault(); require('electron').shell.openExternal(link.href); }); const $localhost = $("#localhost"); $localhost.innerText = `<script src="${server}"></` + 'script>'; $localhost.addEventListener('click', selectAllAndCopy); $localhost.addEventListener('focus', selectAllAndCopy); const $byIp = $("#byip"); $byIp.innerText = `<script src="${serverIp}"></` + 'script>'; $byIp.addEventListener('click', selectAllAndCopy); $byIp.addEventListener('focus', selectAllAndCopy); </del> <ins> function attachListeners() { const link = $('#rn-help-link'); link.addEventListener('click', event => { event.preventDefault(); require('electron').shell.openExternal(link.href); }); const $localhost = $("#localhost"); $localhost.innerText = `<script src="${server}"></` + 'script>'; $localhost.addEventListener('click', selectAllAndCopy); $localhost.addEventListener('focus', selectAllAndCopy); const $byIp = $("#byip"); $byIp.innerText = `<script src="${serverIp}"></` + 'script>'; $byIp.addEventListener('click', selectAllAndCopy); $byIp.addEventListener('focus', selectAllAndCopy); const $profiler = $("#profiler"); $profiler.addEventListener('click', openProfiler); }; </ins> <del> const $profiler = $("#profiler"); $profiler.addEventListener('click', openProfiler); </del> <ins> // Initially attach the listeners attachListeners(); </ins> let devtools; try {

Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!


Question: }); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> var result = shallowRenderer.getRenderOutput(); expect(result.type).toBe('div'); expect(result.props.children).toEqual([

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: } break; case 'SELECT_PREVIOUS_ELEMENT_WITH_ERROR_OR_WARNING_IN_TREE': { <del> if (store.errorCount === 0 && store.warningCount === 0) { </del> <ins> const elementIndicesWithErrorsOrWarnings = store.getElementsWithErrorsAndWarnings(); if (elementIndicesWithErrorsOrWarnings.length === 0) { </ins> return state; } <del> const elementIndicesWithErrorsOrWarnings = store.getElementsWithErrorsAndWarnings(); </del> let flatIndex = 0; if (selectedElementIndex !== null) { // Resume from the current position in the list.

Unfortunately I don't know how to reproduce this bug. It was just logged to Sentry. It seems like there's a logic bug here though: If is null or is empty, then would be 0 still– and this statement would result in an undefined entry: Only once react-devtools-inline 24.4 Error: can't access property "id", n is undefined No response No response
Not sure if will fix your issue. Let me know if you can get a repro!


Question: ### Polyfills Needed to Support Older Browsers <ins> These six functions can be polyfilled using `es5-shim.js` from [kriskowal's es5-shim](https://github.com/kriskowal/es5-shim): </ins> * `Array.isArray` * `Array.prototype.forEach` * `Array.prototype.indexOf` <del> * `Function.prototype.bind` </del> <ins> * `Array.prototype.some` </ins> * `Date.now` <del> * `Array.prototype.some` (also in `es5-shim.js`) </del> <ins> * `Function.prototype.bind` </ins> <del> All of these can be polyfilled using `es5-shim.js` from [https://github.com/kriskowal/es5-shim](https://github.com/kriskowal/es5-shim). </del> <ins> Other required polyfills: </ins> <del> * `console.*` - Only needed when not using the minified build. If you need to polyfill this, try [https://github.com/paulmillr/console-polyfill](https://github.com/paulmillr/console-polyfill). * `Object.create` - Provided in `es5-sham.js` @ [https://github.com/kriskowal/es5-shim](https://github.com/kriskowal/es5-shim). </del> <ins> * `Object.create` – Provided by `es5-sham.js` from [kriskowal's es5-shim](https://github.com/kriskowal/es5-shim). * `console.*` – Only needed when using the unminified build. If you need to polyfill this, try [paulmillr's console-polyfill](https://github.com/paulmillr/console-polyfill). </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? Reporting a Bug What is the current behavior? The main issue is an exception that get's thrown when I try to call ReactDOMServer.renderToStaticMarkup() when NODEENV is set to production as long as I change the NODEENV to anything other than production things work fine but in PROD this happens: You can use the repo provided to reproduce the error. The issue seems to stem from ReactDebugCurrentFrame is not defined in production and yet ReactDOMServer tries to access it when NODEENV is prod and the error happens right now I have to break my ReactDOMServer renders out into it's own script and run it when NODEENV is not prod The triggering lines from are here: You can see the same issue again here (in Chinese) this seems to be new in React 16 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? I would expect to be able to call ReactDOMServer.renderToStaticMarkup with NODE_ENV = production and have it work to turn react classes into a HTML string document. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I think this is new in React16.
This looks like you’re using production version of the package with a development version of the package. That’s not supported. I haven’t looked at your repo yet but I hope this helps!
Thank you. You were right. I compiled staticWriter with a dev version of and then called it with NODEENV=production. I've fixed it so that I now compile with the right NODEENV for each environment. You da' bes!


Question: ): FiberRoot | null { checkForNestedUpdates(); <ins> if (__DEV__) { if (isRunningInsertionEffect) { console.error('useInsertionEffect must not schedule updates.'); } } </ins> const root = markUpdateLaneFromFiberToRoot(fiber, lane); if (root === null) { return null;

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: * renders a div with a single child surrounded by whitespace with client render on top of bad server markup * renders >,<, and & as single child with client render on top of bad server markup * renders >,<, and & as multiple children with client render on top of bad server markup <del> * throws when rendering a string component with clean client render * throws when rendering a string component with client render on top of bad server markup * throws when rendering an undefined component with clean client render * throws when rendering an undefined component with client render on top of bad server markup * throws when rendering a number component with clean client render * throws when rendering a number component with client render on top of bad server markup </del> * renders an input with a value and an onChange with client render on top of bad server markup * renders an input with a value and readOnly with client render on top of bad server markup * renders an input with a value and no onChange/readOnly with client render on top of bad server markup

I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.


Question: expect(console.error.argsForCall.length).toBe(0); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('identifies valid elements', function() { var Component = React.createClass({ render: function() {

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


Question: ); } }); <ins> JQueryMobileFooter = React.createFactory(JQueryMobileFooter); </ins> /** jQuery Mobile header component. */ var JQueryMobileHeader = React.createClass({

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


Question: props = assign({}, props, {selected: this.state.selected}); } <del> return option(props, this.props.children); </del> <ins> var content = ''; // Flatten children and warn if they aren't strings or numbers; // invalid types are ignored. ReactChildren.forEach(this.props.children, function(child) { if (child == null) { return; } if (typeof child === 'string' || typeof child === 'number') { content += child; } else { warning( false, 'Only strings and numbers are supported as <option> children.' ); } }); return option(props, content); </ins> } });

If the contents of the element is constructed in special way, it breaks React on component update with "Unable to find element" error. Here's an example of method body: Here's working jsfiddle (with React 0.12.0): Adding to option props fixes the issue.
React separates the 's children with s. In HTML only text is allowed there and the browser handles it gracefully by removing the s. On the next render React tries to change those s, but can't find them. A workaround is to give a string to the :
Thanks for explaining this. In such case probably the best solution would be to extend error explanation with information about "option" elements (behind "table" etc).
Yea, we should probably do some checks in our ReactDOMOption wrapper and not allow anything but text as children.
Just hit this
This can be fixed by using ReactChildren.forEach in ReactDOMOption to flatten the children before passing it to the raw HTML component. Strings and numbers get concatted together; other elements should be skipped and log a warning for invalid children.


Question: case 'rt': return impliedEndTags.indexOf(parentTag) === -1; <ins> case 'body': </ins> case 'caption': case 'col': case 'colgroup':

(I am using 15rc2 because I need all the svg tags) I am rendering a foreignObject svg tag. According to I put body tag inside that tag and then whatever html I want in there. renderToString on the server leaves the body tag in place, and gives it a react-dataid. However when rendered on the client that body tag is removed. So when I look at the live elements, the body inside foreignObjects is gone, along with it's data-reactid. The server source ( ie view page source ) shows that the body tag was rendered with the missing react-dataid. The result is that you get a “Invariant Violation: Unable to find element with ID XX”, when the page updates, and somethings don't work. Removing the body from inside the foreignObject tag seems to solve the problem, but I don't know if that is an "OK" solution to this or if that body tag is necessary in some scenarios. But in either case this seems to be a scenario where server rendering results in different DOM/HTML then client rendering. Is this a problem, or is the body tag not supposed to there anyway? Todd
We never render the on the client side - only on the server side. Can you provide a jsfiddle that demonstrates the invariant violation?
Thanks for tracking down more specifically. Could be that browsers don't actually support that body usage? Or when actually parsed from markup, the body node doesn't exist (which seems likely and matches up with what we see in other situations where the browser changes markup). I won't have a chance to look into this more for a few days - it might be best to just use your alternate approach for now.
I can remove the body tag. It seems to work ok with out it. Whats clear at this point is that if the server sends the body tag, it is not parsed into a DOM node, at least on mac with Chrome and Safari. That results in the error, since the data-reactid for the body is missing. IE doesn't support foreignObject so its not relevant there. MS Edge does, but I haven't tested it.
It seems so.

Even without React, I can’t get Chrome (or Firefox for that matter) to make an actual node: <img width="261" alt="screen shot 2016-03-17 at 15 19 30" src=""
FWIW, does manage to put one in:
Sounds like we should add this to : we should warn and tell you you can't put a body tag inside foreignObject. We don't do anything much for SVG there right now; probably the ideal solution would be to pass the namespace info down too, then we can distinguish SVG and HTML tags with the same name (like title), then make sure the contents of a SVG tag are appropriate HTML tags. Not sure which HTML tags are and aren't allowed but it might be detailed in the HTML5 spec at
Can I take this one?
please do :-)


Question: } let url = sourceMappingURLs[i].split('=')[1]; <del> if (ABSOLUTE_URL_REGEX.test(url)) { const baseURL = url.slice(0, url.lastIndexOf('/')); url = `${baseURL}/${url}`; if (!isValidUrl(url)) { throw new Error(`Invalid source map URL "${url}"`); } } else if (!url.startsWith('/')) { </del> <ins> if (!url.startsWith('http') && !url.startsWith('/')) { </ins> // Resolve paths relative to the location of the file name const lastSlashIdx = runtimeSourceURL.lastIndexOf('/'); if (lastSlashIdx !== -1) {

This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).


Question: // TODO: These flags are hard-coded to the default values used in open source. // Update the tests so that they pass in either mode, then set these // to __VARIANT__. <ins> export const enableTrustedTypesIntegration = false; </ins> export const disableSchedulerTimeoutBasedOnReactExpirationTime = false; export const disableNativeComponentFrames = false; // You probably *don't* want to add more hardcoded ones.

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: isDOMComponent: function(inst) { // TODO: Fix this heuristic. It's just here because composites can currently // pretend to be DOM components. <del> return !!(inst && inst.getDOMNode && inst.tagName); </del> <ins> return !!(inst && inst.tagName && inst.getDOMNode); </ins> }, isDOMComponentElement: function(inst) {

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


Question: Component.displayName || Component.name || 'Component'; warning( <del> typeof inst.props === 'undefined' || !propsMutated, </del> <ins> inst.props === undefined || !propsMutated, </ins> '%s(...): When calling super() in `%s`, make sure to pass ' + 'up the same props that your component's constructor was passed.', componentName, componentName

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: 'radio': true }; <del> function _assertLink(input) { </del> <ins> function _assertSingleLink(input) { invariant( input.props.checkedLink == null || input.props.valueLink == null, 'Cannot provide a checkedLink and a valueLink. If you want to use ' + 'checkedLink, you probably don't want to use valueLink and vice versa.' ); } function _assertValueLink(input) { _assertSingleLink(input); </ins> invariant( input.props.value == null && input.props.onChange == null, 'Cannot provide a valueLink and a value or onChange event. If you want ' +

When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?


Question: 'use strict'; <ins> var DisabledInputUtils = require('DisabledInputUtils'); </ins> var DOMPropertyOperations = require('DOMPropertyOperations'); var LinkedValueUtils = require('LinkedValueUtils'); var ReactDOMComponentTree = require('ReactDOMComponentTree');

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


Question: hooks, owners, props, <ins> source, </ins> state, } = inspectedElement;

Do you want to request a feature or report a bug? Feature. What is the current behavior? The new DevTools doesn't show the component file path as did the v3 version. What is the expected behavior? It would be great to show the component file path, it's a really important feature when working in a large codebase. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React DevTools v4 is affected, v3 had it.
Please be more specific in your feedback. This is not helpful.
I agree with , in this new version (v4), we cannot get file locations which really slows development time, fix this asap.
You can get your component file path by clicking in the "Log this component data to the console", icon is like a bug, and then copy the path from the Console.
File info isn't shown in the top level UI anymore because there are a lot of important things fighting for space in that UI. You can still see it using the debug button though. ! Is this enough to satisfy your use case Seems like it should be?
I think doing 4 clicks for something so basic is way to much. Putting it at the bottom (or top) of the info panel doesn't seem like it would block anything, since it's quite empty and would be very helpful (at least a copy path button would be small) !
To counter this, I don't think people use this info / look for this info often- so I'm not sure it needs to be available at a glance. I think putting less accessed info behind a click or two isn't so unreasonable. I don't think 4 clicks is right. You have to click to select an element to begin with. Then it's: the bug console or type "Esc" to open the bottom console to expand the logged element (at which point the file info is already visible) Your screenshot looks like a pretty extreme edge case. Many people run this extension docked to the bottom 1/4th or so of their browser window, where there is much less height and adding it to the bottom would require scrolling.
Even 3 clicks is a lot. I know I used it multiple times a day, so does my co-workers.

Maybe adding an option to display it at the bottom would be a good compromise? Even off my default is fine, but the ones that use it would be able to turn it on. IMO, dev tools should help developers do their jobs better/faster, and an option would fulfill that purpose without impeeding others.
I agree with the old place that this piece of information where was way more accessible and easier to reach than now.
Please show the component file path by scrolling. It is very important for large projects. Doing it in 3 clicks is waste of time.
I agree with , in large projects this is such a waste of time, just put it in the old place as it was much much better.
I don't think further comments just saying "please add this" add much value. Copy-pasting Dan's response from another issue as I think it also applies here: We appreciate your feedback but s are enough to help prioritize tasks.
I had the chance to look into this a bit last night and this morning and here are my thoughts. I don't think this was intentional, but the screenshot in the comment above is pretty misleading: <img width="234" alt="Screen Shot 2019-12-10 at 8 20 04 AM" src="https://user-"Source paths are never this short. In practice, the string would always either need to be truncated- so it would not end up showing the file name or line number: <img width="337" alt="Screen Shot 2019-12-10 at 8 23 58 AM" src="https://user-"Or it would need to be the file name only, without the path: <img width="337" alt="Screen Shot 2019-12-10 at 8 22 19 AM" src="https://user-"Neither of which is actually that helpful if your goal is to copy a file path so that you can open it in an external editing tool. If we were to display the full string, and allow it to wrap, it would take up even more space.

<img width="337" alt="Screen Shot 2019-12-10 at 8 27 43 AM" src="https://user-"The only place I feel somewhat okay about putting the info is at the bottom, but I think this will often mean that in practice, it's not visible without scrolling (since most components have several props/state that would push it down): <img width="334" alt="Screen Shot 2019-12-10 at 8 33 32 AM" src="https://user-"I guess I could always make it a configurable option- but more options means more maintenance burden and I don't think this clears the bar for one. Maybe the best compromise would be to show the name only, at the bottom, and have a copy button for the full path with line number: <img width="335" alt="Screen Shot 2019-12-10 at 8 44 27 AM" src="https://user-"This would still require a bit of scrolling but... I don't think there's any way around that without harming the common case UX.
Thanks
This is already much better. Having a single option to make it copy the full path would be the best way though, since it's simple and all editors support opening by full path.
This is literally that. The partial path is shown but the copy button copies the full path. That's what I was trying to say with this:
Ah sorry I misunderstood! Thank you very much!
Still, we can get a file source by clicking the right-side source icon. <img width="1440" alt="Screenshot 2019-12-11 at 11 52 02 AM" src="https://user-"


Question: <title>Hello React</title> <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/JSXTransformer-{{site.react_version}}.js"></script> <del> <script src="https://code.jquery.com/jquery-1.10.0.min.js"></script> </del> <ins> <script src="https://code.jquery.com/jquery-2.1.3.min.js"></script> </ins> <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/0.3.2/marked.min.js"></script> </head> ```

"Getting started" defined to . "Adding Markdown" defined to . Should be unify to or ?
Nice find. We should use the same version. Are you interested in creating a PR to update it?
Yes I am. I looking at I think will attempt to unify the . I would like to create a PR so I'll do that soon.


Question: } return ReactTestUtils.findAllInRenderedTree(root, function(inst) { if (ReactTestUtils.isDOMComponent(inst)) { <del> var classList = ReactDOM.findDOMNode(inst).className.split(/s+/); return classNames.every(function(className) { return classList.indexOf(className) !== -1; </del> <ins> var className = inst.className; if (typeof className !== 'string') { // SVG, probably. className = inst.getAttribute('class') || ''; } var classList = className.split(/s+/); return classNames.every(function(name) { return classList.indexOf(name) !== -1; </ins> }); } return false;

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


Question: } } <del> // Map of one or more Fibers in a pair to their unique id number. // We track both Fibers to support Fast Refresh, // which may forcefully replace one of the pair as part of hot reloading. // In that case it's still important to be able to locate the previous ID during subsequent renders. const fiberToIDMap: Map<Fiber, number> = new Map(); // Map of id to one (arbitrary) Fiber in a pair. // This Map is used to e.g. get the display name for a Fiber or schedule an update, // operations that should be the same whether the current and work-in-progress Fiber is used. const idToArbitraryFiberMap: Map<number, Fiber> = new Map(); </del> // When profiling is supported, we store the latest tree base durations for each Fiber. // This is so that we can quickly capture a snapshot of those values if profiling starts. // If we didn't store these values, we'd have to crawl the tree when profiling started,

Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via


Question:
Component Lifecycle

Event Handling

Advanced Components

Mixins

API

There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with


Question: © 2013 Facebook Inc.

Replace with and no parse error happens. What’s going on?
I had the same issue with this: We actually have an internal task tracking this at Facebook but I don't think it's been looked in to yet. Here's a comment explaining why it happens:
Fixed in esprima-fb () when for esprima-fb, jstransform and react are sorted out.
I'm actually going to leave this open for now so we remember to do the version update.
Now fixed in


Question: this.props.onCommentSubmit({author: author, text: text}); this.refs.author.getDOMNode().value = ''; this.refs.text.getDOMNode().value = ''; <ins> return false; </ins> }), render: function() { return (

Do you want to request a feature or report a bug? bug What is the current behavior? When using the latest Dev tools (v4.0.5) on my project, when I inspect react-redux elements that use connect() devtools crashes. I can't map from my crash to the actual source but the code is react devtools: up one level of stack is react: and up one level is react-redux: () 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: I'll have to try and make a small repro, but I hope there's something obvious given the info above. It's not clear to me if react-redux is doing something or if its devtools. This behavior existed in v3 and i was hoping it'd get magically fixed with v4 but it remains. What is the expected behavior? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? This is in an electron app w/ react-redux v7.1.0 and react v16.8.3 (have to use this due to the version of react native i'm on)
Unfortunately this is a bug with React that was fixed via PR and released with v16.8.4. Thank you for the detailed bug report though! Originally reported here:


Question: function reevaluateErrorsAndWarnings() { fibersWithChangedErrorOrWarningCounts.clear(); <del> fiberToErrorsMap.forEach((countMap, fiberID) => { fibersWithChangedErrorOrWarningCounts.add(fiberID); </del> <ins> fiberIDToErrorsMap.forEach((countMap, fiberID) => { const fiber = idToArbitraryFiberMap.get(fiberID); if (fiber != null) { fibersWithChangedErrorOrWarningCounts.add(fiber); } </ins> }); <del> fiberToWarningsMap.forEach((countMap, fiberID) => { fibersWithChangedErrorOrWarningCounts.add(fiberID); </del> <ins> fiberIDToWarningsMap.forEach((countMap, fiberID) => { const fiber = idToArbitraryFiberMap.get(fiberID); if (fiber != null) { fibersWithChangedErrorOrWarningCounts.add(fiber); } </ins> }); recordPendingErrorsAndWarnings(); } <del> function recordPendingErrorsAndWarnings() { clearPendingErrorsAndWarningsAfterDelay(); </del> <ins> function mergeMapsAndGetCountHelper( fiber: Fiber, fiberID: number, pendingFiberToMessageCountMap: Map<Fiber, Map<string, number>>, fiberIDToMessageCountMap: Map<number, Map<string, number>>, ): number { let newCount = 0; </ins> <del> fibersWithChangedErrorOrWarningCounts.forEach(fiberID => { const fiber = idToArbitraryFiberMap.get(fiberID); if (fiber != null) { // Don't send updates for Fibers that didn't mount due to e.g. Suspense or an error boundary. // We may also need to clean up after ourselves to avoid leaks. // See inline comments in onErrorOrWarning() for more info. if (isFiberMountedImpl(fiber) !== MOUNTED) { untrackFiberID(fiber); return; } </del> <ins> let messageCountMap = fiberIDToMessageCountMap.get(fiberID); </ins> <del> let errorCount = 0; let warningCount = 0; </del> <ins> const pendingMessageCountMap = pendingFiberToMessageCountMap.get(fiber); if (pendingMessageCountMap != null) { if (messageCountMap == null) { messageCountMap = pendingMessageCountMap; </ins> <del> if (!shouldFilterFiber(fiber)) { const errorCountsMap = fiberToErrorsMap.get(fiberID); const warningCountsMap = fiberToWarningsMap.get(fiberID); </del> <ins> fiberIDToMessageCountMap.set(fiberID, pendingMessageCountMap); } else { // This Flow refinement should not be necessary and yet... const refinedMessageCountMap = ((messageCountMap: any): Map< string, number, >); pendingMessageCountMap.forEach((pendingCount, message) => { const previousCount = refinedMessageCountMap.get(message) || 0; refinedMessageCountMap.set(message, previousCount + pendingCount); }); } } </ins> <del> if (errorCountsMap != null) { errorCountsMap.forEach(count => { errorCount += count; }); } if (warningCountsMap != null) { warningCountsMap.forEach(count => { warningCount += count; }); } } </del> <ins> if (!shouldFilterFiber(fiber)) { if (messageCountMap != null) { messageCountMap.forEach(count => { newCount += count; }); } } pendingFiberToMessageCountMap.delete(fiber); return newCount; } function recordPendingErrorsAndWarnings() { clearPendingErrorsAndWarningsAfterDelay(); fibersWithChangedErrorOrWarningCounts.forEach(fiber => { const fiberID = getFiberIDUnsafe(fiber); if (fiberID === null) { // Don't send updates for Fibers that didn't mount due to e.g. Suspense or an error boundary. } else { const errorCount = mergeMapsAndGetCountHelper( fiber, fiberID, pendingFiberToErrorsMap, fiberIDToErrorsMap, ); const warningCount = mergeMapsAndGetCountHelper( fiber, fiberID, pendingFiberToWarningsMap, fiberIDToWarningsMap, ); </ins> pushOperation(TREE_OPERATION_UPDATE_ERRORS_OR_WARNINGS); pushOperation(fiberID); pushOperation(errorCount); pushOperation(warningCount); } <ins> // Always clean up so that we don't leak. pendingFiberToErrorsMap.delete(fiber); pendingFiberToWarningsMap.delete(fiber); </ins> }); fibersWithChangedErrorOrWarningCounts.clear(); }

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


Question:
## Khan Academy Question Editor  It looks like [Ben Alpert](http://benalpert.com/) is the first person outside of Facebook and Instagram to push React code to production. We are very grateful for his contributions in form of pull requests, bug reports and presence on IRC ([#reactjs on Freenode](irc://chat.freenode.net/reactjs)). Ben wrote about his experience using React on Quora:   It looks like [Ben Alpert](http://benalpert.com/) is the first person outside of Facebook and Instagram to push React code to production. We are very grateful for his contributions in form of pull requests, bug reports and presence on IRC ([#reactjs on Freenode](irc://chat.freenode.net/reactjs)). Ben wrote about his experience using React:  > I just rewrote a 2000-line project in React and have now made a handful of pull requests to React. Everything about React I've seen so far seems really well thought-out and I'm proud to be the first non-FB/IG production user of React. > > The project that I rewrote in React (and am continuing to improve) is the Khan Academy question editor which content creators can use to enter questions and hints that will be presented to students:  >
[![](/react/img/blog/khan-academy-editor.png)](http://www.quora.com/React-JS-Library/How-is-Facebooks-React-JavaScript-library/answer/Ben-Alpert)
   >
[![](/react/img/blog/khan-academy-editor.png)](http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-academy.html)
  >  > [Read the full post...](http://www.quora.com/React-JS-Library/How-is-Facebooks-React-JavaScript-library/answer/Ben-Alpert)   > [Read the full post...](http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-academy.html)  ## Pimp my Backbone.View (by replacing it with React)

does not currently support the latest version on , React version: 18.3.1 a new react application @ @ to install @ 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: --cannot install due to only having version 8 as a peer dependancy. npm i output: ES lint is upgraded successfully
Seems like the changes have been to but a new version is yet to be released on NPM
You can install the eslint-plugin-react-hooks RC to get around this for now.
That doesn't work for me unfortunately. Any idea?
your issue is with eslint-plugin-import. I don’t use it personally, but you could try see if they have an rc/beta/preview branch with eslint 9 support.
you can also use as it has a similar feature of import ordering to eslint-plugin-import, and supports eslint v9
thanks whilst using the release candidate as work around does indeed fix the issue (and may be useful for other projects), RCs seem to be updated daily. I'm mainly worried about platform stability and ideally require a stable release version for our application.
I believe this related to
Fixed in Will be released alongside React 19 as stable. You can use it today by install .


Question: } } <del> var IsMountedMixin = { </del> <ins> var IsMountedPreMixin = { </ins> componentDidMount: function () { this.__isMounted = true; <del> }, </del> <ins> } }; var IsMountedPostMixin = { </ins> componentWillUnmount: function () { this.__isMounted = false; }

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


Question: options.sourceType = 'nonStrict6Module'; } <ins> // Instead of doing any fancy validation, only look for 'es3'. If we have // that, then use it. Otherwise use 'es5'. options.es3 = opts.target === 'es3'; options.es5 = !options.es3; </ins> return options; }

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


Question: * Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ <del> batchedUpdates: function(callback, param) { callback(param); </del> <ins> batchedUpdates: function(callback, a, b) { 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: */ export const isUnitlessNumber = { animationIterationCount: true, <ins> aspectRatio: true, </ins> borderImageOutset: true, borderImageSlice: true, borderImageWidth: true,

React version: 16.14.0, 17.0.2 aspectRatio via - no aspectRatio applied via className - aspectRatio applied Needs Chrome 79 or above: Link to code example: No aspectRatio rule applied: aspectRatio applied, here I'm adding it via a :
Yes, I have the same issue with another style property Basically I want to add or and it gets removed.
Try passing a string instead of number. React special cases numbers (to add the "px" suffix) and only doesn't for certain known attributes. So new ones sometimes need to be to this list if they shouldn't get a px suffix (most should):
Your issue is unrelated. Would you mind opening a separate issue for that thread? Basically try instead. I.e. double strings. It's confusing but CSS expects a JS string of a CSS string. This is similar to how you have to do in React but it's a little clearer there because it's a wrapper around it.
Thanks
how soon do you need this? Are you blocked?
no, no rush at all! Just something I stumbled upon. Thanks for the lightning-quick response though!


Question: var ELEMENT_NODE_TYPE = 1; <ins> var styleMutationWarning = {}; function checkAndWarnForMutatedStyle(style1, style2, component) { if (style1 == null || style2 == null) { return; } if (shallowEqual(style1, style2)) { return; } var componentName = component._tag; var owner = component._currentElement._owner; var ownerName; if (owner) { ownerName = owner.getName(); } var hash = ownerName + '|' + componentName; if (styleMutationWarning.hasOwnProperty(hash)) { return; } styleMutationWarning[hash] = true; warning( false, '`%s` was passed a style object that has previously been mutated. ' + 'Mutating `style` will be deprecated. Consider cloning it beforehand. ' + 'Check the `render` %s. Previous style: %s. Mutated style: %s.', componentName, owner ? 'of `' + ownerName + '`' : 'using <' + componentName + '>', JSON.stringify(style1), JSON.stringify(style2) ); } </ins> /** * Optionally injectable operations for mutating the DOM */

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


Question: var children = {}; var childMapping = ReactTransitionKeySet.getChildMapping(sourceChildren); var transitionConfig = this.getTransitionConfig(); var currentKeys = ReactTransitionKeySet.mergeKeySets( this._transitionGroupCurrentKeys,

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


Question: invariant( typeof callback === 'function', 'enqueueCallback(...): You called `setProps`, `replaceProps`, ' + <del> '`setState`, `replaceState`, or `forceUpdate` with a callback that ' + 'isn't callable.' </del> <ins> '`setState`, `replaceState`, or `forceUpdate` with a callback of type ' + '%s. A function is expected', typeof callback === 'object' && Object.keys(callback).length && Object.keys(callback).length < 20 ? typeof callback + ' (keys: ' + Object.keys(callback) + ')' : typeof callback </ins> ); if (internalInstance._pendingCallbacks) { internalInstance._pendingCallbacks.push(callback);

Oddly enough, the two examples below are not equal as I thought they would be. The error is as follows: I'm assuming that is because the function as assuming an optional callback. But I would expect your code to do a typeof check, and not just a defined check. Can we change it to do a check? I can submit a PR.
Well, the typecheck happens with that exact typecheck, just not directly in forceupdate. Here's forceUpdate: and where the invariant happens: FWIW, is not the same as due to an important distinction. The former makes a new function that is bound but it will pass along any arguments. The latter also is a new function but it explicitly doesn't pass any arguments. So the former gets the event passed along while the latter just drops it. The event isn't callable, thus the invariant. We need to do the typecheck so I guess we could discuss whether we keep it as an invariant or a warning. But it is a misuse of the API.
To follow up on that, the more "equal" thing would be: Which should throw the same error that you see with your first bind example.
Correct. Yes, I understand all of that. It wasn't toooo hard for me to understand what is happening. And it is a misuse of the API. So I guess, I would consider adding the argument type to the invariant to help make it clearer? Something more like: It's kind of moot. But It confused me for a second. Might confuse others also.


Question: const [prevValue, setValue] = mountState(value); mountEffect( () => { <del> Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); </del> <ins> const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } </ins> }, [value, config], );

Do you want to request a feature or report a bug? Bug What is the current behavior? is never set to true when calling within , but it does work properly when within a . Here's the correct behavior (accomplished via ): ! Here's the incorrect behavior (via ): ! Note the difference is that the opacity never changes to 0.4 (which is determined based on the state). What is the expected behavior? I expect them to both behave the same (at least as far as the user can observe). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? react react-dom
I guess startTransition is never intended to be used in effects. I didn't expect it even works. Looking at the doc again, Hmm, it doesn't clearly say so.
Ok but the use cases is interesting.
Do you think this is the same as
Yes, I believe that's the same issue.
Hello, I think I have a similar issue when using with . When returns a new value I would like to create a new resource. I tried to use for this, but I don't even have an idea where to put ...
you can see the isPending is if the is bigger than 5100 when calling in .
I'm seeing the same behavior as - setting to a value of 5200 or higher causes to fire reliably in the original CodeSandbox:
That is a bug we need to fix regardless.
Fixed by . Updated Sandbox:


Question: const {profilerStore} = store; const inputRef = useRef<HTMLInputElement | null>(null); <ins> const downloadRef = useRef<HTMLAnchorElement | null>(null); </ins> const {dispatch: modalDialogDispatch} = useContext(ModalDialogContext);

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: if (mutationMethod) { mutationMethod(node, value); } else if (shouldIgnoreValue(propertyInfo, value)) { <del> this.deleteValueForProperty(node, name); </del> <ins> DOMPropertyOperations.deleteValueForProperty(node, name); </ins> return; } else if (propertyInfo.mustUseProperty) { // Contrary to `setAttribute`, object properties are properly

Do you want to request a feature or report a bug? Report a bug What is the current behavior? Referring to object's method from a another method within same object, , , breaks React build in Closure Compiler under advanced optimizations. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Build a React app using Closure Compiler in advanced mode. (Unfortunately I can not provide a source of the app where I got this bug.) What is the expected behavior? An app built with Closure Compiler in advanced mode should not throw exception Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React v15.4.2 Changing to solves this issue. There are other methods of object which are using properly via call. If this makes sense, I'll prepare a PR.
Seems reasonable. A PR would be great :)


Question: "electron": "^23.1.2", "internal-ip": "^6.2.0", "minimist": "^1.2.3", <del> "react-devtools-core": "5.3.1", </del> <ins> "react-devtools-core": "6.0.0", </ins> "update-notifier": "^2.1.0" } }

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: }, /** <del> * Stores `listener` at `listenerBank[registrationName][id]`. Is idempotent. </del> <ins> * Stores `listener` at `listenerBank[registrationName][key]`. Is idempotent. </ins> * * @param {object} inst The instance, which is the source of events. * @param {string} registrationName Name of listener (e.g. `onClick`).

In my javascript frameworks benchmark I ran into a performance regression for react. To reproduce open and open the console. Repeat three times the following: Click "Create 10,000" then click "Clear" You'll get a result like that: runLots took 1905. clear took 1997. runLots took 1813. clear took 4208.895 runLots took 1806. clear took 401. Now repeat the same for and you'll get something like that: unLots took 2938. clear took 399. runLots took 2726.365 clear took 383. runLots took 2872.625 clear took 381. (Measurement on Chrome 51 on MacOS 10.11.5 on a MBP 15) Notice that clear is a lot slower for the first two runs for React v 15, but the third clear run performs about the same for both react versions. The source code can be found in the of my benchmark.
In general we don’t advise you to render 10K items. Use something like instead. However, this indeed seems like a perf regression. <sIt appears that we’re spending a little time in per each item, and it adds up with 10K items.</s(Scratch that, doesn’t appear to be the cause.)
This is a very simple scenario: we are unmounting 10,000 components. The bottleneck is somewhere in reconciliation. React 0.14 is reconciling fast right away: <img width="762" alt="screen shot 2016-07-08 at 22 06 01" src=""React 15 is reconciling slow at first (notice how long is compared to applying DOM updates): <img width="1097" alt="screen shot 2016-07-08 at 22 03 56" src=""But it warms up exactly after two mount-unmount cycles (notice how its size is less relative to DOM updates): <img width="928" alt="screen shot 2016-07-08 at 22 04 07" src=""
It looks like there is some sort of V8 optimization that doesn’t kick in until you unmount a lot of components.

I was able to drastically reduce time (from 2 seconds to 300 milliseconds) on React 15 by replacing statements with assignment in these two places:   This is probably not a real solution (I think just leaving them as means memory keeps growing, even if just for property keys). Still, I wonder why 0.14.x is not similarly penalized.
Replacing objects with ES6 Maps gives similar performance improvements there.
This was fixed in . Thank you very much for caring and providing specific instructions.
As a quick experiment, I ran the benchmarks under Firefox: both versions ran in the same speed as the 15.2 in Chrome (I mean: slow). I surely hope the fix would fix it in Firefox too !
Maybe putting these fields on the internal instances instead of global maps will help it in Firefox. Would you like to investigate why it's slow?
I gave it a look, and Firefox slowness is due to DOM being slow. I don’t think we can fix it.
I'd really appreciate a Firefox bug report with testcase here!
I filed with the information of this bug. I don't have the time to do a reduced testcase now though.
FWIW, removeChild is slow in Gecko because of layout. No idea whether setting display: none before removal or some such might speed up the process. It might help if done on the element on which removeChild is being called.
Thank you for filing!


Question: var mocks = require('mocks'); describe('ReactDOMInput', function() { <ins> var EventConstants; </ins> var React; var ReactLink; var ReactTestUtils; beforeEach(function() { require('mock-modules').dumpCache(); <ins> EventConstants = require('EventConstants'); </ins> React = require('React'); ReactLink = require('ReactLink'); ReactTestUtils = require('ReactTestUtils');

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


Question: addChecksumToMarkup: function(markup) { var checksum = adler32(markup); <del> // Add checksum (handle both parent tags and self-closing tags) return markup.replace( TAG_END, ' ' + ReactMarkupChecksum.CHECKSUM_ATTR_NAME + '="' + checksum + '"$&' ); </del> <ins> // Add checksum (handle both parent tags, comments and self-closing tags) if (markup.test(COMMENT_START)) { return markup; } else { return markup.replace( TAG_END, ' ' + ReactMarkupChecksum.CHECKSUM_ATTR_NAME + '="' + checksum + '"$&' ); } </ins> }, /**

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: .Wrapper { padding: 0 0.25rem; <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> height: var(--line-height-data); line-height: var(--line-height-data); display: inline-flex;

Compare two screenshots closely. The space after "from" disappears when the next word is selected. <img width="574" alt="Screenshot 2020-04-07 at 13 26 40" src="https://user-"<img width="776" alt="Screenshot 2020-04-07 at 13 26 35" src="https://user-"
Oops. Yeah this looks like a CSS bug. Each row in the tree is . This means that gets smushed together in a way we don't want. Need to think about this for a minute.


Question: * does diffed reordering and insertion. */ var ReactChildReconciler = { /** * Generates a "mount image" for each of the supplied children. In the case * of `ReactDOMComponent`, a mount image is a string of markup.

Flattening children to an array is 20 times faster than flattening to an object. For long list of elements, this shows up on the initial render flame graphs as pretty hot.


Question: <option value="/email-inputs">Email Input</option> <option value="/selects">Selects</option> <option value="/textareas">Textareas</option> <ins> <option value="/progress">Progress</option> </ins> <option value="/input-change-events"> Input change events </option>

Maybe I missed it but I don't see this case in DOM fixtures: Seems important because it's easy to accidentally gloss over it if we stop syncing attributes and have to edit a bunch of jsdom tests.
Hello I would be interested in working on this. Thanks
Maybe it will really cool feature


Question: 'use strict'; <del> var exec = require('child_process').exec; </del> var jsxTask = require('./grunt/tasks/jsx'); var browserifyTask = require('./grunt/tasks/browserify'); var populistTask = require('./grunt/tasks/populist');

We're blocked on a few things here. Current JSHint is incompatible with what we do with template strings. I have a PR up there to mostly fix it but I bet there are more things. So even after that I think we'll want to switch to using ESLint. However that has its own set of problems as it is still working on ES6/JSX support (mostly blocked on other libraries at this point it seems). I have a PR () up to start using eslint, but there are a few rules disabled (because of incompatibilities on their end) which are really important and enabling them is a blocker for this. [x] Use eslint () [x] Enable all appropriate rules [ ] Add custom rules (namely, must use string literals for 2nd argument)


Question: // effect even though we're bailing out, so that cWU/cDU are called. if (typeof instance.componentDidUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Update;

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is


Question: expect(handleParentClick.mock.calls.length).toBe(0); }); <ins> it('should have mouse enter simulated by test utils', function() { ReactBrowserEventEmitter.putListener( getID(CHILD), ON_MOUSE_ENTER_KEY, recordID.bind(null, getID(CHILD)) ); ReactTestUtils.Simulate.mouseEnter(CHILD); expect(idCallOrder.length).toBe(1); expect(idCallOrder[0]).toBe(getID(CHILD)); }); </ins> it('should infer onTouchTap from a touchStart/End', function() { ReactBrowserEventEmitter.putListener( getID(CHILD),

While testing I wanted to simulate and events, but for some reason they are not firing the handlers in the component. Here's a fiddle to show you: You'll see that with the Simulate functions, only the click is actually triggered, while the other ones not. With the real events everything works perfectly. I tried to debug a little bit what's going on, but didn't get much information, especially since it's the first time I'm diving into the events mechanism internals in React. If you want more info, then I can try and dig a bit deeper, but I think the fiddle is clear enough.
Yeah, unfortunately mouseEnter/mouseLeave don't get simulated properly at the moment due to their unique bubbling situation. The biggest blocker here is picking a good API, I think. Maybe just ?
Why should the user care about where the mouse moves from/to? Perhaps this can be handled internally? Is the problem due to bubbling here? I may need to dive into the code a little more to get a better understanding and stop saying nonsense :P
Yes, it's due to bubbling. If you have the DOM structure and your mouse moves from C to D, then C and B receive mouseleave events, D receives a mouseenter event, and A receives nothing. All other events bubble up to the root. Perhaps it's good enough to just make simulated mouseEnter and mouseLeave events not bubble at all.
That would work at least where I was trying to test. While testing I generally don't need anything too complex, just making sure the right behavior triggers when the event happens. Hopefully that's the way others do as well
(As a workaround for now, you can use SimulateNative.mouseOver and SimulateNative.mouseOut (making sure to specify relatedTarget appropriately on each) and together they will cause React to fire onMouseEnter and onMouseLeave events.)
Do we have a good solution for such case now? I'm trying my solution but feeling so tricky. And I got still quite strange results:
can you give an example. I can't find any documentation on SimulateNative or how to set relatedTarget appropriately?
You want to do something like this: The simulates the mouse moving one element another. The element can be anything really, it’s not important.
Do we have a good solution for such case now? or It can not be solved?

I am manually applying this patch until it is pulled into the core:
Any update on this?
I was able to get my tests to pass using SimulateNative. Here's my codez: Test results:
I tried that using both and instead of but it still did not trigger my event.
If it helps - the difference which worked for me was calling with a and not a . Pass & fail states listed along with full test case below: This seems to also work:
No update so far? Maybe some workarounds?
This was fixed in in April as you can see a few messages up; it'll be in the 0.14 release. If you search "workaround" on this page you'll see that I also posted a workaround over a year ago.
Sorry, really missed it. Thanks for it!


Question: <del> #encoding: utf-8 require('json') # Because of build process, does not necessarily reflect directory path in the # repository. package = JSON.parse(File.read('../../package.json')) gemspec = Gem::Specification.new do |s| s.name = 'react-source' s.version = package['version'] s.license = 'BSD-3-Clause' s.homepage = 'https://github.com/facebook/react' s.summary = 'Ruby bridge to JSX & the React JavaScript library.' s.authors = ['Paul O’Shannessy'] s.email = ['paul@oshannessy.com'] s.files = Dir[ 'build/react.js', 'build/react.min.js', 'build/react-with-addons.js', 'build/react-with-addons.min.js', 'build/JSXTransformer.js', 'lib/react/source.rb' ] end </del>

I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)


Question: withoutStack: true, }); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); <Lazy />; expect(didCall).toBe(false); }); </ins> });

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


Question: return JSXTransformer.transform(code).code; }, editorTabTitle: 'Live JSX Editor', <del> showCompiledJSTab: true </del> <ins> showCompiledJSTab: true, showLineNumbers: false </ins> }; },

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: LOCAL_EXTENSION_ID, } from './constants'; <ins> const IS_CHROME = getBrowserName() === 'Chrome'; </ins> const UNRECOGNIZED_EXTENSION_ERROR = 'React Developer Tools: You are running an unrecognized installation of the React Developer Tools extension, which might conflict with other versions of the extension installed in your browser. ' + 'Please make sure you only have a single version of the extension installed or enabled. ' +

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


Question: this._pendingCallbacks = null; this._pendingElement = null; <del> ReactComponentEnvironment.unmountIDFromEnvironment(this._rootNodeID); </del> // These fields do not really need to be reset since this object is no // longer accessible. this._context = null;

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


Question: <ins> --- id: docs-mixins title: Mixins layout: docs prev: advanced-components.html next: api.html --- Mixins allow code to be shared between multiple React components. They are pretty similar to mixins in Python or traits in PHP. Let's look at a simple example: ```javascript var MyMixin = { getMessage: function() { return 'hello world'; } }; var MyComponent = React.createClass({ mixins: [MyMixin], render: function() { return <div>{this.getMessage()}</div>; } }); ``` A class can use multiple mixins, but no two mixins can define the same method. Two mixins can, however, implement the same [lifecycle method](component-lifecycle.html). In this case, each implementation will be invoked one after another. The only exception is the `shouldComponentUpdate` lifecycle method. This method may only be implemented once (either by a mixin or by the component). ```javascript var Mixin1 = { componentDidMount: function() { console.log('Mixin1.componentDidMount()'); } }; var Mixin2 = { componentDidMount: function() { console.log('Mixin2.componentDidMount()'); } }; var MyComponent = React.createClass({ mixins: [Mixin1, Mixin2], render: function() { return <div>hello world</div>; } }); ``` When `MyComponent` is mounted into the page, the following text will print to the console: ``` Mixin1.componentDidMount() Mixin2.componentDidMount() ``` ## When should you use mixins? In general, add a mixin whenever you want a component to share some utility methods, public interface, or lifecycle behavior. Often it's appropriate to use them as you would use a superclass in another OOP language. </ins>

There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with


Question: var React = require('React'); var ReactMount = require('ReactMount'); var ReactTestUtils = require('ReactTestUtils'); <del> var WebComponents = undefined; </del> <ins> var WebComponents = WebComponents; </ins> try { <del> WebComponents = require('WebComponents'); </del> <ins> if (WebComponents === undefined && jest !== undefined) { WebComponents = require('WebComponents'); } </ins> } catch(e) { <del> /* leave WebComponents undefined */ </del> <ins> // Parse error expected on engines that don't support setters // or otherwise aren't supportable by the polyfill. // Leave WebComponents undefined. </ins> } describe('constructAndRenderComponentByID', function() {

Our tests currently only pass in the browser when running in Chrome. This is because it supports WebComponents already. However they fail in every other browser. I think this is because of when is actually loaded. It's currently getting packaged into react-test because we're requiring it. It creates a new which is resulting in nodes we create with to have a different prototype than what is expected in WebComponents. WebComponents's new Node prototype has a different implementation of which does an check which our nodes are failing. I think if we loaded into the browser before we loaded JS, the node we create for markup wrapping would have the right prototype.


Question: "lint-build": "node ./scripts/rollup/validate/index.js", "extract-errors": "yarn build --type=dev --extract-errors", "postinstall": "node node_modules/fbjs-scripts/node/check-dev-engines.js package.json && node ./scripts/flow/createFlowConfigs.js && node ./scripts/yarn/downloadReactIsForPrettyFormat.js", <del> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source.js --runInBand", </del> <ins> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.source.js --runInBand", </ins> "test": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source.js", "test-persistent": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source-persistent.js", <del> "debug-test-persistent": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source-persistent.js --runInBand", </del> <ins> "debug-test-persistent": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.source-persistent.js --runInBand", </ins> "test-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.source.js", "test-prod-build": "yarn test-build-prod", "test-build": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.build.js", "test-build-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.build.js", "test-build-devtools": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.build-devtools.js", <del> "debug-test-build-devtools": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.build-devtools.js", </del> <ins> "debug-test-build-devtools": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.build-devtools.js", </ins> "test-dom-fixture": "cd fixtures/dom && yarn && yarn prestart && yarn test", "flow": "node ./scripts/tasks/flow.js", "flow-ci": "node ./scripts/tasks/flow-ci.js",

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Throw exception, don't run tests. SyntaxError: missing ) after argument list 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: one of the commands: yarn debug-test yarn debug-test-persistent yarn debug-test-build-devtools chrome://inspect and press “Inspect”. What is the expected behavior? Possibility debug tests. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.2.0 and higher. Chrome 77.0.3865.120 Windows 10. Older version React hasn't this feature.
fixed in


Question: // tell the service worker which versions of backends are needed for the current page function updateRequiredBackends() { <ins> if (requiredBackends.size === 0) { return; } </ins> window.postMessage( { source: 'react-devtools-backend-manager',

the codepen linked above. sure to open the Debug View, so codepen doesn't add any additional iframes (). : Warning in the Console tab: . Error in the Components tab: . After dismissing the error, all components seem to be accounted for (you might need to adjust the "Hide components where..." option). In my actual application the error pops up for every change in the tree, making the devtools virtually unusable. Note: This only seems to happen if the iframe is some time after the initial React tree was mounted in the parent window. When I remove the so the iframe is synchronously, I no longer see any warnings. Related issues: Every time No response 27.7 (5/7/2023) in Google Chrome Version 112.0.5615.165 (Official Build) (64-bit) Cannot add node "3" because a node with that id is already in the Store. No response No response
Hey thanks for reporting this. Can confirm this issue, but I am getting different error on my side and only when refreshing the page. Extension works as expected for me when I open the page for the first time. I will put up a fix for this.
can you please also validate this on your side? You can download a build from our CircleCI pipeline here - Chrome extension should be in archive, you can then install it via dialog in
Yes! I'm no longer seeing the warning/errors when I use the build you linked. Thanks for the fix :)
Great, thanks for helping resolving this. This will be included in v4.27.8 release, which I will publish this week.


Question: "bin": { "react-devtools": "./bin.js" }, <del> "files": [], </del> <ins> "files": [ "bin.js", "app.html", "app.js", "index.js", "icons" ], </ins> "scripts": { "start": "node bin.js" },

react-devtools version: 4.22.0 npm -g install react-devtools react-devtools
This was broken because of . My apologies.
Fix has been published as 4.22.1. Sorry again.
react-devtools: 4.22.1 <img width="417" alt="Screen Shot 2021-12-15 at 1 09 33 PM" src="https://user-"react-devtools: 4.21 has no problem.
Thanks for confirming,


Question: let currentEventTime: number = NoTimestamp; let currentEventTransitionLane: Lanes = NoLanes; <ins> let isRunningInsertionEffect = false; </ins> export function getWorkInProgressRoot(): FiberRoot | null { return workInProgressRoot; }

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: 1. Assign a `ref` attribute to anything returned from `render` such as: <del> ```html <input ref="myInput" /> ``` </del> <ins> ```html <input ref="myInput" /> ``` </ins> 2. In some other code (typically event handler code), access the **backing instance** via `this.refs` as in: <del> ```javascript this.refs.myInput ``` </del> <ins> ```javascript this.refs.myInput ``` </ins> You can access the component's DOM node directly by calling `React.findDOMNode(this.refs.myInput)`.

I'm trying to use the attribute as described here: Unfortunately, sometimes returns , when is called multiple times. MWE:
This is intended – when the component is unmounted or the ref changes, the old ref gets called with null before it's called with the new value (or the same component instance again). If you store the instance on your component, this effect should be unobservable as long as your component is mounted, but it prevents memory leaks. If you want to do something with in the ref handler, you should check if it's null.
Thanks for the information! I think this might be worth mentioning in the docs.


Question: React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> ComponentClass = React.createClass({ render: function() { return React.createElement('div');

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


Question:
ReactDOM = require('react-dom'); ReactTestUtils = require('react-dom/test-utils');  class ClassComponent extends React.Component { render() { return null; } }  TestComponent = class extends React.Component { render() {  return (
 {this.props.destroy ? null : (
Lets try to destroy this.
 )}
 );   if (this.props.destroy) { return
; } else if (this.props.removeRef) { return (

 <ClassComponent />
 ); } else { return (

 <ClassComponent ref="theInnerClassComponent" />
 ); }  } }; });

Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.


Question: // autoFocus is polyfilled/normalized by AutoFocusUtils // autoFocus: HAS_BOOLEAN_VALUE, autoPlay: HAS_BOOLEAN_VALUE, <del> capture: HAS_BOOLEAN_VALUE, </del> <ins> capture: HAS_OVERLOADED_BOOLEAN_VALUE, </ins> checked: MUST_USE_PROPERTY | HAS_BOOLEAN_VALUE, cols: HAS_POSITIVE_NUMERIC_VALUE, contentEditable: HAS_STRING_BOOLEAN_VALUE,

This is a follow-up to . The attribute on elements is currently supported, but it is configured as a attribute: This causes to render as The attribute supports strings though: This is very important for being able to configure the default camera selected on mobile devices.
Should be out in 16.1.1.
I have confirmed that updating to 16.1.1 fixes the issue in my project.


Question: </React.Profiler> </AdvanceTime> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);

: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks