Question: untrackFibersSet.add(fiber); <ins> // React may detach alternate pointers during unmount; // Since our untracking code is async, we should explicily track the pending alternate here as well. const alternate = fiber.alternate; if (alternate !== null) { untrackFibersSet.add(alternate); } </ins> if (untrackFibersTimeoutID === null) { untrackFibersTimeoutID = setTimeout(untrackFibers, 1000); }

! There's seems to be circumstances where unmounted DOM/Fibers are kept alive by React DevTools. They're kept alive in : It seems like a WeakSet would be appropriate and would remove the leak. Otherwise we'd need to understand why recordUnmount isn't called. CC
I'm not necessarily convinced that the above screenshot is showing what this issue suggests. I believe it's possible that this indicates that component rendered where it previously rendered a DOM element, and the "alternate" Fiber still has a reference to the (now unmounted) DOM element. In this case both DevTools and React itself would have references to both Fibers as well as the unmounted DOM element. We do clear pointers for both "current" and "alternate" in but this does not include the property: The retain behavior I describe above can be verified with the following example app code: I'm not sure I would call this a "leak", since the retained DOM elements would go away once the leaf Fiber itself went away, but it could at least exhibit the behavior your Memory profile shows in the picture above. If one was to argue this was a leak, then I believe it would be considered a React leak rather than a DevTools leak. Edit I think we also leak Fibers in this way, since the may have a reference to its previous children - which themselves have references to their Fibers via the "__reactInternalInstance" field.
Quick update about this issue and PR The thing that caused the above temporarily "leak" is the alternate pointer- which will be cleared during the next render. That being said, the reason the temporary "leak" retains so much (the whole subtree) is because we weren't nulling out the field. PR changes this behavior so that we now will null that field. This should make our memory snapshot comparisons less noisy in the future. In other words, hopefully this will show that DevTools isn't actually leaking DOM nodes (and Fibers) but if it is at least we should be able to identify them less ambiguously now.
Looks like there is a memory leak in DevTools, was noticed in Created small demo, it can be observer while scrolling a list, memory increase because of detached fiber and dom elements It happens also in production build, noticed that elements aren't removed from after they are unmounted, something fishy there
Thanks for sharing a repro, I'll take a look.

It does look like DevTools isn't recording unmounts for list-item Fibers in this repro, which causes it to retain them after they've been unmounted. This might have been a bad lead here. I think the reason I'm initially not seeing calls to commit unmount are because grows a pool of items initially. Still digging. It's definitely the list items that are leaking though. Just not sure why yet. Update I'm not convinced this is the entire problem, but it does seem like DevTools isn't properly cleaning out all of the alternate entries in the Map. I think this is because the is being cleared out synchronously by React when a Fiber gets unmounted (as part of our memory cleanup flag) but DevTools is asynchronously processing the untracking in order to support fast Refresh: The previous update is the problem. I think I have a fix. Will be pushing shortly.
Also as side note, i would expect to see similar behaviour in react-window, as in windowing nature there is lot of mounting/unmounting, only difference to react-virtual is, that it's hook based and react-window on classes.
This fix will go out with the next DevTools release.
Thanks


Question: > > [Sortable jQuery Plugin Integration](https://groups.google.com/forum/#!topic/reactjs/mHfBGI3Qwz4) > <del> > * [JSFiddle](https://jsfiddle.net/LQxy7/): Your React component simply render empty divs, and then in componentDidMount() you call React.renderComponent() on each of those divs to set up a new root React tree. Be sure to explicitly unmountAndReleaseReactRootNode() for each component in componentWillUnmount(). </del> <ins> > * [JSFiddle](http://jsfiddle.net/LQxy7/): Your React component simply render empty divs, and then in componentDidMount() you call React.renderComponent() on each of those divs to set up a new root React tree. Be sure to explicitly unmountAndReleaseReactRootNode() for each component in componentWillUnmount(). </ins> ## Introduction to React Screencast

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


Question: 'jsx:normal', 'npm-react:release', ]); <del> grunt.registerTask('build:gem-react-source', [ 'build', 'gem-react-source:release', ]); </del> grunt.registerTask('webdriver-phantomjs', require('./grunt/tasks/webdriver-phantomjs'));

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


Question: var source = null; if (config != null) { <del> ref = config.ref === undefined ? null : config.ref; key = config.key === undefined ? null : '' + config.key; </del> <ins> if (__DEV__) { ref = !config.hasOwnProperty('ref') || Object.getOwnPropertyDescriptor(config, 'ref').get ? null : config.ref; key = !config.hasOwnProperty('key') || Object.getOwnPropertyDescriptor(config, 'key').get ? null : '' + config.key; } else { ref = config.ref === undefined ? null : config.ref; key = config.key === undefined ? null : '' + config.key; } </ins> self = config.__self === undefined ? null : config.__self; source = config.__source === undefined ? null : config.__source; // Remaining properties are added to a new props object

The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.


Question: }, MemberExpression: 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: ## IRC Many developers and users idle on Freenode.net's IRC network in **[#reactjs on freenode](irc://chat.freenode.net/reactjs)**.  ## Twitter [**#reactjs** hash tag on Twitter](https://twitter.com/search?q=%23reactjs) is used to keep up with the latest React news.

The shows:  Sometimes we will make a typo mistake,e.g., enter not , not ,and then the result are the same with the pic above.This will make us very confused. And sometimes will spend us 2 or more minutes to find the typo,because at first we will check the code when we first see the error,"oh,god,I don't use ,why the error says it should be a func?",and then check it again and again,and finally find that it's just a typo and react will treat the as a to check. I think this is not very friendly and the doc does not mention.Maybe it could be improved?
If it's really not what React intended, can I work on this to throw a relevant warning?
I think it's clear enough. It shows on console that the property type is invalid, so you start from there. The prop type can be any function, from PropTypes object or not.
You are right.But the point is that if you don't know react will treat the undefined as a func to check,then you will be very confused,it maybe will spend your a lot of time to figure it out especially for new people.And the doc doesn't mention this. So I agree that if you already know this,it will be easy to realize what the error means.But for new people,it's not very friendly.
PropTypes have been removed from React core and now exist as a separate package . Any future feature requests, bug reports, or changes should be directed to the new repo at
in python we have somthing called deprecation warning ¬¬
in python we have somthing called deprecation warning ¬¬ So do we, and PropTypes have been warning since April. And there's automated codemod that will change the code for you (it's in the link).


