Question: <del> /** * Copyright 2013-present, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; describe('ReactDOMButton', function() { var React; var ReactDOM; var ReactTestUtils; var onClick = jest.genMockFn(); function expectClickThru(button) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(button)); expect(onClick.mock.calls.length).toBe(1); } function expectNoClickThru(button) { onClick.mockClear(); ReactTestUtils.Simulate.click(ReactDOM.findDOMNode(button)); expect(onClick.mock.calls.length).toBe(0); } function mounted(button) { button = ReactTestUtils.renderIntoDocument(button); return button; } beforeEach(function() { React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('should forward clicks when it starts out not disabled', function() { expectClickThru(mounted(<button onClick={onClick} />)); }); it('should not forward clicks when it starts out disabled', function() { expectNoClickThru( mounted(<button disabled={true} onClick={onClick} />) ); }); it('should forward clicks when it becomes not disabled', function() { var container = document.createElement('div'); var btn = ReactDOM.render( <button disabled={true} onClick={onClick} />, container ); btn = ReactDOM.render( <button onClick={onClick} />, container ); expectClickThru(btn); }); it('should not forward clicks when it becomes disabled', function() { var container = document.createElement('div'); var btn = ReactDOM.render( <button onClick={onClick} />, container ); btn = ReactDOM.render( <button disabled={true} onClick={onClick} />, container ); expectNoClickThru(btn); }); it('should work correctly if the listener is changed', function() { var container = document.createElement('div'); var btn = ReactDOM.render( <button disabled={true} onClick={function() {}} />, container ); btn = ReactDOM.render( <button disabled={false} onClick={onClick} />, container ); expectClickThru(btn); }); }); </del>

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


Question: layout: docs permalink: pure-render-mixin.html prev: update.html <ins> next: perf.html </ins> --- If your React component's render function is "pure" (in other words, it renders the same result given the same props and state), you can use this mixin for a considerable performance boost.

I'll let write these, but it would be nice to get them spot checked by and/or


Question: } if (typeof instance.getSnapshotBeforeUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Snapshot;

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


Question: } if (__DEV__) { <del> var ExecutionEnvironment = require('ExecutionEnvironment'); </del> if (ExecutionEnvironment.canUseDOM && window.top === window.self) { // If we're in Chrome, look for the devtools marker and provide a download

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: }); }); <del> // Only call profile updates for paths that have re-rendered // Since "inner" is beneath a pure component, it isn't called expect(callback).toHaveBeenCalledTimes(2); expect(callback.mock.calls[0][0]).toBe('middle'); expect(callback.mock.calls[1][0]).toBe('outer'); </del> <ins> // Only call onRender for paths that have re-rendered. // Since the Updater's props didn't change, // React does not re-render its children. expect(callback).toHaveBeenCalledTimes(1); expect(callback.mock.calls[0][0]).toBe('outer'); </ins> }); it('decreases actual time but not base time when sCU prevents an update', () => {

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


Question: render: function() { return ( <div> <del> <ReactCSSTransitionGroup transitionName="carousel" transitionEnterTimeout={300} transitionLeaveTimeout={300}> </del> <ins> <ReactCSSTransitionGroup transitionName="carousel" transitionEnterTimeout={300} transitionLeaveTimeout={300}> </ins> <img src={this.props.imageSrc} key={this.props.imageSrc} /> </ReactCSSTransitionGroup> </div>

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


Question:
expect(result.props.className).toEqual('clicked'); });  it('can setState in componentWillMount when shallow rendering', function() { var SimpleComponent = React.createClass({ componentWillMount() { this.setState({groovy: 'doovy'}); }, render() { return
{this.state.groovy}
; }, }); var shallowRenderer = ReactTestUtils.createRenderer(); var result = shallowRenderer.render(<SimpleComponent />); expect(result).toEqual(
doovy
); });  it('can pass context when shallowly rendering', function() { var SimpleComponent = React.createClass({ contextTypes: {

Calling on in a component being Shallow Rendered will result in the error being thrown. I set up a test case:
Who would be best to answer this one?
Seems like a valid bug report — thanks and the test case is rad. I may not be able to look at this for a while, unfortunately.
no worries let me know if you need any more info from me. This was on React 14 beta btw (not sure if that matters)
I have the same issue. A simpler example that throws the error:
Any way of getting around this issue? I am currently running into it.
Sorry about the slow response from us (FB) here. I'm the principal author of the shallow render feature, but React core isn't my main gig and I've been swamped with product work. I don't have an offhand answer for you, but I've just put time on my calendar to look into this next week. Jim, Ben, Paul — if by chance one of you happened to take care of this before then, I wouldn't be mad :)
An update on my end. I think that my problem actually went away when I deduped my npm dependencies to remove an extra react version that was causing issues. If this error pops up again I'll let you know. Thanks for the response! On Fri, Aug 28, 2015, 9:38 PM Scott Feeney wrote:
Hmm I am still able to reproduce this issue in my test case after running npm dedupe
Just to clarify, my previous comment wasn't supposed to mean that the issue has gone away. I think I was seeing a separate issue caused by multiple react versions that I misidentified as this issue (I hope that makes sense).
I am getting this error, too. I'm using react v0.14.0-rc1. Looking at the code : Apparently .
Note that shallow rendered components override to return a instead of whatever it normally returns. That still shouldn't be undefined and should have a attribute, though.
I'm experiencing this issue too - your suggestion gets me past the initial error & on to in
Pretty sure this breaks many other things outside of , but I noticed moving to be directly above in fixed this for me.
We are also affected by this issue.

I think shallow rendering is a really cool feature for testing, but unfortunately I can't use it for some of our components due to this bug.
I created pull request with a fix that works for me. Can someone else verify?
Any workaround for this issue?
:+1: Having same issue
Just ran into this too :/
Any update on this? I see that 0.14.3 was released, but these kind of tests are still failing.
I think I have to add a test to my pull request before it can be merged, but I did not get around to do it yet.
Closing in favor of which should merge soon.


Question: { "name": "react-devtools-inline", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "description": "Embed react-devtools within a website", "license": "MIT", "main": "./dist/backend.js",

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


Question: } } } <ins> export function setIsRunningInsertionEffect(isRunning: boolean): void { if (__DEV__) { isRunningInsertionEffect = isRunning; } } </ins>

Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?


Question: }, }} className="gatsby-highlight"> <del> <LiveEditor onChange={this._onChange} /> </del> <ins> <LiveEditor onChange={this._onChange} ignoreTabKey={true} /> </ins> </div> </div> {error &&

The current default behavior is that keyboard users will get to the code sections of the live editor and get stuck. Can someone configure ignoreTabKey which makes the editor ignore tab key presses so that keyboard users can tab past the editor without getting stuck? Chrome on Windows atm and cannot edit it to submit a fix. Sorry about that :(
Thanks for bringing this to our attention


Question: resolved "https://registry.yarnpkg.com/react-timer-mixin/-/react-timer-mixin-0.13.4.tgz#75a00c3c94c13abe29b43d63b4c65a88fc8264d3" integrity sha512-4+ow23tp/Tv7hBM5Az5/Be/eKKF7DIvJ09voz5LyHGQaqqz9WV8YMs31eFvcYQs7d451LSg7kDJV70XYN/Ug/Q== <del> react-virtualized-auto-sizer@^1.0.2: version "1.0.2" resolved "https://registry.yarnpkg.com/react-virtualized-auto-sizer/-/react-virtualized-auto-sizer-1.0.2.tgz#a61dd4f756458bbf63bd895a92379f9b70f803bd" integrity sha512-MYXhTY1BZpdJFjUovvYHVBmkq79szK/k7V3MO+36gJkWGkrXKtyr4vCPtpphaTLRAdDNoYEYFZWE8LjN+PIHNg== </del> <ins> react-virtualized-auto-sizer@^1.0.6: version "1.0.6" resolved "https://registry.yarnpkg.com/react-virtualized-auto-sizer/-/react-virtualized-auto-sizer-1.0.6.tgz#66c5b1c9278064c5ef1699ed40a29c11518f97ca" integrity sha512-7tQ0BmZqfVF6YYEWcIGuoR3OdYe8I/ZFbNclFlGOC3pMqunkYF/oL30NCjSGl9sMEb17AnzixDz98Kqc3N76HQ== </ins> react@^16.13.1: version "16.13.1"

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

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

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

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


Question: if (request.status === CLOSED) { return; } <ins> if (request.destination !== null) { // We're already flowing. return; } </ins> request.destination = destination; try { flushCompletedQueues(request, destination);

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: expect(getDisplayName(FauxComponent, 'Fallback')).toEqual('Fallback'); }); }); describe('getDisplayNameForReactElement', () => { it('should return correct display name for an element with function type', () => { function FauxComponent() {}

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


Question: unstable_pauseExecution, unstable_continueExecution, unstable_getCurrentPriorityLevel, <ins> unstable_IdlePriority, unstable_ImmediatePriority, unstable_LowPriority, unstable_NormalPriority, unstable_UserBlockingPriority, </ins> }, SchedulerTracing: { __interactionsRef,

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? when typing in a controlled input, the cursor always jumps to the end. This was an old issue that seems to have resurfaced. used in the docs has the problem in all browsers as far as I have been able to test. What is the expected behavior? because we are using the state to update the component as soon as it's changed, the input element should be able to keep the cursor in the same place. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I'm at latest (16.8.2) and I tested on Chrome, FireFox, and Edge on Windows as far as I know, this was working at some point, though I don't know how long ago. possibly even before "Fiber"
This is quite weird. Same code works for me on CodeSandbox: Not sure what's going on here.
Seems UMD-specific.
Thank you very much for reporting this. It's a serious regression in the last patch release, and exposed some lacking coverage in our test suite regarding UMD bundles. I have a fix ready in
Great! thank you for the fix.
This is fixed in 16.8.3. Unfortunately unpkg doesn't seem to pick up the 16.8.3 version yet from its default redirect.
That's OK, I replaced the resources with the specific release artifacts to test and it works great now.
it flipped for me and I'm actually having the same problem OP reported in your CodeSandbox, but not in his codepen. Should that be? Chrome 74
I've updated from react 16.8.1 to 16.8.6. Still having the same problem...
I am running into this same issue. I have created the following fiddle which is a boiled down version of what I have. Ultimately once the event stack finishes it appears that React clears the value in the input since it is controlled. Then when the timeout fires it sets the correct value but at this time the position is lost.

I tried the fix this by handling the state internally to the TestInput Component as in the following fiddle. But after debugging it appears that setState causes getDerivedStateFromProps to be called which has the old value and I end up in the same mess. I feel I need getDerivedStateFromProps because I have handle the case where the value can change externally and I need to set the state to this new value. I believe if getDerivedStateFromProps was NOT called for a setState change then perhaps this problem would not exist, at least for my second example. But I am not familiar with the internals of React to even feel confident in this suggestion, so please take it with a grain of salt of course.
Okay based on my second fiddle I have come up with the following solution which should not require weird cursor manipulation. Please review, test, and use at your discretion. I have tested it a little and it appears to work. If I run into any problems I will post here.
Is this issue fixed? I'm having the same problem in 16.8.6.
Here is how I reproduce this issue. Is there something I'm doing wrong (or should do differently)?
There are 2 possible ways to get around this issue, as far as I can tell. Solution 1: Use the from the prop. Solution 2: Update the local state simultaneously as the parent state.
You're round-tripping the value change from to and back to and then calling . Apparently this round-trip makes React forget/reset the cursor position because I assume it looses a association between value and input element and/or re-renders the whole component. suggested in to call directly in the component which does work, but is not ideal when one prefers a stateless component. What I've done to workaround is to make the uncontrolled (change to ) with a prop. This also brings the benefit of the input remaining responsive when is computationally expensive.
In your example if you make a change, the InputChild component will be rendered once with outdated values. This is because the new value isn't set until useEffect. So whatever you typed will be erased for one frame, then put back after useEffect. This is enough to make the cursor position ambiguous to the browser. As a hack suggestion, you can swap useEffect with useMemo. This works because useMemo runs before render.


Question: <ins> /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @flow */ const {useEffect} = require('react'); function useCustom() { useEffect(() => { // ... }, []); } module.exports = {useCustom}; </ins>  No newline at end of file

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


Question:
 import Fixture from '../../Fixture'; import FixtureSet from '../../FixtureSet'; import TestCase from '../../TestCase'; const React = window.React; class ProgressFixture extends React.Component { state = {value: 0, max: 1, enabled: false, backwards: false}; startTest = () => { this.setState({enabled: true}, () => { this.progressIntervalId = setInterval(() => { if (this.state.backwards) { if (this.state.value > 0) { this.setState({value: this.state.value - this.state.max / 100}); } else { if (this.state.max === 10000) { this.resetTest(); } else { this.setState({max: this.state.max * 100, backwards: false}); } } } else { if (this.state.value < this.state.max) { this.setState({value: this.state.value + this.state.max / 100}); } else { this.setState({backwards: true}); } } }, 10); }); }; resetTest = () => { clearInterval(this.progressIntervalId); this.setState({value: 0, max: 1, enabled: false, backwards: false}); }; render() { return ( <FixtureSet title="Progress"> <TestCase title="Fill and reset progress bar"> <TestCase.Steps>
Press enable button
 </TestCase.Steps> <TestCase.ExpectedResult> When enabled, bar value should increase from 0% to 100% and backwards during three step loop: 0-1, 0-100, 0-10000. Reset button stops loop, sets value to 0 and max to 1. </TestCase.ExpectedResult> <Fixture>
 <fieldset> <legend>Controlled</legend> <progress value={this.state.value} max={this.state.max}></progress> <button onClick={ this.state.enabled ? this.resetTest : this.startTest }> {this.state.enabled ? 'Reset' : 'Enable'} </button>
  {' '} max: {JSON.stringify(this.state.max)}   {' '} value:{' '} {JSON.stringify( Math.round((this.state.value + Number.EPSILON) * 100) / 100 )}  </fieldset>
 </Fixture> </TestCase> </FixtureSet> ); } } export default ProgressFixture;

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


Question: "applications": { "gecko": { "id": "@react-devtools", <del> "strict_min_version": "54.0" </del> <ins> "strict_min_version": "55.0" </ins> } },

We currently build DevTools to target Chrome 49 and Firefox 54. These are super old browser versions and they did not have full ES6 support, so the generated build is more bloated than it needs to be. DevTools uses most modern language features. Off the top of my head, the following features are used (basically everything but async and generator functions): The above min browser versions come from Assuming I'm not forgetting things, it looks like we'd need to target Chrome 60+ (released 2017-07-25) and Firefox 55+ (released 2017-04-18). This seems like a reasonable set of browsers to target. Interestingly enough, according to , but I think certain details (like spread in object literals) weren't included in the original spec and/or weren't until later. Note that we can't remove the IE 11 target from the backend yet due to Hermes (React Native) ES6 support but that should be doable by the end of the year given current engineering targets. But we could update the frontend target, as well as the targets for the extensions and the package. It would be good to increase the browser versions we target to at least the version numbers mentioned above, rebuild the DevTools, and compare bundle sizes and generated code.


Question: --- <ins> ### 6.0.0 September 25, 2024 #### Features * Support Server Components in Tree ([sebmarkbage](https://github.com/sebmarkbage) in [#30684](https://github.com/facebook/react/pull/30684)) * feat: expose installHook with settings argument from react-devtools-core/backend ([hoxyq](https://github.com/hoxyq) in [#30987](https://github.com/facebook/react/pull/30987)) * Add Filtering of Environment Names ([sebmarkbage](https://github.com/sebmarkbage) in [#30850](https://github.com/facebook/react/pull/30850)) * Support secondary environment name when it changes ([sebmarkbage](https://github.com/sebmarkbage) in [#30842](https://github.com/facebook/react/pull/30842)) * Filter Server Components ([sebmarkbage](https://github.com/sebmarkbage) in [#30839](https://github.com/facebook/react/pull/30839)) * Make function inspection instant ([sebmarkbage](https://github.com/sebmarkbage) in [#30786](https://github.com/facebook/react/pull/30786)) * Make Functions Clickable to Jump to Definition ([sebmarkbage](https://github.com/sebmarkbage) in [#30769](https://github.com/facebook/react/pull/30769)) * [Flight/DevTools] Pass the Server Component's "key" as Part of the ReactComponentInfo ([sebmarkbage](https://github.com/sebmarkbage) in [#30703](https://github.com/facebook/react/pull/30703)) * Make Element Inspection Feel Snappy ([sebmarkbage](https://github.com/sebmarkbage) in [#30555](https://github.com/facebook/react/pull/30555)) * Print component stacks as error objects to get source mapping ([sebmarkbage](https://github.com/sebmarkbage) in [#30289](https://github.com/facebook/react/pull/30289)) #### Bugfixes * Fix: profiling crashes #30661 #28838 ([EdmondChuiHW](https://github.com/EdmondChuiHW) in [#31024](https://github.com/facebook/react/pull/31024)) * chore: remove settings manager from react-devtools-core ([hoxyq](https://github.com/hoxyq) in [#30986](https://github.com/facebook/react/pull/30986)) * fix[react-devtools/extensions]: fixed tabs API calls and displaying restricted access popup ([hoxyq](https://github.com/hoxyq) in [#30825](https://github.com/facebook/react/pull/30825)) * fix[react-devtools/InspectedElement]: fixed border stylings when some of the panels are not rendered ([hoxyq](https://github.com/hoxyq) in [#30676](https://github.com/facebook/react/pull/30676)) * fix: path handling in react devtools ([Jack-Works](https://github.com/Jack-Works) in [#29199](https://github.com/facebook/react/pull/29199)) #### Other * feat: display message if user ended up opening hook script ([hoxyq](https://github.com/hoxyq) in [#31000](https://github.com/facebook/react/pull/31000)) * refactor[react-devtools]: move console patching to global hook ([hoxyq](https://github.com/hoxyq) in [#30596](https://github.com/facebook/react/pull/30596)) * refactor[react-devtools]: initialize renderer interface early ([hoxyq](https://github.com/hoxyq) in [#30946](https://github.com/facebook/react/pull/30946)) * Use Unicode Atom Symbol instead of Atom Emoji ([sebmarkbage](https://github.com/sebmarkbage) in [#30832](https://github.com/facebook/react/pull/30832)) * feat[react-devtools]: support Manifest v3 for Firefox extension ([hoxyq](https://github.com/hoxyq) in [#30824](https://github.com/facebook/react/pull/30824)) * Enable pointEvents while scrolling ([sebmarkbage](https://github.com/sebmarkbage) in [#30560](https://github.com/facebook/react/pull/30560)) --- </ins> ### 5.3.1 July 3, 2024

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


Question: "node": ">=0.10.0" }, "dependencies": { <ins> "create-react-class": "^15.5.2", </ins> "fbjs": "^0.8.9", "loose-envify": "^1.1.0", "object-assign": "^4.1.0",

Looks like something about the 'create-react-class' removal was not correctly cherry-picked into 15.6. Steps to reproduce: a new CRA project the version of React in to You'll get this error:


Question: var event = SyntheticInputEvent.getPooled( eventTypes.beforeInput, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ); event.data = chars;

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


Question: function makeSimulator(eventType) { return function(domComponentOrNode, eventData) { var node; <ins> invariant( !React.isValidElement(domComponentOrNode), 'TestUtils.Simulate expects a component instance and not a ReactElement.' + 'TestUtils.Simulate will not work if you are using shallow rendering.' ); </ins> if (ReactTestUtils.isDOMComponent(domComponentOrNode)) { node = findDOMNode(domComponentOrNode); } else if (domComponentOrNode.tagName) {

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


Question: * ${license} */ <del> ${source}`; </del> <ins> (function(){${source}})();`; </ins> }, /***************** UMD_PROFILING *****************/

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


Question: layout: docs next: tutorial.html --- <ins> ## JSFiddle The easiest way to start hacking on React is using the following JSFiddle Hello Worlds * **[React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)** * [React JSFiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) ## Starter Kit </ins> Download the starter kit to get started. <div class="buttons-unit downloads">

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: /** * Hyphenates a camelcased CSS property name, for example: * <del> *   > hyphenate('backgroundColor') </del> <ins> *   > hyphenateStyleName('backgroundColor') </ins> *   < "background-color" <del> *   > hyphenate('MozTransition') </del> <ins> *   > hyphenateStyleName('MozTransition') </ins> *   < "-moz-transition" <del> *   > hyphenate('msTransition') </del> <ins> *   > hyphenateStyleName('msTransition') </ins> *   < "-ms-transition" * * As Modernizr suggests (http://modernizr.com/docs/#prefixed), an `ms` prefix

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


Question: cloneUpdateQueue(current, workInProgress); <del> const oldProps = workInProgress.memoizedProps; instance.props = </del> <ins> const unresolvedOldProps = workInProgress.memoizedProps; const oldProps = </ins> workInProgress.type === workInProgress.elementType <del> ? oldProps : resolveDefaultProps(workInProgress.type, oldProps); </del> <ins> ? unresolvedOldProps : resolveDefaultProps(workInProgress.type, unresolvedOldProps); instance.props = oldProps; const unresolvedNewProps = workInProgress.pendingProps; </ins> const oldContext = instance.context; const contextType = ctor.contextType;

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


Question: return ( <FixtureSet title="Mouse Events"> <MouseMovement /> <ins> <MouseEnter /> </ins> </FixtureSet> ); }

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: ]); grunt.registerTask('build:test', [ 'delete-build-modules', <del> 'test:eslint-rules', </del> 'jsx:test', 'version-check', 'populist:test',

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: .filter(function(npmTaskName) { return npmTaskName != 'grunt-cli'; }) .forEach(function(npmTaskName) { grunt.loadNpmTasks(npmTaskName); }); <del> // Alias 'jshint' to 'lint' to better match the workflow we know grunt.registerTask('lint', ['jshint']); </del> <ins> // Super simplified eslint task that we can use to replace linting. This just // shells out to eslint. grunt.registerTask('eslint', function() { var done = this.async(); grunt.util.spawn({ cmd: 'node_modules/.bin/eslint', args: ['src'] }, function(err, result, code) { if (result.stdout.length) { grunt.warn(result.stdout); } done(code === 0); }); }); grunt.registerTask('lint', ['eslint']); </ins> grunt.registerTask('download-previous-version', require('./grunt/tasks/download-previous-version.js'));

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


Question: font-family: var(--font-family-sans); } <ins> .Source { padding: 0.25rem; border-top: 1px solid var(--color-border); } .SourceHeaderRow { display: flex; align-items: center; } .SourceHeader { flex: 1 1; font-family: var(--font-family-sans); } .SourceOneLiner { font-family: var(--font-family-monospace); font-size: var(--font-size-monospace-normal); white-space: nowrap; overflow: hidden; text-overflow: ellipsis; max-width: 100%; margin-left: 1rem; } </ins> .Component, .Owner { color: var(--color-component-name);

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

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

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


Question: // TODO: When is this not true? if (ReactComponent.isValidComponent(child)) { this.removeChild(child); <del> child._mountImage = null; </del> child._mountIndex = null; child.unmountComponent(); delete this._renderedChildren[name];

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: react_docs: { files: [ { <del> src: ['react.min.js', 'JSXTransformer.js'], </del> <ins> src: ['react.js', 'JSXTransformer.js'], </ins> dest: 'docs/js/', cwd: 'build/', expand: true

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


Question: }); it("does not bail out if there's a context change", async () => { <del> const {Suspense} = React; </del> const CountContext = React.createContext(0); function readContext(Context) {

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0


Question: .center { text-align: center; } <ins> input { font-family: inherit; } </ins>

It doesn't match the rest of our text. I think a in the right place in the stylesheet should fix this. !
Pretty sure this is already correct…
It's not. Proxima Nova on the body vs. the default sans system font (San Francisco in the screenshot) in the
The font is indeed different. With font-family inherited: <img width="248" alt="screen shot 2016-09-13 at 00 27 38" src=""Without (current): <img width="244" alt="screen shot 2016-09-13 at 00 27 48" src=""
touché - I had unchecked the browser-styles box in my inspector at some point and so it showed it inheriting the html style… oops. (the Proxima Nova "R" and SF "R" look similar enough that it fooled me too). We could probably just make in as opposed to targeting just this one - we already have that for headers.
Adjusted the PR to include just that
Closed with


Question: .Value { color: var(--color-attribute-value); <del> white-space: nowrap; </del> <ins> white-space: pre; </ins> overflow: hidden; text-overflow: ellipsis; cursor: default;

It looks like the property inspector inside React DevTools is not rendering repeating spaces properly. I imagine this can result in some fairly frustrating debugging sessions when doing something like string matching a component that takes a string as a property. multiple spaces in a row to that property (I would type the actual spaces, but it appears Github truncates the extra spaces even inside the code snippet!) that element inside React DevTools. The value of the prop is rendered as The value of the prop should be rendered as Below are some screenshots of the behavior I'm seeing in production. Here's how the property value is rendered in inspector when it is output directly to the HTML: ! And here is how that same value is rendered inside DevTools: !
Looks like is our culprit. According to we just need to change that from to . I will try to test that and put up a PR if it works.
You're correct. Interested in contributing a patch for it? (If not, I'm happy to– but since you've already done the work I thought I'd ask.)
I would be more than happy to! I'll aim to have something up by this evening.
PR is up and ready for review!


Question: It's as simple as assigning a `ref` attribute to anything returned from `render` such as: <del> ```html <input ref={ function(component){ React.findDOMNode(component).focus();} } /> ``` </del> <ins> ```html render: function() { return <TextInput ref={(c) => this._input = c} } />; }, componentDidMount: function() { this._input.focus(); }, ``` or ```html render: function() { return ( <TextInput ref={function(input) { if (input != null) { input.focus(); } }} /> ); }, ``` Note that when the referenced component is unmounted and whenever the ref changes, the old ref will be called with `null` as an argument. This prevents memory leaks in the case that the instance is stored, as in the first example. Note that when writing refs with inline function expressions as in the examples here, React sees a different function object each time so on every update, ref will be called with `null` immediately before it's called with the component instance. </ins> ## Completing the Example

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


Question: }); ``` <del> ### function createClass(object specification) </del> <ins> #### React.createClass ```javascript function createClass(object specification) ``` </ins> Creates a component given a specification. A component implements a `render` method which returns a single child. That child may have an arbitrarily deep child structure. One thing that makes components different than a standard prototypal classes is that you don't need to call new on them. They are convenience wrappers that construct backing instances (via new) for you. <del> ### ReactComponent renderComponent(ReactComponent container, DOMElement mountPoint) </del> <ins> #### React.renderComponent ```javascript ReactComponent renderComponent(ReactComponent container, DOMElement mountPoint) ``` </ins> Renders a React component into the DOM in the supplied `container`.

I have a fresh installation of Ubuntu 14.04 and installed compiled version of 10.38. failed on step with error 'make: g++: Command not found'. solves the problem. It make sense put g++ dependency into Prerequisites section.
That's kind of annoying but yea, we might need to do something like that. Compilers are a dependency for any binary npm module (which one of our dependencies depends on). Even contextify itself doesn't call out the need for g**. When you install node / npm via does it not install as well? It seems like it should since that's a requirement for many modules.
I used the recommended approach for . is not a part of installation. But I see your point, contextify setup on Windows even more .
The installation of build-essential is not 'optional'. It is a prerequisite for otherwise node-gyp will fail. The instructions for the Debian-based installation should reflect that build-essential is a prerequisite.
for installing g++ in fedora and other linux os use sudo yum install /usr/bin/g++ or sudo dnf install gcc-c++
fixed it for me (Ubuntu)
works for CentOS7, too. :)
What about Mac?


Question: place, }); } else if (propertyPath.isObjectMethod()) { <ins> if (propertyPath.node.kind !== "method") { builder.errors.push({ reason: `(BuildHIR::lowerExpression) Handle ${propertyPath.node.kind} functions in ObjectExpression`, severity: ErrorSeverity.Todo, loc: propertyPath.node.loc ?? null, suggestions: null, }); continue; } </ins> const method = lowerObjectMethod(builder, propertyPath); const place = lowerValueToTemporary(builder, method); const loweredKey = lowerObjectPropertyKey(builder, propertyPath);

[ ] 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: * Creates a child component. * * @param {ReactComponent} child Component to create. <ins> * @param {string} mountImage Markup to insert. </ins> * @protected */ <del> createChild: function(child) { enqueueMarkup(this._rootNodeID, child._mountImage, child._mountIndex); </del> <ins> createChild: function(child, mountImage) { enqueueMarkup(this._rootNodeID, mountImage, child._mountIndex); </ins> }, /**

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: // Make sure we set .type before any other properties (setting .value // before .type means .value is lost in IE11 and below) type: undefined, <del> }, props, { </del> <ins> }, DisabledInputUtils.getNativeProps(inst, props), { </ins> defaultChecked: undefined, defaultValue: undefined, value: value != null ? value : inst._wrapperState.initialValue,

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


Question: // stash the callbacks first var callbacks = component._pendingCallbacks; component._pendingCallbacks = null; <del> component.performUpdateIfNecessary(transaction); </del> <ins> component.performUpdateIfNecessary(transaction.reconcileTransaction); </ins> if (callbacks) { for (var j = 0; j < callbacks.length; j++) { <del> transaction.getReactMountReady().enqueue( </del> <ins> transaction.callbackQueue.enqueue( </ins> callbacks[j], component );

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

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

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


Question: function isPresto() { const opera = window.opera; return ( <ins> opera !== null && </ins> typeof opera === 'object' && typeof opera.version === 'function' && parseInt(opera.version(), 10) <= 12

I want to report a bug. When there is a var named opera with value null in window before loading react then react app crashes. Steps to reproduce: 1) Create a new app using create-react-app my-app 2) cd my-app && yarn start 3) Add one line (</script) just before closing body tag into file 4) The app crashes here. Couldn't reproduce on I think because problem appears if we execute BEFORE loading react. Expected behavior is to not crash. React v16.2.0 and Google Chrome Version 63.0.3239.84 (Official Build) (64-bit). Have no info about problematic behavior with previous versions of React.
Closed by


Question: } `, }, <ins> { code: normalizeIndent` function App(props) { React.useEffect((() => { console.log(props.test); }) as any, [props.test]); } `, }, </ins> ], invalid: [ {

React version: 17.0.1 Setup eslint with as parser Cast a function passed to Link to code example: The following error was reported The rule should interpret the function argument correctly and know that it is already inline.
It looks like it is something that would be easy to support, but the question is: why would you do that?
Heh, a fair question. In my case, I needed it in order to support generics for a hook that helps manage state for asynchronous calls like mutations: Without the cast, TS doesn't know that the shape of the args object is the same. On the return statement, TS warns: This remains true even if I make the args a generic type too, so I think the issue is unavoidable.
TS is correct there. A function that has the same input type & return type as is not assignable to . might have other properties attached to it as well, which won't be attached to . For your particular situation, the type for can be a function that has the same argument & return types as , but should not be . Casting it as is lying to typescript.
Ahhh. Thanks With that hint I was able to fix my types and obviate the cast. That said, I would recommend keeping this issue open, since there will always be cases where folks will have to resort to casts like these, whether due to limitations in TS's expressiveness or (as in this case and I suspect most cases) one's ability to understand the type complexities and specify the types correctly. Sadly, not everyone has access to a to help them out when the types get complex.


Question: <ins> --- id: perf title: Performance Tools layout: docs permalink: perf.html prev: pure-render-mixin.html --- React is usually quite fast out of the box. However, in situations where you need to squeeze every ounce of performance out of your app, it provides a [shouldComponentUpdate](/react/docs/component-specs.html#updating-shouldcomponentupdate) hook where you can add optimization hints to React's diff algorithm. In addition to giving you an overview of your app's overall performance, ReactPerf is a profiling tool that tells you exactly where you need to put these hooks. > Note: > > The dev build of React is slower than the prod build, due to all the extra logic for providing, for example, React's friendly console warnings (stripped away in the prod build). Therefore, the profiler only serves to indicate the _relatively_ expensive parts of your app. ## General API ### `Perf.start()` and `Perf.stop()` Start/stop the measurement. The React operations in-between are recorded for analyses below. Operations that took an insignificant amount of time are ignored. ### `Perf.printInclusive(measurements)` Prints the overall time taken. If no argument's passed, defaults to all the measurements from the last recording. This prints a nicely formatted table in the console, like so: ![](/react/img/docs/perf-inclusive.png) ### `Perf.printExclusive(measurements)` "Exclusive" times don't include the times taken to mount the components: processing props, `getInitialState`, call `componentWillMount` and `componentDidMount`, etc. ![](/react/img/docs/perf-exclusive.png) ### `Perf.printWasted(measurements)` **The most useful part of the profiler**. "Wasted" time is spent on components that didn't actually render anything, e.g. the render stayed the same, so the DOM wasn't touched. ![](/react/img/docs/perf-wasted.png) ### `Perf.printDOM(measurements)` Prints the underlying DOM manipulations, e.g. "set innerHTML" and "remove". ![](/react/img/docs/perf-dom.png) ## Advanced API The above print methods use `Perf.getLastMeasurements()` to pretty-print the result. ### `Perf.getLastMeasurements()` Get the measurements array from the last start-stop session. The array contains objects, each of which looks like this: ```js { // The term "inclusive" and "exclusive" are explained below "exclusive": {}, // '.0.0' is the React ID of the node "inclusive": {".0.0": 0.0670000008540228, ".0": 0.3259999939473346}, "render": {".0": 0.036999990697950125, ".0.0": 0.010000003385357559}, // Number of instances "counts": {".0": 1, ".0.0": 1}, // DOM touches "writes": {}, // Extra debugging info "displayNames": { ".0": {"current": "App", "owner": "<root>"}, ".0.0": {"current": "Box", "owner": "App"} }, "totalTime": 0.48499999684281647 } ``` </ins>

I'll let write these, but it would be nice to get them spot checked by and/or


Question: 'use strict'; var CSSProperty = require('CSSProperty'); <ins> var warning = require('warning'); </ins> var isUnitlessNumber = CSSProperty.isUnitlessNumber; <ins> var styleWarnings = {}; </ins> /** * Convert a value into the proper css writable value. The style name `name`

It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.