Question: time: true, // There are working polyfills for <dialog>. Let people use it. dialog: true, <ins> // Electron ships a custom <webview> tag to display external web content in // an isolated frame and process. // This tag is not present in non Electron environments such as JSDom which // is often used for testing purposes. // @see https://electronjs.org/docs/api/webview-tag webview: true, </ins> }; validatePropertiesInDevelopment = function(type, props) {

Do you want to request a feature or report a bug? Bug (for electron users) What is the current behavior? When running jest, if any components containing a webview element are rendered, a warning is rendered to the console. When many tests are run, the output is littered with warnings. 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? No warning is logged to the console. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React: 16.4.1 Electron: 2.0.6 Unknown if it worked in prior versions of react.
What other special tags does Electron have?
Looking through their docs it seems to be only the tag for now:
In that case I don’t mind adding it to the whitelist. Send a PR?
You beat me to the punch. Thanks so much and


Question: * ${license} */ <del> 'use strict'; </del> ${source}`; },

React version: 16.13.1 Even though React's code (and other packages like ReactDOM) are wrapped in a IIFE, the code applies an entire script strict mode by placing a 'use strict' before any other statement: MDN mentions the "trap" of concatenating conflicting scripts strict mode when using the entire script strict mode, see . a file with React's code at the top and concat an expression that causes a 'use strict' violation this file as a script tag Link to code example: (Scroll to bottom of file to see the concatenated expressions) 'use strict' mode is enforced on all the concatenated code, even if it was not defined as 'strict'. As a result, 'strict' violations at the other concatenated libraries will now throw errors (instead of silencing them), causing the script to stop execution. Global 'use strict' should not be used and should be replaced with function scope strict mode (which already exist in some cases of React IIFE bundles code wrappers, like ). - Always wrap UMD bundles in IIFEs - options for the build script stating - explained (vs )
Thanks for the super quick handling!


Question: ); }); <ins> it('does not report work done on a sibling', () => { const callback = jest.fn(); const DoesNotUpdate = React.memo(function DoesNotUpdateInner() { Scheduler.unstable_advanceTime(10); return null; }, () => true); let updateProfilerSibling; function ProfilerSibling() { const [count, setCount] = React.useState(0); updateProfilerSibling = () => setCount(count + 1); return null; } function App() { return ( <React.Fragment> <React.Profiler id="test" onRender={callback}> <DoesNotUpdate /> </React.Profiler> <ProfilerSibling /> </React.Fragment> ); } const renderer = ReactTestRenderer.create(<App />); expect(callback).toHaveBeenCalledTimes(1); let call = callback.mock.calls[0]; expect(call).toHaveLength(enableSchedulerTracing ? 7 : 6); expect(call[0]).toBe('test'); expect(call[1]).toBe('mount'); expect(call[2]).toBe(10); // actual time expect(call[3]).toBe(10); // base time expect(call[4]).toBe(0); // start time expect(call[5]).toBe(10); // commit time expect(call[6]).toEqual(enableSchedulerTracing ? new Set() : undefined); // interaction events callback.mockReset(); Scheduler.unstable_advanceTime(20); // 10 -> 30 // Updating a parent should report a re-render, // since React technically did a little bit of work between the Profiler and the bailed out subtree. renderer.update(<App />); expect(callback).toHaveBeenCalledTimes(1); call = callback.mock.calls[0]; expect(call).toHaveLength(enableSchedulerTracing ? 7 : 6); expect(call[0]).toBe('test'); expect(call[1]).toBe('update'); expect(call[2]).toBe(0); // actual time expect(call[3]).toBe(10); // base time expect(call[4]).toBe(30); // start time expect(call[5]).toBe(30); // commit time expect(call[6]).toEqual(enableSchedulerTracing ? new Set() : undefined); // interaction events callback.mockReset(); Scheduler.unstable_advanceTime(20); // 30 -> 50 // Updating a sibling should not report a re-render. ReactTestRenderer.act(updateProfilerSibling); expect(callback).not.toHaveBeenCalled(); }); </ins> it('logs render times for both mount and update', () => { const callback = jest.fn();

: 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


Question: "uglifyify": "^3.0.1" }, "devEngines": { <del> "node": "4.x || 5.x", </del> <ins> "node": "4.x || 5.x || 6.x", </ins> "npm": "2.x || 3.x" }, "commonerConfig": {

The does not accept a node engine of version 6.x I don't think that there is some regressions caused by Node v6, so it should be okay?
there is in npm package.
My bad, -- I meant the , you cannot without getting an error with Node v6.0.0.


Question: 'Can only set one of `children` or `props.dangerouslySetInnerHTML`.' ); invariant( <del> props.dangerouslySetInnerHTML.__html != null, </del> <ins> typeof props.dangerouslySetInnerHTML === 'object' && '__html' in props.dangerouslySetInnerHTML, </ins> '`props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`. ' + 'Please visit https://fb.me/react-invariant-dangerously-set-inner-html ' + 'for more information.'

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


Question: expect(isTagStackValid(['table', 'tr'])).toBe(false); expect(isTagStackValid(['div', 'ul', 'li', 'div', 'li'])).toBe(false); expect(isTagStackValid(['div', 'html'])).toBe(false); <ins> expect(isTagStackValid(['body', 'body'])).toBe(false); expect(isTagStackValid(['svg', 'foreignObject', 'body', 'p'])).toBe(false); </ins> }); });

(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's call the callback from the `CommentForm` when the user submits the form: <del> ```javascript{6} </del> <ins> ```javascript{10} </ins> // tutorial18.js var CommentForm = React.createClass({ handleSubmit: function(e) {

<!-- 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? In shallow renderer, The returned callback from is not the same one between two rerendering even though the dependencies are the same. But will work as expected. For example, the following test won't work: If returned the same callback between two rendering (I think) the assertion should pass. but the same (almost) logic will work with , in the shallow renderer test suite (See ). 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 created a branch in and you can run the failed shallow renderer test in . What is the expected behavior? should return the memoized callback when the dependencies unchanged even in shallow renderer. I tried to look into this and I found out that in shallow renderer just returns the original callback argument (See ) but will compare the dependencies between rendering. I'm not sure if it's intended (So it's expected that will not memoize callback in shallow renderer). If it's triaged as a bug I'm glad to send a pr for this :) Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? react
yup, this looks like a miss on our part. Would you like to send a PR? :)
thanks for reply :-) I'd try to make a PR in a few days.
I don't think it's a miss on our part. It was an intentional decision since it's mostly an optimization, and unclear why it would be important for shallow rendering to do that. Can you explain why it matters?
It’s important for shallow rendering to match production as much as possible, since shallow rendering is a testing tool.
Agree to Even it's optimization I think there might be still case that we want to make sure we've really do the optimization (though not guaranteed in production) in code.
Is this still open to be worked on?

For this code and statement: Isn't it creating two instances, and then rendering each of them independently? AFAIK this is not two renderings of the same, but instead two different elements. If I have a component rendered in different places those are independent of each other. They keep the same callback between re-renders, but not across all the instances.
The shallow renderer has moved to If this is still relevant, please feel free to file this issue there. Thanks!


Question:
{{ page.title }}

{{ page.date | date_to_string }} by {{ page.author }}

 {% if content != '' %} {{ content }} {% else %} {{ page.content }} {% endif %}

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


Question: }); } <del> if (this._isProfiling !== isProfiling) { this._isProfiling = isProfiling; </del> <ins> this._isProfiling = isProfiling; </ins> <del> // Invalidate suspense cache if profiling data is being (re-)recorded. // Note that we clear again, in case any views read from the cache while profiling. // (That would have resolved a now-stale value without any profiling data.) this._cache.invalidate(); </del> <ins> // Invalidate suspense cache if profiling data is being (re-)recorded. // Note that we clear again, in case any views read from the cache while profiling. // (That would have resolved a now-stale value without any profiling data.) this._cache.invalidate(); </ins> <del> this.emit('isProfiling'); </del> <ins> this.emit('isProfiling'); </ins> <del> // If we've just finished a profiling session, we need to fetch data stored in each renderer interface // and re-assemble it on the front-end into a format (ProfilingDataFrontend) that can power the Profiler UI. // During this time, DevTools UI should probably not be interactive. if (!isProfiling) { this._dataBackends.splice(0); this._rendererQueue.clear(); </del> <ins> // If we've just finished a profiling session, we need to fetch data stored in each renderer interface // and re-assemble it on the front-end into a format (ProfilingDataFrontend) that can power the Profiler UI. // During this time, DevTools UI should probably not be interactive. if (!isProfiling) { this._dataBackends.splice(0); this._rendererQueue.clear(); </ins> <del> // Only request data from renderers that actually logged it. // This avoids unnecessary bridge requests and also avoids edge case mixed renderer bugs. // (e.g. when v15 and v16 are both present) this._rendererIDsThatReportedProfilingData.forEach(rendererID => { if (!this._rendererQueue.has(rendererID)) { this._rendererQueue.add(rendererID); </del> <ins> // Only request data from renderers that actually logged it. // This avoids unnecessary bridge requests and also avoids edge case mixed renderer bugs. // (e.g. when v15 and v16 are both present) this._rendererIDsThatReportedProfilingData.forEach(rendererID => { if (!this._rendererQueue.has(rendererID)) { this._rendererQueue.add(rendererID); </ins> <del> this._bridge.send('getProfilingData', {rendererID}); } }); </del> <ins> this._bridge.send('getProfilingData', {rendererID}); } }); </ins> <del> this.emit('isProcessingData'); } </del> <ins> this.emit('isProcessingData'); </ins> } }; }

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

debugging my nextjs project to find out which component is slowing down my application by using react devtools profiler section. when i start recording by clcking the blue button it start recording. then when go to my page and navigate different page like first i sign in to my application and then navigate from home to my when i stop the recording this error occured. Every time react-devtools-extensions 2- Could not find node with id "464" in commit tree
best of luck
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0


Question: <ins> // Do not delete or move this file. // Many fiddles reference it so we have to keep it here. (function() { var tag = document.querySelector( 'script[type="application/javascript;version=1.7"]' ); if (!tag || tag.textContent.indexOf('window.onload=function(){') !== -1) { alert('Bad JSFiddle configuration, please fork the original React JSFiddle'); } tag.setAttribute('type', 'text/babel'); tag.textContent = tag.textContent.replace(/^//<![CDATA[/, ''); })(); </ins>  No newline at end of file

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


Question: var ON_CLICK_KEY = keyOf({onClick: null}); var onClickListeners = {}; <ins> function getDictionaryKey(inst) { return '.' + inst._rootNodeID; } </ins> var SimpleEventPlugin = { eventTypes: eventTypes,

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: componentWillReceiveProps: function(nextProps) { if (!nextProps.children && this.props.children) { this.savedChildren = this.props.children; <ins> } else if (nextProps.children && !this.props.children) { // We're being told to re-add the child.  Let's stop leaving! if (this.isMounted()) { var node = this.getDOMNode(); var className = this.props.name; CSSCore.removeClass(node, className + '-leave'); CSSCore.removeClass(node, className + '-leave-active'); if (this.props.enter) { CSSCore.addClass(node, className + '-enter'); CSSCore.addClass(node, className + '-enter-active'); } } </ins> } },

Please see: and do the following: 'Toggle' to make the list-item fade into view. -click/Spam-click the 'Toggle' button again to make the item fade-out of view. 'Toggle' again to try to make the component come back into view. You'll see that the item doesn't come back! If you check the HTML, you can see that the list-item is still there, with the class name "example-leave example-leave-active". I suspect that React should reverse the animation elegantly in the case of the same component being re- in the render function during a leave transition.
Thanks, I was going to point you to but I see that you're the author of it!
Hehe, I thought perhaps it'd be best if I made a proper Issue (with JSFiddle example!) rather than just rudely posting Pull Requests! :)


Question: color: var(--color-text); } <ins> .Profiler, .Profiler * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); } </ins> .LeftColumn { display: flex; flex-direction: column;

I don't see the selection at all. My version is 4.5.0. I think this regressed. <img width="266" alt="Screenshot 2020-03-11 at 23 40 37" src="https://user-"
This is interesting. The extension seems to have a shorter toolbar height than I would expect, which is clipping the current index. Here's what the test harness/shell looks like: <img width="437" alt="Screen Shot 2020-03-11 at 6 11 50 PM" src="https://user-"
Looks like something is going wrong with the relative height of the list items in the extension. Works fine in Chrome but it's overflowing in the extension.
Ah, it looks like the style isn't cascading correctly in the extension.
I think this probably regressed with , because the extension uses portals to mount (so they don't get mounted underneath of the class).
Yay! Fixed. <img width="369" alt="Screen Shot 2020-03-11 at 6 35 52 PM" src="https://user-"


Question: visitor: { CallExpression: function(path, file) { <del> if (file.filename.indexOf('shared/assign') !== -1) { </del> <ins> if (/shared(/|)assign/.test(file.filename)) { </ins> // Don't replace Object.assign if we're transforming shared/assign return; }

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: Current main branch the repository from the main branch node and yarn (node version: 16.14.0, yarn version: 1.22.17, JDK version: tried both 11 and 17) yarn yarn build <!-- 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. --Error message : <!-- 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: --No error messages from rollup. Success in yarn build.
If rollup is crashing during the build process, that's a rollup problem.
Yes, that was what my colleagues and I are thinking too. Then shouldn't something change related to Rollup, like going back to the previous version of code, or another way to resolve the error in the react project?
Exactlly it's the problem of Rollup and already fix it two years ago. See
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!


Question: }, isDOMComponent: function(inst) { <del> // TODO: Fix this heuristic. It's just here because composites can currently // pretend to be DOM components. </del> return !!(inst && inst.nodeType === 1 && inst.tagName); },

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: ); });  // Fixes: https://github.com/facebook/react/issues/27910 it('omits preloads for images inside noscript tags', async () => { function App() { return (         ); } await act(() => { renderToPipeableStream(<App />).pipe(writable); }); expect(getMeaningfulChildren(document)).toEqual(   <link rel="preload" href="foo" as="image" />    <img src="bar">  , ); });  it('should handle media on image preload', async () => { function App({isClient}) { ReactDOM.preload('/server', {

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 18.3.0-canary-- SSR app that has images in its tree using renderToString or renderToPipeableStream <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --! To not insert preloads randomly. Note that there is difference between renderToString and renderToPipeableStream, renderToString the preloads appear inside root and renderToPipeableStream they appear in head. Sorry this is a bit of a question rather than bug report maybe, I have searched around and cannot see any mention of auto-preloading images but I assume there must be something going on that I have missed. I was able to fix by using .
This. Tested with . It would be "kinda" tolerable for the LCP image above fold (featured image or similar), but we have lots of lazy loaded images below fold which contain <noscriptalternatives like: For every tag used in noscript, the image is preloaded in which completely defies the purpose of lazy loading.
I think this is actually now expected behaviour, after digging the source a bit I found Though I could not find any docs/release notes that mention this which is a little odd as now you need to explicitly think about the loading strategy of every img tag you use. For me I was able to "fix" this by making sure all our img tags have either loading=lazy or fetchPriority=low when they are not to be preloaded, this gave me more or less only the LCP images preloaded. For your case you could either add loading=lazy or fetchPriority=low to the fallback images, though depending on your target browsers you could get rid of the noscript parts these days as loading=lazy has pretty wide browser support now.

Would be good to have this documented somewhere and also maybe add this to the react linter.
Thanks for the info regarding loading=lazy, that could solve it. If this is really a "feature", I have to say, I don't think it should be React's business to put stuff into my automagically…
Which framework are you using?
For me, its Remix.
You're probably using their image component that uses . Or they're doing calls some other way. Can you open an issue on their issue tracker first to clarify?
I'm not using their image component but , but I will take a look at Remix & React Router code, whether they call this somewhere and open an issue. Interestingly, this behavior is only applied by Remix (or happens for some reason), when upgrading to React canary.
React is adding support for Suspensey "resource". For instance if you render a stylesheet and opt into React's handling of this using "precedence" then commits which contain this stylesheet will wait to commit until the sheet has loaded. Another area that we're making Suspensey is images. Lazy images indicate that they do not require suspense coordination but by default images will (in the future) block a boundary reveal until the image has loaded and been decoded. While these features are for client updates there are analogs for SSR. for stylesheets browsers already block paint until stylesheets load in the head. They don't however do this for images. React canaries now preload the first few images rendered if they are not lazy because we want to mimic the coordinated reveal of Suspensey images along with the first paint. It's not a perfect heuristic because it's not actually enforced to be coordinated but it does better align the behavior across suspensy vs lazy images. Another way you can signal to React that an image is not expected to be part of the first paint is to set the fetchPriority to "low"
For every <imgtag used in noscript, the image is preloaded in <headwhich completely defies the purpose of lazy loading. This is a genuine bug. will land a fix
Good to know, thanks for the explanation.
fwiw no framework used just renderToPipeableStream, in my case I was able to add low priority to a few icon images to get the preload to load reasonable candidates.

Would be good to be able to opt-out of this somehow for a boundary, thinking of the case where you are waiting on component/data to load and don't really care about the image but lazy loading would be inappropriate for an above the fold larger image. Maybe even a way to modify the heuristic via some sort of callback would be useful.


Question: --- id: tutorial-ja-JP title: チュートリアル <ins> permalink: tutorial-ja-JP.html </ins> prev: getting-started-ja-JP.html next: thinking-in-react-ja-JP.html ---

At gh-pages branch, there are and files. I think those file name must be and .
Thanks! I just pushed the change to the stable branch so this should be updated on the site and in the gh-pages branch as soon as it builds.
Thanks!


Question: expect(root).toMatchRenderedOutput('SiblingB'); }); <ins> it('resolves defaultProps without breaking bailout due to unchanged props and state, #17151', async () => { class LazyImpl extends React.Component { static defaultProps = {value: 0}; render() { const text = `${this.props.label}: ${this.props.value}`; return <Text text={text} />; } } const Lazy = lazy(() => fakeImport(LazyImpl)); const instance1 = React.createRef(null); const instance2 = React.createRef(null); const root = ReactTestRenderer.create( <> <LazyImpl ref={instance1} label="Not lazy" /> <Suspense fallback={<Text text="Loading..." />}> <Lazy ref={instance2} label="Lazy" /> </Suspense> </>, { unstable_isConcurrent: true, }, ); expect(Scheduler).toFlushAndYield(['Not lazy: 0', 'Loading...']); expect(root).not.toMatchRenderedOutput('Not lazy: 0Lazy: 0'); await Promise.resolve(); expect(Scheduler).toFlushAndYield(['Lazy: 0']); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to unchanged props and state instance1.current.setState(null); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to unchanged props and state instance2.current.setState(null); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); }); it('resolves defaultProps without breaking bailout in PureComponent, #17151', async () => { class LazyImpl extends React.PureComponent { static defaultProps = {value: 0}; state = {}; render() { const text = `${this.props.label}: ${this.props.value}`; return <Text text={text} />; } } const Lazy = lazy(() => fakeImport(LazyImpl)); const instance1 = React.createRef(null); const instance2 = React.createRef(null); const root = ReactTestRenderer.create( <> <LazyImpl ref={instance1} label="Not lazy" /> <Suspense fallback={<Text text="Loading..." />}> <Lazy ref={instance2} label="Lazy" /> </Suspense> </>, { unstable_isConcurrent: true, }, ); expect(Scheduler).toFlushAndYield(['Not lazy: 0', 'Loading...']); expect(root).not.toMatchRenderedOutput('Not lazy: 0Lazy: 0'); await Promise.resolve(); expect(Scheduler).toFlushAndYield(['Lazy: 0']); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to shallow equal props and state instance1.current.setState({}); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); // Should bailout due to shallow equal props and state instance2.current.setState({}); expect(Scheduler).toFlushAndYield([]); expect(root).toMatchRenderedOutput('Not lazy: 0Lazy: 0'); }); </ins> it('sets defaultProps for modern lifecycles', async () => { class C extends React.Component { static defaultProps = {text: 'A'};

<!-- 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: CSSTransitionGroup: { module: 'ReactCSSTransitionGroup', name: 'css-transition-group', <ins> docs: 'animation', </ins> }, LinkedStateMixin: { module: 'LinkedStateMixin', name: 'linked-state-mixin', <ins> docs: 'two-way-binding-helpers', </ins> }, Perf: { module: 'ReactDefaultPerf', name: 'perf', <ins> docs: 'perf', </ins> }, PureRenderMixin: { module: 'ReactComponentWithPureRenderMixin', name: 'pure-render-mixin', <ins> docs: 'pure-render-mixin', </ins> }, TestUtils: { module: 'ReactTestUtils', name: 'test-utils', <ins> docs: 'test-utils', </ins> }, TransitionGroup: { module: 'ReactTransitionGroup', name: 'transition-group', <ins> docs: 'animation', </ins> }, cloneWithProps: { module: 'cloneWithProps', name: 'clone-with-props', <ins> docs: 'clone-with-props', </ins> }, createFragment: { module: 'ReactFragment', method: 'create', name: 'create-fragment', <ins> docs: 'create-fragment', </ins> }, shallowCompare: { module: 'shallowCompare',

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


Question: */ function transformReact(source, options) { // TODO: just use react-tools <ins> options = options || {}; </ins> var visitorList; <del> if (options && options.harmony) { </del> <ins> if (options.harmony) { </ins> visitorList = visitors.getAllVisitors(); } else { visitorList = visitors.transformVisitors.react; } return transform(visitorList, source, { <del> sourceMap: supportsAccessors </del> <ins> sourceMap: supportsAccessors && options.sourceMap </ins> }); }

This is a tricky issue, so I'll do my best to explain: I've been using the to build my React app using AMD. I've been using a of React (with ), which is based off of master. Until recently, everything was working fine. But since , I've been unable to create optimized builds using the plugin. At first, I assumed it was an issue with the plugin, but it seems that the offending line is the changed function: Until this change, wasn't forced on, and things worked just fine. With this change, it's no longer possible to build in an AMD environment, as errors out with: My best guess is that the isn't being correctly loaded (although it is included ), but I don't know enough about Browserify to debug this. Hoping someone else can take a look and find out what's going on. (in the meantime, I suppose I'll update my branch to undo the change that set )
is this still happening for you?
just updated to v0.9.0, and yep: Unfortunately still having to maintain my own branch :(
I have the same issue.
thanks for tracking this issue down. I was trying to update React in and was puzzled by this. I will disable it manually in the modified provides.


Question: } } <ins> var testFunc = function testFn() {}; warning( (testFunc.name || testFunc.toString()).indexOf('testFn') !== -1, 'It looks like you're using a minified copy of the development build ' + 'of React. When deploying React apps to production, make sure to use ' + 'the production build which skips development warnings and is faster. ' + 'See https://fb.me/react-minification for more details.' ); </ins> // If we're in IE8, check to see if we are in compatibility mode and provide // information on preventing compatibility mode var ieCompatibilityMode =

Do we want to do this now? mentioned this but I forgot about it until this morning.
That would be nice but shouldn't be blocking. We can make that 0.15.


Question: ); ReactShallowRenderer.prototype.render = function(element, context) { <ins> if (!context) { context = emptyObject; } </ins> var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(); this._render(element, transaction, context); ReactUpdates.ReactReconcileTransaction.release(transaction);

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: draggable: null, encType: null, form: MUST_USE_ATTRIBUTE, <ins> formAction: MUST_USE_ATTRIBUTE, formEncType: MUST_USE_ATTRIBUTE, formMethod: MUST_USE_ATTRIBUTE, </ins> formNoValidate: HAS_BOOLEAN_VALUE, <ins> formTarget: MUST_USE_ATTRIBUTE, </ins> frameBorder: MUST_USE_ATTRIBUTE, headers: null, height: MUST_USE_ATTRIBUTE,

Docs here: And those ones taged as HTML5 are not in the list of supported tags:
, are in there. is handled at run time. The others are missing.
It seems autoFocus is not supported on server side rendering
The property should add the attribute to the html input element too. This is especially useful if you decide to do server-side rendering only. There shouldn’t be a conflict with the current JS code that handles auto focus on unsupported browsers.


Question: 'OverrideDisplayName', ); }); it('should return correct display name for an element with a type of StrictMode', () => { const element = createElement(StrictMode); expect(getDisplayNameForReactElement(element)).toEqual('StrictMode'); }); it('should return correct display name for an element with a type of SuspenseList', () => { const element = createElement(SuspenseList); expect(getDisplayNameForReactElement(element)).toEqual('SuspenseList'); }); it('should return NotImplementedInDevtools for an element with invalid symbol type', () => { const element = createElement(Symbol('foo')); expect(getDisplayNameForReactElement(element)).toEqual( 'NotImplementedInDevtools', ); }); it('should return NotImplementedInDevtools for an element with invalid type', () => { const element = createElement(true); expect(getDisplayNameForReactElement(element)).toEqual( 'NotImplementedInDevtools', ); }); it('should return Element for null type', () => { const element = createElement(); expect(getDisplayNameForReactElement(element)).toEqual('Element'); }); }); <ins> describe('format', () => { it('should format simple strings', () => { expect(format('a', 'b', 'c')).toEqual('a b c'); }); it('should format multiple argument types', () => { expect(format('abc', 123, true)).toEqual('abc 123 true'); }); it('should support string substitutions', () => { expect(format('a %s b %s c', 123, true)).toEqual('a 123 b true c'); }); it('should gracefully handle Symbol types', () => { expect(format(Symbol('a'), 'b', Symbol('c'))).toEqual( 'Symbol(a) b Symbol(c)', ); }); it('should gracefully handle Symbol type for the first argument', () => { expect(format(Symbol('abc'), 123)).toEqual('Symbol(abc) 123'); }); }); </ins> });

This function will throw this error if one of the arguments is type of . The error is swallowed but it does interfere with debugging. When I run with the "pause on caught exceptions" I get trapped here all the time. Can we change into ??? Every time No response 13.2- TypeError: Cannot convert a Symbol value to a string No response No response No response


Question: Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <AdvanceTime byAmount={20} /> <React.Profiler id="test" onRender={callback}> <AdvanceTime byAmount={5} /> </React.Profiler> <AdvanceTime byAmount={20} /> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(1);

: 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


Question: if (!styles.hasOwnProperty(styleName)) { continue; } <ins> if (__DEV__) { if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } } </ins> var styleValue = dangerousStyleValue(styleName, styles[styleName]); if (styleValue) { style[styleName] = styleValue;

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


Question: object-assign "^4.1.0" prop-types "^15.5.10" <ins> "react-16-8@npm:react@16.8.0": version "16.8.0" resolved "https://registry.yarnpkg.com/react/-/react-16.8.0.tgz#8533f0e4af818f448a276eae71681d09e8dd970a" integrity sha512-g+nikW2D48kqgWSPwNo0NH9tIGG3DsQFlrtrQ1kj6W77z5ahyIHG0w8kPpz4Sdj6gyLnz0lEd/xsjOoGge2MYQ== dependencies: loose-envify "^1.1.0" object-assign "^4.1.1" prop-types "^15.6.2" scheduler "^0.13.0" </ins> "react-dom-15@npm:react-dom@^15": version "15.6.2" resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-15.6.2.tgz#41cfadf693b757faf2708443a1d1fd5a02bef730"

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

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

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

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

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


Question: `), ).toMatchSnapshot(); }); <ins> it('can handle implicit arrow returns', () => { expect( transform(` export default () => useContext(X); export const Foo = () => useContext(X); module.exports = () => useContext(X); const Bar = () => useContext(X); const Baz = memo(() => useContext(X)); const Qux = () => (0, useContext(X)); `), ).toMatchSnapshot(); }); </ins> });