Question: ); } }); <ins> PagePopUpContent = React.createFactory(PagePopUpContent); </ins> // Render application. React.render(App(null), document.getElementById('content'));

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


Question: chrome.devtools.inspectedWindow.eval( `window.postMessage({ source: 'react-devtools-inject-backend', <del> extensionId: "${CURRENT_EXTENSION_ID}" </del> <ins> extensionId: "${CURRENT_EXTENSION_ID}", </ins> }, '*');`, function(response, evalError) { if (evalError) {

a website that uses React. an element that uses Hooks. to load hook names. hook names always fails: !
Fix landed in , it should be a few days before it can be published to the Chrome Web Store, since it needs to go through the review process.


Question: ); Object.defineProperty(activeElement, 'value', newValueProp); <del> activeElement.attachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.attachEvent) { activeElement.attachEvent('onpropertychange', handlePropertyChange); } else { activeElement.addEventListener('propertychange', handlePropertyChange, false); } </ins> } /** <del> * (For old IE.) Removes the event listeners from the currently-tracked element, </del> <ins> * (For IE <=11) Removes the event listeners from the currently-tracked element, </ins> * if any exists. */ function stopWatchingForValueChange() {

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

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


Question: } scripts.forEach(function(script, i) { <del> var options; </del> <ins> var options = { sourceMap: true }; </ins> if (/;harmony=true(;|$)/.test(script.type)) { <del> options = { harmony: true }; </del> <ins> options.harmony = true </ins> } // script.async is always true for non-javascript script tags

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:
 import TestCase from '../../TestCase'; const React = window.React; const ReactDOM = window.ReactDOM; const MouseEnter = () => { const containerRef = React.useRef(); React.useEffect(function() { const hostEl = containerRef.current; ReactDOM.render(<MouseEnterDetect />, hostEl, () => { ReactDOM.render(<MouseEnterDetect />, hostEl.childNodes[1]); }); }, []); return ( <TestCase title="Mouse Enter" description="" affectedBrowsers="Chrome, Safari, Firefox"> <TestCase.Steps>
Mouse enter the boxes below, from different borders
 </TestCase.Steps> <TestCase.ExpectedResult> Mouse enter call count should equal to 1;
 Issue{' '}  #16763 {' '} should not happen.
 </TestCase.ExpectedResult>
 </TestCase> ); }; const MouseEnterDetect = () => { const [log, setLog] = React.useState({}); const firstEl = React.useRef(); const siblingEl = React.useRef(); const onMouseEnter = e => { const timeStamp = e.timeStamp; setLog(log => { const callCount = 1 + (log.timeStamp === timeStamp ? log.callCount : 0); return { timeStamp, callCount, }; }); }; return ( <React.Fragment>
 Mouse enter call count: {log.callCount || ''}

 </React.Fragment> ); }; export default MouseEnter;

Do you want to request a feature or report a bug? I want to report a bug. What is the current behavior? Event handlers on elements are fired twice, when hovering from one element onto the next. 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? Event handlers should only fire once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.8.4 ReactDOM 16.8.4 Chrome 76.0.3809.132 Firefox 69.0 (64-Bit) Edge 44..267.0
After testing it again and again, I found how to reproduce it: Step 1, render a new component inside a rendered component; Step 2, inside the new component, mouse enter a node from its sibling. Current result: onMouseEnter is called more than once. Demo: We may change the issue title because it's not related with . I've made a test and fixture for this: Hope the information can be helpful. I still have no idea how to fix it. If there's no one working on this, I would like to pick this up. There's a similar issue Do you have any advice?
Go for it,
Let's close this? I see the fix was merged in .


Question: </a> </div> <del> ## Hello, world! </del> In the root directory of the starter kit, create a `helloworld.html` with the following contents. ```html

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.

We need to host a standalone React component (DraftJS editor) inside a HTML5 application which will run on other JS framework, or even plain JS or jQuery. The code of the application is beyond our control, we are just a vendor of a component which adds some content, part of which is this React-based editor. Anyway, the most important part is that we need to add the component with the following code to an existing DIV. EditorComponent is a regular React component with some onClick events attached to its content (primarily toolbar buttons for the editor). I learned that React event model and its bubbling executes independently after the event bubbles all the way up to the document, and that if ev.stopPropagation() is called on native event, React events won't execute at all. That is understandable for situations where document contains only the React app / component at its root and no other content, meaning you have control over all events on the page from React code. However, when React component is just a small fraction of the entire page, it may be severely influenced by the rest of the page. The problem is that any event handling code above the component which calls ev.stopPropagation() cuts of the events of that smaller fraction, even that the event originated from the React component scope. That influencing code could very well be just some jQuery plugin, so even author of the page may not be able to rewrite their code for some special event handling. Here is a fiddle to demonstrate that: I believe that the point where the event chain breaks, allowing React to execute its events, should be the root element of React component, rather than the whole document. This way, React root element could be considered an isolation edge of the React application / component. ! I tracked the React event registration down to function ReactDOMComponent.ensureListeningTo(...) where I found the following code: I tried to change to to register the React event chain to the root of the React container, and tried it for several basic events (onClick, onMouseDown/Up) and it seems working for us as expected. React events are not influenced by stopping propagation at the native events outside of React component root, so the two differently implemented parts of the application can coexist in peace. I am not sure why ownerDocument was chosen over node in the implementation and if changing it to _node could break something important.

Please advise if the proposed solution seems viable (in that case consider a change to that), or for what reasons you wouldn't recommend it.
thanks for the well thought out and detailed issue! This is something that's been requested a number of times in the past, see is an open PR that implements essentially the same solution that you've proposed, you can read the comments there for some context on why this hasn't been done yet.
Thank you! I couldn't find them, probably because I was searching by problem keywords, not solution keywords :-) I willl observe them. If I understand it correctly, if we use only some basic events e.g. onClick in our small React components, and support latest enough versions of browsers, the temporary fix should be pretty safe. Or is there some set of DOM events that React listens to that are attached automatically regardless of whether we register them or not?
I’ll close as a duplicate of
We're changing this in React 17 to attach to roots.
If you want to try it, we released 17 RC yesterday with this change:


Question:
expect(reportedErrors).toEqual([]); });  it('should close the stream upon completion when rendering to W3C streams', async () => { const {Suspense} = React; // Model function Text({children}) { return children; } const [Friends, resolveFriends] = makeDelayedText(Text); const [Name, resolveName] = makeDelayedText(Text); const [Posts, resolvePosts] = makeDelayedText(Text); const [Photos, resolvePhotos] = makeDelayedText(Text); // View function ProfileDetails({avatar}) { return (
 <Name>:name:</Name> {avatar}
 ); } function ProfileSidebar({friends}) { return (
 <Photos>:photos:</Photos> {friends}
 ); } function ProfilePosts({posts}) { return
{posts}
; } function ProfileContent() { return ( <Suspense fallback="(loading everything)"> <ProfileDetails avatar={<Text>:avatar:</Text>} /> <Suspense fallback={
(loading sidebar)
}> <ProfileSidebar friends={<Friends>:friends:</Friends>} /> </Suspense> <Suspense fallback={
(loading posts)
}> <ProfilePosts posts={<Posts>:posts:</Posts>} /> </Suspense> </Suspense> ); } const model = { rootContent: <ProfileContent />, }; const stream = ReactServerDOMWriter.renderToReadableStream( model, webpackMap, ); const reader = stream.getReader(); const decoder = new TextDecoder(); let flightResponse = ''; let isDone = false; reader.read().then(function progress({done, value}) { if (done) { isDone = true; return; } flightResponse += decoder.decode(value); return reader.read().then(progress); }); // Advance time enough to trigger a nested fallback. jest.advanceTimersByTime(500); await act(async () => {}); expect(flightResponse).toContain('(loading everything)'); expect(flightResponse).toContain('(loading sidebar)'); expect(flightResponse).toContain('(loading posts)'); expect(flightResponse).not.toContain(':friends:'); expect(flightResponse).not.toContain(':name:'); await act(async () => { resolveFriends(); }); expect(flightResponse).toContain(':friends:'); await act(async () => { resolveName(); }); expect(flightResponse).toContain(':name:'); await act(async () => { resolvePhotos(); }); expect(flightResponse).toContain(':photos:'); await act(async () => { resolvePosts(); }); expect(flightResponse).toContain(':posts:'); // Final pending chunk is written; stream should be closed. expect(isDone).toBeTruthy(); });  });

When using for e.g. Cloudflare Workers runtimes, I'm noticing this error on the server: I'm assuming this results in the following malformed chunk being sent to the stream: Which results in the client failing: I put together a reproduction here, powered by for the Workers runtime: Could this be related to the "fundamentally flawed" nature of Web Streams implementations in e.g. Cloudflare Workers runtime? Is something going on with corking/uncorking, as per Maybe something's wrong with Miniflare's polyfill and this is a non-issue, coming from ? Finally, it's possible something is wrong with the Vite version of the example I've put together. I could try rebuilding with webpack if it's determined none of these items apply.
Have you looked at what chain of assumptions leads to this? It seems like it would be good to understand what different state machines are involved and why something's happening in CF that doesn't happen in the browser.
Have you looked at what chain of assumptions leads to this? after lots of digging, here's what we've discovered: The difference between Cloudflare/Oxygen Workers runtimes and the browser comes down to how the is consumed after being passed to . In the browser and , this is how the stream (via ) is consumed: This presumably results in a single . In the worker runtime, is read through an : Importantly, this results in getting called multiple times as more data is enqueued and as the reader sees fit. This is an assumption on my part, so I could be wrong here. When combined with Suspense boundaries, callbacks trigger . At the same time, repeated requests from the stream reader also call . This results in the following error on the server: You can also reproduce this directly in the browser by attempting to read the stream with . Here is a new fixture with a reproduction of the issue, including a couple test cases that show the different errors you'll see based on the number of Suspense boundaries you have: If this seems like a legitimate bug to you, a couple ideas I had: Should there be some sort of check like in ? Should we splice completed boundaries earlier to account for concurrency so they are removed from the array and not re-flushed? Here are some other resources and scratch notes:
~We'll fix this reentrancy bug somehow.

However, right now it's a bit lower priority because CloudFlare technically don't support ReadableStreams and so you have to go through the polyfill and any subtle differences might be due to the polyfill. To really know if we fixed this issue we should apply this to native CloudFlare ReadableStreams... which I'm told is coming. So that's how we know if it actually worked. Until then, the support for CloudFlare workers is... partial.~ On a second thought this should probably fix it. I think I finally understand how it's supposed to work now.
Please take another look and see if this fixes all the issues you've noticed.
works like a charm! Thanks for taking the time to look at it and get it fixed


Question: <ins> ## Input ```javascript function Component(props) { let value; const object = { set value(v) { value = v; }, }; object.value = props.value; return <div>{value}</div>; } export const FIXTURE_ENTRYPOINT = { fn: foo, params: [{ value: 0 }], sequentialRenders: [{ value: 1 }, { value: 2 }], }; ``` ## Error ``` 2 |   let value; 3 |   const object = { > 4 |     set value(v) { |     ^^^^^^^^^^^^^^ > 5 |       value = v; | ^^^^^^^^^^^^^^^^ > 6 |     }, | ^^^^^^ Todo: (BuildHIR::lowerExpression) Handle set functions in ObjectExpression (4:6) 7 |   }; 8 |   object.value = props.value; 9 |   return <div>{value}</div>; ``` </ins>  No newline at end of file

[ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization) [X] babel-plugin-react-compiler (build issue installing or using the Babel plugin) [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin) [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script) In the above code, doubleValue uses get syntax, and after compilation, it loses the keyword and becomes an ordinary function. In this case the compiler should skip compilation until this syntax is supported. I know that some syntaxes are currently unsupported by the react compiler, can we know what syntaxes are currently unsupported and in process? Every time 0-rc--
Thanks for posting, this is a bug. We have not support for get/set syntax but looks like we missed a todo for this.
Let’s close when the associated PR lands
Oops my bad, I didn't read


Question: 'use strict'; var ReactBrowserComponentMixin = require('ReactBrowserComponentMixin'); <ins> var ReactChildren = require('ReactChildren'); </ins> var ReactClass = require('ReactClass'); var ReactDOMSelect = require('ReactDOMSelect'); var ReactElement = require('ReactElement');

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


Question: internalInstance._currentElement ); } <del> transaction.getReactMountReady().enqueue(attachRefs, internalInstance); </del> <ins> if (internalInstance._currentElement.ref != null) { transaction.getReactMountReady().enqueue(attachRefs, internalInstance); } </ins> return markup; },

We currently use the transaction queue too much and build up a giant array on mount. Here's one simple example of where we add things to the queue unnecessarily:
I don't know of anything else easy here.