Using 0.4.0 is giving me this error on a large number of files: I narrowed down that file to the simplest thing that causes it: Originally posted by in
Fixed in 0.4.1


Question: } case Profiler: if (enableProfilerTimer) { <del> workInProgress.effectTag |= Update; </del> <ins> // Profiler should only call onRender when one of its descendants actually rendered. const hasChildWork = workInProgress.childExpirationTime >= renderExpirationTime; if (hasChildWork) { workInProgress.effectTag |= Update; } </ins> } break; case SuspenseComponent: {

: 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


Question: var app = <MyComponent someProperty={true} />; ``` <ins> JSX will infer the component's name from the variable assignment and specify the class's [displayName](/react/docs/component-specs.html#displayName) accordingly. </ins> See [Multiple Components](/react/docs/multiple-components.html) to learn more about using composite components. > Note:

I couldn't find a reference to the fact that jsx transform attaches to the component spec, this would be nice to document somewhere (more importantly, that not using jsx means debugging messages will be littered with ). I found this while using .
That would be very nice indeed. If you want to take a stab at it, the docs are in the repo in the markdown format. Would love to have you on the contributor list :)


Question: case MemoComponent: { const type = workInProgress.type; const unresolvedProps = workInProgress.pendingProps; <del> const resolvedProps = resolveDefaultProps(type.type, unresolvedProps); </del> <ins> // Resolve outer props first, then resolve inner props. let resolvedProps = resolveDefaultProps(type, unresolvedProps); resolvedProps = resolveDefaultProps(type.type, resolvedProps); </ins> return updateMemoComponent( current, workInProgress,

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


Question: loose-envify "^1.1.0" object-assign "^4.1.1" <ins> scheduler@^0.13.0: version "0.13.6" resolved "https://registry.yarnpkg.com/scheduler/-/scheduler-0.13.6.tgz#466a4ec332467b31a91b9bf74e5347072e4cd889" integrity sha512-IWnObHt413ucAYKsD9J1QShUKkbKLQQHdxRyw73sw4FN26iWr3DY/H34xGPe4nmL1DwXyWmSWmMrA9TfQbE/XQ== dependencies: loose-envify "^1.1.0" object-assign "^4.1.1" </ins> schema-utils@^1.0.0: version "1.0.0" resolved "https://registry.yarnpkg.com/schema-utils/-/schema-utils-1.0.0.tgz#0b79a93204d7b600d4b2850d1f66c2a34951c770"

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

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

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

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

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


Question: ); }); <ins> itRenders('svg element with a tabIndex attribute', async render => { let e = await render(<svg tabIndex="1" />); expect(e.tabIndex).toBe(1); }); itRenders( 'svg element with a badly cased tabIndex attribute', async render => { let e = await render(<svg tabindex="1" />, 1); expect(e.tabIndex).toBe(1); }, ); </ins> itRenders('a math element', async render => { const e = await render(<math />); expect(e.childNodes.length).toBe(0);

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


Question: if (options.harmony) { visitorSets.push('harmony'); } <ins> if (options.es3) { visitorSets.push('es3'); } </ins> if (options.stripTypes) { // Stripping types needs to happen before the other transforms // unfortunately, due to bad interactions. For example,

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: var React = { DOM: ReactDOM, <ins> Props: ReactProps, </ins> initializeTouchEvents: function(shouldUseTouch) { ReactMount.useTouchEvents = shouldUseTouch; },

! The only alternative is using chains which aren't very readable at their own.
I think you're making it more complicated than it needs to be. If it uses some prop like : However, note that this doesn't guarantee requests come in order. So a better solution would be: This is a good article that goes into more detail and has more useful examples: In longer term, we'll recommend Suspense for data fetching which will look more like and no effects. But in the meantime the code above works fine.
What if I need to close over ? (Or based on your example): Also where do the errors go that are thrown in that async function invocation? I'd need to it? Or try/catch the body of the async so the promise always resolves? Why not make useEffect take an async function if we'd have to wrap them all the time anyways?
I guess one can always just :
now I should use instead of into a React Component with Hooks. Scenario "initial unique call to a server": To accomplished this, DependencyList ( second argument of useEffect) in useEffect should every time an empty array otherwise the application will send every state change a fetch call to the server. it' means , this it the best practise to getData ` Full Code here <details
Please ask on StackOverflow and feel free to link to your question from here. We don’t use issues for support because answers get lost on GitHub.
supports being async so I think useEffect should accept a promise and automatically resolve it to avoid having to them.
It is an intentional design decision. The async/await model is a pitfall for effects in general (and has always been a pitfall in classes!) due to race conditions. In the longer term, Suspense will be the recommended data fetching solution, and you can do / there. But Suspense for data fetching is not ready yet.
As I explained above, is a bad idea because you don't know whether is still relevant. For example, if the user starts fetching one profile page but then switches to another profile. Then you're at the mercy of which request arrives first, and can show incorrect data. This kind of code would handle it correctly: I'm going to lock this issue as resolved to prevent further confusion. Here's a good article that answers your other questions (e.g. about loading states):


Question: ## Practical Examples <del> * [React ART](https://github.com/facebook/react/blob/master/src/renderers/art/ReactARTFiberEntry.js) * [React DOM](https://github.com/facebook/react/blob/master/src/fb/ReactDOMFiberFBEntry.js) * [React Native](https://github.com/facebook/react/blob/master/src/renderers/native/ReactNativeFiberRenderer.js) </del> <ins> * [React ART](https://github.com/facebook/react/blob/master/packages/react-art/src/ReactART.js) * [React DOM](https://github.com/facebook/react/blob/master/packages/react-dom/src/client/ReactDOM.js) * [React Native](https://github.com/facebook/react/blob/master/packages/react-native-renderer/src/ReactNativeFiberRenderer.js) </ins> If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving.

Reporting this since it says "If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving." and knowing the place of the most up-to-date examples would help me a lot. The issue template does not really fit here but I'm trying to follow it anyway. Do you want to request a feature or report a bug? Bug (In a README) What is the current behavior? In there are 3 links to reconciler configuration examples of , and . All 3 links are broken 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 for React 16: , template for React 15: ). Just visit the  What is the expected behavior? Correct links I wanted to fix these in a PR but could only find an appropriate replacement for react-native here: Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Issue exists on -branch
The other ones are called just ReactDOM and ReactART. Please submit a PR.


Question: 'use strict'; <del> var mouseListenerNames = { onClick: true, onDoubleClick: true, onMouseDown: true, onMouseMove: true, onMouseUp: true, onClickCapture: true, onDoubleClickCapture: true, onMouseDownCapture: true, onMouseMoveCapture: true, onMouseUpCapture: true, }; </del> <ins> var DisabledInputUtils = require('DisabledInputUtils'); </ins> /** * Implements a <button> native component that does not receive mouse events * when `disabled` is set. */ var ReactDOMButton = { <del> getNativeProps: function(inst, props) { if (!props.disabled) { return props; } // Copy the props, except the mouse listeners var nativeProps = {}; for (var key in props) { if (props.hasOwnProperty(key) && !mouseListenerNames[key]) { nativeProps[key] = props[key]; } } return nativeProps; }, </del> <ins> getNativeProps: DisabledInputUtils.getNativeProps, </ins> }; module.exports = ReactDOMButton;

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: { "name": "react-devtools-inline", <del> "version": "4.27.7", </del> <ins> "version": "4.27.8", </ins> "description": "Embed react-devtools within a website", "license": "MIT", "main": "./dist/backend.js",

local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.


Question: - `order` - `orphans` - `strokeOpacity` <ins> - `tabSize` </ins> - `widows` - `zIndex` - `zoom`

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


Question: it('warns when classic properties are defined on the instance, ' + 'but does not invoke them.', function() { spyOn(console, 'error'); <ins> var getDefaultPropsWasCalled = false; </ins> var getInitialStateWasCalled = false; class Foo extends React.Component { constructor() {

I am working on a very simple component with default props. And I simply render it without any props (). But I got an empty object from console output. I am using react 0.13.1, chrome 41, OSX 10.10. Any idea what is going wrong?
Es6 classes need defaultProps as a static property. Navigation.defaultProps = {...}
Thanks. Maybe update this in documentation :) ? I will be happy to send in a PR
has some commentary on docs and es6. I agree that I’d like to see better docs on the class syntax. I’m just a guy who happened to see your issue really quickly :)
does reference this. It might be good to also put some documentation in to make it a bit easier to find. I'm going to close this out since it's invalid but I'd love to see a PR with more docs :)
I think you should have also seen a runtime warning for this?
not really, though
Thanks, looks like an oversight. Fix incoming…


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('allows static methods to be called using the type property', function() { spyOn(console, 'error');

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

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


Question: ); }); <del> it('gives a helpful error when passing null or undefined', function() { </del> <ins> it('gives a helpful error when passing null, undefined, or boolean', () => { </ins> var Undefined = undefined; var Null = null; <ins> var True = true; var Num = 123; </ins> var Div = 'div'; spyOn(console, 'error'); <Undefined />; <Null />; <del> expect(console.error.calls.length).toBe(2); </del> <ins> <True />; <Num />; expect(console.error.calls.length).toBe(4); </ins> expect(console.error.calls[0].args[0]).toContain( <del> 'type should not be null or undefined. It should be a string (for ' + 'DOM elements) or a ReactClass (for composite components).' </del> <ins> 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' </ins> ); expect(console.error.calls[1].args[0]).toContain( <del> 'type should not be null or undefined. It should be a string (for ' + 'DOM elements) or a ReactClass (for composite components).' </del> <ins> 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' ); expect(console.error.calls[2].args[0]).toContain( 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' ); expect(console.error.calls[3].args[0]).toContain( 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' </ins> ); <Div />; <del> expect(console.error.calls.length).toBe(2); </del> <ins> expect(console.error.calls.length).toBe(4); </ins> }); it('should check default prop values', function() {

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

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


Question: styleProp.hasOwnProperty('display') ? styleProp.display : null; <del> // $FlowFixMe Setting a style property to null is the valid way to reset it. instance.style.display = display; </del> <ins> instance.style.display = dangerousStyleValue('display', display); </ins> } export function unhideTextInstance(

Do you want to request a feature or report a bug? Bug What is the current behavior? Suspense adds display: none to all top level child elements in IE11. 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: Code sandbox can't render in IE11 either, but in this example I would expect to not see IE11 because the div would have display: none on it. What is the expected behavior? To be visible and not have display: none on the children. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I had to revert back to react-loadable to fix this.
Is it IE11 specific or a general bug? There’s a few general bugs we’re tracking right now.
IE specific, it worked on Chrome/Safari, but in IE11 the display: none; was left on all the child components. I was able to go and check that style off in the inspector and see the components were loaded just fine.
If I take your CodeSandbox, add react-app-polyfill/ie9 and edit the to compile for IE11 support: – then download that, build it locally, and deploy to at https://build-, then I get a page that successfully displays "hello world" when opened in IE11. !
Can you confirm if I'm doing anything different from what you tested?
Hmm I was hoping it would be as simple as that. But I guess it is more complicated. I'm using it with the router for lazyloading router components. Here is my file that was working everywhere except for IE.
Oh, I think I found the bug.
I love GitHub issues/prs. I can easily track the problem, what caused it, and how to fix it! I was looking for a fix and had one! Thank you!
any ideas when this fix might make it into a release?
PS: We love the work you do for us all!
Any updates to this?
can be fixed with polyfills. It´s described in this pull request
Thanks everyone for this.

The issue itself has been fixed (I think in 16.7).
I'm noticing this problem with react version Suspense/fallback adds a style and this doesn't get removed on IE 11. Works fine on Chrome though.


Question:
expect(handler).toHaveBeenCalledWith(jasmine.objectContaining({target: node})); });  it('should throw when attempting to use ReactTestUtils.Simulate with shallow rendering', function() { var SomeComponent = React.createClass({ render: function() { return (
 hello, world.
 ); }, }); var handler = jasmine.createSpy('spy'); var shallowRenderer = ReactTestUtils.createRenderer(); shallowRenderer.render(<SomeComponent handleClick={handler} />); var result = shallowRenderer.getRenderOutput(); expect(() => ReactTestUtils.Simulate.click(result)).toThrow( 'TestUtils.Simulate expects a component instance and not a ReactElement.' + 'TestUtils.Simulate will not work if you are using shallow rendering.' ); expect(handler).not.toHaveBeenCalled(); });  it('can scry with stateless components involved', function() { var Stateless = () =>

; var SomeComponent = React.createClass({

I'm doing a simple shallow render on a component which has a button () with an handler. I can correctly assert most of its properties, but I can't get asserting whether the button has been clicked (by using and a passed in as handler) to work. TestUtils doesn't throw any Invariant Violation or whatever other error, the spy just never gets called. When I manually call it through it works. Is this expected behavior?
I'm not up to date with what the interaction is supposed to be with the shallow renderer these days so cc … But when you use the shallow renderer you aren't working on a real rendered tree. especially doesn't look like it should work - remember that props are not rendered output. will be a React Element, not a component instance. So as your test case seems to be written, yes this is expected.
That's expected. We should probably give a better error message – changing this issue title to reflect that.
Is there anything I can do to help with this? I haven't contributed to React yet, but we're investing heavily into in-company knowledge. If you can point me to where to assert this, I'd love to help.
Also, where do I submit PR's for React's website? I could clarify this in the documentation...
The docs/ directory has markdown files that turn into the website. Each page should also have an "Edit on GitHub" button at the top that links you straight to it. In the file, you could add an invariant that makes sure React.isValidElement returns false on the passed-in node.


Question: var cloneWithProps = require('cloneWithProps'); var shallowCompare = require('shallowCompare'); var update = require('update'); <ins> var warning = require('warning'); var warnedAboutBatchedUpdates = false; </ins> React.addons = { CSSTransitionGroup: ReactCSSTransitionGroup,

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