Question: .HookName { color: var(--color-component-name); <ins> } .ToggleError { color: var(--color-error-text); </ins> }  No newline at end of file

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


Question: var value = LinkedValueUtils.getValue(props); if (value != null) { <del> updateOptions(this, props, value); </del> <ins> updateOptions(this, Boolean(props.multiple), value); </ins> } } }

Case: ,js,output I have a with a value depending on the state. When I select the 'baz' item in the combobox, and don't do anything in the onChange handler, the combobox suddenly displays the first element (even though the state is still the same). So, the state of the combobox is inconsistent with the state of its 'value' property. This seems to happen in at least Chrome and Safari.


Question: grunt.registerTask('coverage:parse', require('./grunt/tasks/coverage-parse')); <del> grunt.registerTask('test:eslint-rules', require('./grunt/tasks/test-eslint-rules')); </del> grunt.registerTask('test:webdriver:phantomjs', [ 'connect', 'webdriver-phantomjs',

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


Question: <del> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule ReactRAFBatchingStrategy * @typechecks static-only */ /* global requestAnimationFrame:true */ 'use strict'; var ExecutionEnvironment = require('ExecutionEnvironment'); var ReactUpdates = require('ReactUpdates'); var requestAnimationFrame = require('requestAnimationFrame'); function tick() { ReactUpdates.flushBatchedUpdates(); requestAnimationFrame(tick); } var ReactRAFBatchingStrategy = { isBatchingUpdates: true, /** * Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ batchedUpdates: function(callback, a, b, c, d) { callback(a, b, c, d); } }; if (ExecutionEnvironment.canUseDOM) { requestAnimationFrame(tick); } module.exports = ReactRAFBatchingStrategy; </del>

I didn't realise this was in the addons bundle, would be good to get it to the docs. Would be good to also include an example of using or something similar.
rAF batching isn't supported and won't go in the docs, but batchedUpdates should.
is rAF batching discouraged, or just not suitable for shipping with core? Would it be reasonable to link to an up-to-date npm project on the batchedUpdates page?
We don't use it at Facebook and it's not clear that it solves real problems, so we don't want to maintain it or have to fix bugs related to it. should give enough control over batching.
There are also known issues with rAF batching (mostly around controlled components).
Should we deprecate and eventually remove the RAF batching?
It's never been supported in any fashion.
(i.e., it's already deprecated?)
shouldn't this file be deleted in that case?
That's not exposed as a public API in any of our builds, but sure, we can delete it – PR incoming.
Killed in
We should document ReactDOM.unstable_batchedUpdates.
Since when did we start documenting features? Haven't we always left them intentionally undocumented? We also have unstablerenderSubtree and unstable_handleError and others, but I thought the decision was to not document them until they become stable. We document them as part of the release process. It was a different situation when it was an addon, the issue made sense at that time.
Sure.


Question: expect(data.commitData).toHaveLength(1); expect(data.operations).toHaveLength(1); }); <ins> it('should not throw while initializing context values for Fibers within a not-yet-mounted subtree', () => { const promise = new Promise(resolve => {}); const SuspendingView = () => { throw promise; }; const App = () => { return ( <React.Suspense fallback="Fallback"> <SuspendingView /> </React.Suspense> ); }; const container = document.createElement('div'); utils.act(() => legacyRender(<App />, container)); utils.act(() => store.profilerStore.startProfiling()); }); </ins> });

not public I have two code bases in a yarn workspaces linked monorepo. One is using react-three-fiber (the lib), and the other one is really thin wrapper around it with some simple UI, just couple of buttons. Both are using multiple (3) zustand stores. Every time react-devtools-extensions 21.0- Could not find ID for Fiber "App"
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or 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:
I have experienced the same issue in Firefox, also with the use of react-three-fiber and zustand. If it helps isolate the issue, I only experience it for development builds but do not experience it for production builds. Repository: Browser: Firefox 95.0.2 (64-bit), Windows 10 Sample video: https://user- The error message in the pane:
Thanks for the repro,
I, too, have had this issue and spent a bit of time reducing the surface area to a really small combo of react + canvas. Hopefully, this breaks in a way that is helpful. DevTools version Error message Error call stack Error component stack GitHub query string !
Possibly fixed by . Possible requires an additional change made to this method to replace with (and we can just skip Fibers with a null ID).
Repro from by repo repo in your browser of choice. to the dev tools, and you should see the error
Fix released on Jan 24 as version 4.23.0: Give it a couple of days to propagate to all of the browsers. (Chrome usually takes the longest.)


Question: ), ]; break; <ins> case 'input': case 'select': case 'textarea': inst._wrapperState.listeners = [ ReactBrowserEventEmitter.trapBubbledEvent( EventConstants.topLevelTypes.topInvalid, 'invalid', node ), ]; break; </ins> } }

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


Question: "README.md", "main.js", "bin/jsx", <del> "build/React.js", </del> <ins> "build/react.js", </ins> "vendor/fbtransform/", "vendor/woodchipper.js" ],

I'm trying to programatically invoke the JSX transformer (using the version of in the npm registry) by running something like Which then throws this error: If I comment out the lines in that require/use the module loads fine and the transformer runs correctly.
Bah, I changed build filenames last minute and didn't properly test the module after :( Thanks for finding this! I guess we should write some tests for the node module too, not just our phantomjs tests. (Very) Short term, you should be able to change to and that will fix the problem. - I guess it's time to figure out what we want to do with npm versions vs library versions. Should we just bump them both for the time being?
Nope, that alone won't do it, we're not even packaging. I totally screwed up the node module :( Fix soon!
Yeah, doesn't look like there's even a directory there. :)


Question: ]); }); <ins> it('should chain functions regardless of spec property order', function() { var listener = mocks.getMockFunction(); var instance = <TestComponentWithReverseSpec listener={listener} />; instance = ReactTestUtils.renderIntoDocument(instance); expect(listener.mock.calls).toEqual([ ['MixinA didMount'], ['MixinBWithReverseSpec didMount'], ['MixinC didMount'], ['Component didMount'] ]); }); </ins> it('should validate prop types via mixins', function() { expect(TestComponent.type.propTypes).toBeDefined(); expect(TestComponent.type.propTypes.value)

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


Question: // register renderers that have already injected themselves. hook.renderers.forEach(renderer => { <del> registerRenderer(renderer); </del> <ins> registerRenderer(renderer, hook); </ins> }); // Activate and remove from required all present backends, registered within the hook

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


Question: // Compute `paths` and cache it. Guarding against cycles. cache.set(segment.id, null); <del> if (segment.prevSegments.length === 0) { </del> <ins> if (codePath.thrownSegments.includes(segment)) { paths = 0; } else if (segment.prevSegments.length === 0) { </ins> paths = 1; } else { paths = 0;

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


Question: if (!backend) { throw new Error(`Could not find backend for version "${version}"`); } const {Agent, Bridge, initBackend, setupNativeStyleEditor} = backend; const bridge = new Bridge({ listen(fn) {

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


Question: var DOMProperty = require('DOMProperty'); var DOMPropertyOperations = require('DOMPropertyOperations'); var ReactBrowserEventEmitter = require('ReactBrowserEventEmitter'); <ins> var ReactComponentBrowserEnvironment = require('ReactComponentBrowserEnvironment'); </ins> var ReactMount = require('ReactMount'); var ReactMultiChild = require('ReactMultiChild'); var ReactPerf = require('ReactPerf');

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


Question: PluginModule.willDeleteListener(inst, registrationName); } <del> delete listenerBank[registrationName][inst._rootNodeID]; </del> <ins> delete listenerBank[registrationName][key]; </ins> } },

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: // Check that the version we're exporting is the same one we expect in the // package. This is not an ideal way to do this, but makes sure that we keep // them in sync. <del> var reactVersionExp = /bReact.versions*=s*['"]([^'"]+)['"];/; </del> <ins> var reactVersionExp = /bREACT_VERSIONs*=s*['"]([^'"]+)['"];/; </ins> module.exports = function() { var reactVersion = reactVersionExp.exec(

People lose hours of work debugging a simple issue: two versions of React being loaded at the same time. Because there is no warning right away when this happens, they usually discover the problem through invariant violations. Some of them are descriptive (e.g. ) and I think I even saw warning that said something like "check if two copies of React are loaded", but some are really cryptic: . Is there a reason why we don't want to warn right away when two copies of React are loaded?
There's probably no good way to find out if two copies of React are loaded (CommonJS modules are the antithesis of sharing a global scope, they're literally two duplicate but separate modules). But I would expect React to be clever enough to figure out that, say, a component is a React component even if it's not from the same copy of React.
I think it's lesser evil to put some flag on , like , than to spend any more time on this.
Should be preferable to just extend (or w/e) with simple duck-typing that warns if it looks like a ReactElement but isn't... or something like that. It's free and doesn't interfere with intentionally running multiple React instances.
I think that in the future, this will actually just work. In the meantime we can warn here:
Would it catch all of the issues listed above though? Usually the problem comes up when some component or helper library loads its own version. Will we get to in this case? Besides, does React truly support independent Reacts on page right now? Do they not interfere in any way at all if they aren't mixed (e.g. browser event handling)?
(To clarify, I was referring to comment)
I might be mistaken, but ignoring weird hacks then the only issue with multiple instances of React are when ReactElements from different instances gets mixed up. Depending on which API you feed them to, you're going to see lots of different errors though. So yeah... I think that should take care of all, or most at the very least. As long as you never stop event propagation or mount them inside each other it should be OK I think (but still not great though). Good point.
Just a confirmation from someone who just flushed 3 hours of debugging time down the toilet that, yes, this issue is hard to debug, please make at least a warning.

In my case I was having a weird exception (TypeError: Cannot read property 'firstChild' of undefined) caused by the fact that a component created with a different (uninitialised) copy of React was carrying a _owner = null, thereby breaking findComponentRoot().
We should already be warning in the case that an element from one copy of React is passed to in another: I guess the cases here are when nesting elements from different versions inside each other?
Yes. At least it was in my case. Nested elements created from different React versions.
Just my 2cents: I had the same issue today and my problem was using browserify 8.1.3 instead of 8.1.1 Hope it helps
The other issue with this is you can't reliably use the dependency injection mechanism, e.g. to change the batching strategy, while using components from multiple modules where each has it's own instance of React as a dependency. Even if they are the same version of React.
+1 ; thanks gaearon
said: "The other issue with this is you can't reliably use the dependency injection mechanism, e.g. to change the batching strategy, while using components from multiple modules where each has it's own instance of React as a dependency. Even if they are the same version of React." This.
The main workaround many modular React components are using is to specify React as a -- the parent module must provide React to prevent multiple copies. This is problematic because are on track to because they introduce .
I've seen this a lot as well, and had lots of requests to switch React to a (+) in my packages which I'm currently resisting for reasons mentioned. The most common frustration I've seen is when npm subtly installs two versions of React, and Browserify (correctly) includes both in the build. It can happen unexpectedly w/ package updates and breakage ensues. A warning from React that "hey, there is more than one of me on the page" seems like the most elegant way to warn developers early and direct them to an explanation of what's gone wrong / how to fix it. It's a side-effect of npm's dependency rules and node's behaviour that I end up with two Reacts when I just want one.

Looks like things will get better with (see npm/npm) but in the meantime I agree with about adding a "lesser evil" hack: ... there's a good argument to be made that this isn't React's problem to solve, but since it's a common problem and React can solve it, I think it would be great if it did.
A solution I found with was to alias all calls like so (example shown with grunt): so it isn't impossible to fix, but I'd make the argument that since this is such a common issue it needs to be highlighted more clearly in the React docs.
when using browserify it can happen just when requiring two different versions of React because of the way it handles deduplication. Requires with the same path and code between the two versions can end up getting de-duped. Modules where the code/require path was changed between versions get deduplicated and others don't. So I encountered this: (from React v1) is evaluated and it mixes in ReactBrowserComponentMixin as part of its spec .Class.injectMixin(ReactBrowserComponentMixin) is evaluated and it adds ReactBrowserComponentMixin to all classes subsequently created by ReactClass.createClass (shared between React v1 and v2 because it didn't change between the two versions of React) (from React v2) is evaluated and it tries to mix in ReactBrowserComponentMixin twice, once from ReactDOMSelect's own spec and once from the global injected mixin list. As long as modules can be stateful, this approach to deduplication seems horrifically unsafe. I'll file an issue with Browserify itself, I haven't yet verified if Webpack would have the same issue. Either way - I think it would make sense to handle it specifically in React given how it can trip newcomers up.
Reverting for now (in ) as we sort out some problems.
THANK YOU for this discussion. I was battling with an Invariant Violation bug for half the day yesterday and then came across this ticket this morning. My setup was using a browserify-shimmed version of React and react-router loaded from CDN. After reading this discussion I just opted to use the npm versions of these libs and the error went away. This is my first React project so debugging this problem was a pretty big headache. Thanks again for this discussion as it lead me to figure out the problem and move forward.

Leaving details of my case for future searchers: I got the error "Invariant Violation: Could not find the drag and drop manager in the context of Card. Make sure to wrap the top-level component of your app with configureDragDropContext" Also turned out I had two React versions loaded. The problem was Webpack. I was using "npm link <folder" for one of my packages, which also depends on React. Seems webpack has problems handling symbolic links, or it's my fault configuring it improperly. Anyway, the problem was fixed by installing the package into my local node_modules directory.
Thanks for this, I'm gonna add it to the relevant explanation gist for React DnD.
Would like to have this too. Haven't figured out a way to get GitHub cc'd (rather than bcc'd) without explicitly participating, sorry for the noise.
There's a button :)
I think that still doesn't CC you but only BCC, sadly. Moreover, I'm watching the repo already, but I have a different inbox for when GitHub CCs me.
Fyi: Ongoing PR
Fixed by , hopefully.
If it helps the next person googling, is yet another sign of this problem.
and counting... I've got this one: I'm looking everywhere for the sneaky react twin, but no luck. doesn't show any duplicates The other possibilities I've read about are double-loading the react script, webpack double-bundling, or react/addons causing trouble, so those are what I'm working on now. Insidious.
As you've hopefully set up correctly, then simply remove and reinstall everything, that usually fixes it unless there's some incorrectly configured module.
I tried to git clone the repo and reinstall, but that wasn't the issue. Eventually I noticed that the error was only happening after the first navigation (similar to this ) and started taking apart my navigation menu. Turns out that for some reason putting a from react-router inside a from react-boostrap was causing react to go nuts. I posted my findings on .
I think it also might have had something to do with my not using the generated from react-router as the root of my component hierarchy. I was wrapping it in a higher level-component that accepts my flux instance and passes it on as context.

Isolating the issue into gave me the following error:
The nested links thing is due to invalid HTML and we have a new warning for that in 0.14.
By the way I got that new warning a few days ago and it's beautiful, great work. :+1:
I'm getting this error: when using npm link to require a module I'm working on. I can't be 100% sure that it's caused by having multiple versions of React, but the error does go away when I just paste the npm module directly into my app instead of using it via npm link. I don't get this error when using my npm module the normal way (react is a dev dependency so I don't think it gets installed in node modules). Has anyone else run into this issue and come up with a fix? Thanks!
I got this error while running 0.14-rc1 and 0.14-beta3 together
Please do not report random problems in this issue. File new issues.
Seriously. This has taken me 3 days to figure out that my random error about unmounting the _mouseMoveTracker twice in fixed-data-table is caused by two reacts... This is not good that this bug seemingly can't be fixed? Why can React not just put the version number on the window object and never add itself again if it's there already? This is better than the hours and hours wasted by many people with this!
I thought we fixed this in 0.14 (); is it not displaying a warning?
Yep, I just upgraded to 0.14.2 everywhere (including inside the module) and somehow deleting react from nodemodules/react-datatable/nodemodules/ fixed my bug! (see here ). Maybe there is something wrong with my webpack config? It's weird that this fixed it. Is this having two of the identical version included a subtle variant on this bug?
Part of the problem is react-datatable having as a non-peer dependency (cc which can cause NPM to fetch a separate react installation for just that module.
Okay - thanks - I'll try adding this as a peer dep, however when I want to run the build for my module if developing the datatable from within my main project, what is the best way to accomplish this without issues?
you might try upgrading to , then .

has improvements in how it handles dependencies and is better about avoiding multiple instances of a given package, since it installs with a flat structure instead of nesting dependencies within packages. This, along with moving from to in a library I am writing, solved my similar problems.
Another 4 hours lost. My webpack config now is:
Can you say what symptom you experienced? Also, if you are using the prebuilt I would recommend using the prebuilt react- as well and using in your webpack config since the secret property is unstable and will change in the next version (hence its name).
yes, the problem was in prebuild version of React. The second instance of React came from require('react'). It did work somehow until React 0.14 migration. And even more: It work after partial code removal! This lead me to wrong way of long debugging. I agree, this is my fault. But I still expect something like: every time, instead of rare warning: after which I spent hours to find out whats wrong with my refs... It seems like it is very common problem, and it is have to be more detailed and have better documentation.
same issue with webpack and loading manually.
Is it still an issue to load more than one version of React on a page, even if those instances are managing totally separate DOM trees and aren't being explicitly instantiated as globals? Like if, say, I had a package with and as dependencies, and they both depended on different versions of React, with npm as the dependency manager, could they be used together on one page?
No, that should work now if both are on a recent version of React.
Could you please point me out what would be the behavior of React if , let say , we want to introduce a widget including React in a host page that has an older version of it and the possible workaround to make it work? Thanks
Old versions of React are probably only tripped up by data-reactid IDs in the DOM that it didn't generate. If you're doing only client-side rendering with your widget, it should only have a data-reactroot attribute and no data-reactid so there shouldn't be any conflict.
Just ran into problems again today when I accidentally had 16.4.2 and 16.5.0 installed in a project, no warning from React.

To make matters worse, the duplicate versions were caused by a bug in that ...
Was there any resolution as to whether or not this is possible and/or a good idea? It seems like it'd provide developers with useful information.
Project A uses React 16 wherein Project B uses React 15, Lets say Project A is package got used in Project B - can that work?
Would Preact and React have the same issue described here? I’m asking because I’m using single-spa for a platform play at a large company of distributed teams.
It sounds to me like there are two separate issues here: you have two different copies of the library loaded and in use anywhere on a page in separate components that don't interact with each other? you have components from two different bundles, each with their own copy of the library, interact with each other (eg. the function from one library receiving an element created with from the other library) I don't know about the status with modern versions of React. In the case of Preact (1) should be fine but since it does have some global state you could run into problems in situation (2). Please file an issue in the repository if you'd like to discuss further.
This appears to be a bad link.
For someone encountering this at the moment - does anyone have any tips on identifying the cause and debugging the issue? I've used the check from the hooks page (how I discovered this) which confirms I've got 2 instances loaded: I believe I'm doing things by the book, in a monorepo react, react-dom etc are all always . What steps would you recommend after this?


Question: var ReactEmptyComponentType = function() {}; ReactEmptyComponentType.prototype.componentDidMount = function() { var internalInstance = ReactInstanceMap.get(this); <ins> // TODO: Make sure we run these methods in the correct order, we shouldn't // need this check. We're going to assume if we're here it means we ran // componentWillUnmount already so there is no internal instance (it gets // removed as part of the unmounting process). if (!internalInstance) { return; } </ins> registerNullComponentID(internalInstance._rootNodeID); }; ReactEmptyComponentType.prototype.componentWillUnmount = function() { var internalInstance = ReactInstanceMap.get(this); <ins> // TODO: Get rid of this check. See TODO in componentDidMount. if (!internalInstance) { return; } </ins> deregisterNullComponentID(internalInstance._rootNodeID); }; ReactEmptyComponentType.prototype.render = function() {

tl;dr: If you have a component that returns and it rerenders, the noscript tag is unmounted and a new one is created because shouldUpdateReactComponent gets and and returns false. This came out of some internal components that were breaking after the most recent update. I haven't gone to see if this is more widely broken - it might have been before any of the recent updates, just that the empty component is triggering it reliably. I've been some reports of having similar weird problems that we couldn't track down. It's use of is very similar to what's happening in . The trigger here is that we're triggering an update during the mount phase. When we do this works correctly because it's before which is triggering to rerender. is the broken one because its hasn't been called yet. So we actually call its first. Then we still call its . There's also the whole question of why we're trying to unmount anything at all here. It seems like we shouldn't be doing that. cc Drop this into examples/basic-jsx-harmony and debug with pausing on caught exceptions. I some breakpoints in ReactEmptyComponent to make it super obvious.
Why it's unmounting: When comparing the old to the new in , is actually whereas is , so returns false.
Why it's throwing: the three componentDidMount calls get queued in the order they were rendered (Child 0's null, Child 1, Child 2's null), but because batching doesn't happen on an initial render (something I've been meaning to make happen…), the forceUpdate happens synchronously and causes the unmount/remount of both child components, after which the old enqueued Child 2 null did-mount callback runs and throws, because that component isn't mounted any more.
(Two issues; we should fix both.)
The first one is a new regression, right?
Not sure, but I think so. I a test recently to ensure that text components don't get remounted on update; we should add one for empty components too.
Initial render isn't asynchronous but to change it, I think we'd need to change the API to pass the instance to a callback instead of synchronously returning it. We should be able to queue up new updates during initial render though. So that they're guaranteed to happen after the queue as processed.

Right -- that's what we do already for new mounts of child components within a larger update.
The second issue should be fixed now because we batch on initial render. Not sure about the first; it's probably still a problem.
I just ran into this (I think) and made a JSFiddle for it
Maybe you can fix this.
Suggestion to use instead of so that it doesn't mess up s and s.


Question:
```javascript{3-5} render: function() { return (  <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}>   <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}>
Dissolvenza al Montaggio Iniziale
 </ReactCSSTransitionGroup> );

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: // Flush the immediate callbacks that were scheduled during this batch. // Note that this will happen even if batchedUpdates is higher up // the stack. <del> flushSyncCallbackQueue(); </del> <ins> if ((executionContext & (RenderContext | CommitContext)) === NoContext) { flushSyncCallbackQueue(); } else { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } } </ins> } }

flushSync early returns if it detects it's in the commit (or render) phase, since it can't synchronously flush when React is already working. However, it should still change the priority of updates scheduled by the callback to be synchronous. This mostly already works because the commit phase itself has a sync event priority context, but the passive effect phase doesn't. Need more tests for this.


Question: downloadUrl = URL.createObjectURL(blob); <del> const element = document.createElement('a'); </del> element.setAttribute('href', downloadUrl); element.setAttribute('download', filename); <del> element.style.display = 'none'; ((document.body: any): HTMLBodyElement).appendChild(element); </del> element.click(); <del> ((document.body: any): HTMLBodyElement).removeChild(element); </del> } export function truncateText(text: string, maxLength: number): string {

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


Question: }, /** <ins> * Setup this component to trap non-bubbling events locally * * @private * @param {ReactReconcileTransaction|ReactServerRenderingTransaction} transaction */ _setupTrapBubbledEventsLocal: function(transaction) { this._wrapperState = { listeners: null, }; transaction.getReactMountReady().enqueue(trapBubbledEventsLocal, this); }, /** </ins> * Creates markup for the open tag and all attributes. * * This method has side effects because events get registered.

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


Question: }); it('should keep both sets of DOM nodes around', function() { <del> var container = document.createElement('div'); </del> var a = React.renderComponent( <ReactTransitionGroup transitionName="yolo"> <span key="one" id="one" />

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


Question: } var markup = null; if (this._tag != null && isCustomComponent(this._tag, props)) { <del> if (propKey !== CHILDREN) { </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { </ins> markup = DOMPropertyOperations.createMarkupForCustomAttribute(propKey, propValue); } } else if (this._namespaceURI === DOMNamespaces.svg) { <del> markup = DOMPropertyOperations.createMarkupForSVGAttribute(propKey, propValue); </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { markup = DOMPropertyOperations.createMarkupForSVGAttribute(propKey, propValue); } </ins> } else { markup = DOMPropertyOperations.createMarkupForProperty(propKey, propValue); }

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


Question: } const shallowRenderer = createRenderer(); <del> expect(() => shallowRenderer.render(<Component />)).toWarnDev( 'Unsafe legacy lifecycles will not be called for components using the new getDerivedStateFromProps() API.', ); }); it('should warn about deprecated lifecycles (cWM/cWRP/cWU) if new static gDSFP is present', () => { let shallowRenderer; class AllLegacyLifecycles extends React.Component { state = {}; static getDerivedStateFromProps() { return null; } componentWillMount() {} UNSAFE_componentWillReceiveProps() {} componentWillUpdate() {} render() { return null; } } shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<AllLegacyLifecycles />)).toWarnDev( 'Unsafe legacy lifecycles will not be called for components using the new getDerivedStateFromProps() API.nn' + 'AllLegacyLifecycles uses getDerivedStateFromProps() but also contains the following legacy lifecycles:n' + '  componentWillMountn' + '  UNSAFE_componentWillReceivePropsn' + '  componentWillUpdatenn' + 'The above lifecycles should be removed. Learn more about this warning here:n' + 'https://fb.me/react-async-component-lifecycle-hooks', ); class WillMount extends React.Component { state = {}; static getDerivedStateFromProps() { return null; } UNSAFE_componentWillMount() {} render() { return null; } } shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<WillMount />)).toWarnDev( 'Unsafe legacy lifecycles will not be called for components using the new getDerivedStateFromProps() API.nn' + 'WillMount uses getDerivedStateFromProps() but also contains the following legacy lifecycles:n' + '  UNSAFE_componentWillMountnn' + 'The above lifecycles should be removed. Learn more about this warning here:n' + 'https://fb.me/react-async-component-lifecycle-hooks', ); class WillMountAndUpdate extends React.Component { state = {}; static getDerivedStateFromProps() { return null; } componentWillMount() {} UNSAFE_componentWillUpdate() {} render() { return null; } } shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<WillMountAndUpdate />)).toWarnDev( 'Unsafe legacy lifecycles will not be called for components using the new getDerivedStateFromProps() API.nn' + 'WillMountAndUpdate uses getDerivedStateFromProps() but also contains the following legacy lifecycles:n' + '  componentWillMountn' + '  UNSAFE_componentWillUpdatenn' + 'The above lifecycles should be removed. Learn more about this warning here:n' + 'https://fb.me/react-async-component-lifecycle-hooks', ); class WillReceiveProps extends React.Component { state = {}; static getDerivedStateFromProps() { return null; } componentWillReceiveProps() {} render() { return null; } } shallowRenderer = createRenderer(); expect(() => shallowRenderer.render(<WillReceiveProps />)).toWarnDev( 'Unsafe legacy lifecycles will not be called for components using the new getDerivedStateFromProps() API.nn' + 'WillReceiveProps uses getDerivedStateFromProps() but also contains the following legacy lifecycles:n' + '  componentWillReceivePropsnn' + 'The above lifecycles should be removed. Learn more about this warning here:n' + 'https://fb.me/react-async-component-lifecycle-hooks', ); </del> <ins> shallowRenderer.render(<Component />); </ins> }); it('should only render 1 level deep', () => {

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


Question: const originalSymbolFor = global.Symbol.for; global.Symbol.for = null; try { <del> expectToBeUnique(Object.entries(require('shared/ReactSymbols'))); </del> <ins> const entries = Object.entries(require('shared/ReactSymbols')).filter( // REACT_ASYNC_MODE_TYPE and REACT_CONCURRENT_MODE_TYPE have the same numeric value // for legacy backwards compatibility ([key]) => key !== 'REACT_ASYNC_MODE_TYPE', ); expectToBeUnique(entries); </ins> } finally { global.Symbol.for = originalSymbolFor; }

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

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


Question: * @param {object} inst The instance, which is the source of events. */ deleteAllListeners: function(inst) { <ins> var key = getDictionaryKey(inst); </ins> for (var registrationName in listenerBank) { if (!listenerBank.hasOwnProperty(registrationName)) { continue; } <del> if (!listenerBank[registrationName][inst._rootNodeID]) { </del> <ins> if (!listenerBank[registrationName][key]) { </ins> continue; }

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: ) { return true; } <ins> if (isCustomComponentTag) { return false; } </ins> if (propertyInfo !== null) { switch (propertyInfo.type) { case BOOLEAN:

Do you want to request a feature or report a bug? Bug What is the current behavior? The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. 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: Sorry, it's a CodePen. This example uses a framework called OnsenUI that internally uses web components. In the OnsenUI framework there is an icon web component that transforms every size prop value into a string which is not attached to the DOM. I know that the example has more dependencies than React, BUT there is also a simple div (as simple as this ) which is also affected by this issue. What is the expected behavior? The size prop should be to the DOM when it is not a number on HTML tags that aren't inputs and selects. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? The affected versions are = 16.3 It works ok in versions <= 16.2 Browsers: All
The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. What are the HTML tags that have a attribute except inputs and selects? With web components I am not seeing the issue: <img width="227" alt="screen shot 2018-04-26 at 7 51 53 pm" src="https://user-"
the attribute is an HTML attribute, not something that React provides. According to the HTML spec, is only allowed on and elements
I don't know why I wrote "rest of HTML tags", my bad . The example you provided works ok, but if I add something that doesn't seems like a valid size then it doesn't work. For example: Value | Works -------|------- 100 | Yes 10px | No 10e1 | Yes -1 | No Something changed in 16.3.

Version 16.3 <img width="853" alt="captura de pantalla 2018-04-26 a las 21 36 43" src="https://user-"Version 16.2 <img width="855" alt="captura de pantalla 2018-04-26 a las 21 37 10" src="https://user-" I suppose that it's fine to filter props when not passing the appropriate values when using HTML tags but I suppose that in web components the size attribute can be anything. Am I wrong? What do you think?
The web component code path shouldn't reject any attributes. If it does it's a bug.
The bug is . Before the we should add something like Please send a PR :-)
Ok, I will work on this tomorrow. I'm heading to bed. Thanks for your quick response.
Couldn't wait
Should be fixed in React 16.4.


Question: .DevTools, .DevTools * { box-sizing: border-box; -webkit-font-smoothing: var(--font-smoothing); }

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: * @param {ReactElement} element */ function validatePropTypes(element) { <del> if (element.type == null) { </del> <ins> if (!(typeof element.type === 'string' || typeof element.type === 'function')) { </ins> // This has already warned. Don't throw. return; }

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: transaction, this._mountDepth + 1 ); <del> child._mountImage = mountImage; </del> child._mountIndex = index; <del> this.createChild(child); </del> <ins> this.createChild(child, mountImage); </ins> this._renderedChildren = this._renderedChildren || {}; this._renderedChildren[name] = child; },

We're currently not cleaning up strings from _mountImage after a component gets mounted. That memory could be freed. But the act of freeing the memory could be more expensive than it's worth. Needs proper benchmarks and a workaround.
I noticed this a little while ago. I'm not sure why we need to store it on the child instance in the first place -- PR incoming.


Question: var args = [ "bin/jsx", <ins> "--cache-dir", ".module-cache", </ins> config.sourceDir, config.outputDir ];

has two calls to the Component class construction which are missing use of the 'new' operator. The calls are like this: Component(publicProps, publicContext, updateQueue) and are here: and here:
This is intentional. We check if we need to construct , and then use it to either call or not. This lets us support functional components and factory components:


Question: rootType = fiberRoot._debugRootType; } <del> const errors = fiberToErrorsMap.get(id) || new Map(); const warnings = fiberToWarningsMap.get(id) || new Map(); </del> <ins> const errors = fiberIDToErrorsMap.get(id) || new Map(); const warnings = fiberIDToWarningsMap.get(id) || new Map(); </ins> return { id,

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