Question:
expect(el.style.color).toBe('red'); } });  // This simulates the scenario in https://github.com/facebook/react/issues/20100 it('does not block DevTools when an unsupported renderer is injected', () => { if (__DEV__) { initFauxDevToolsHook(); const onCommitFiberRoot = global.__REACT_DEVTOOLS_GLOBAL_HOOK__.onCommitFiberRoot; // Redirect all React/ReactDOM requires to v16.8.0 // This version predates Fast Refresh support. jest.mock('react', () => jest.requireActual('react-16-8')); jest.mock('react-dom', () => jest.requireActual('react-dom-16-8')); // Load React and company. jest.resetModules(); React = require('react'); ReactDOM = require('react-dom'); Scheduler = require('scheduler'); // Important! Inject into the global hook *after* ReactDOM runs: ReactFreshRuntime = require('react-refresh/runtime'); ReactFreshRuntime.injectIntoGlobalHook(global); render(() => { function Hello() { return
Hi!
; } $RefreshReg$(Hello, 'Hello'); return Hello; }); expect(onCommitFiberRoot).toHaveBeenCalled(); } });  });

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

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

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

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

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


Question: { "private": true, "name": "react-devtools-timeline", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "license": "MIT", "dependencies": { "@elg/speedscope": "1.9.0-a6f84db",

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: componentWillMount() ``` <del> Invoked immediately before rendering occurs. If you call `setState` within this method, `render()` will see the updated state and will be executed only once despite the state change. </del> <ins> Invoked once, immediately before the initial rendering occurs. If you call `setState` within this method, `render()` will see the updated state and will be executed only once despite the state change. </ins> ### Mounting: componentDidMount

I ran a few benchmarks on the server (modifying to not use jsdom). The results were surprising, as the browserified was about 30% faster than the npm version, even with . The performance ranking (test run time) was < < < . I suspect is not a regular js object but perhaps a getter and thus carries a penalty when you test for everywhere. Also the minified version might still perform best of all, as at least some time ago V8 used function source length (including comments) as a heuristic for function complexity / compilation time and thus affecting chances for optimization in some cases, but the effect might be negligible.
is indeed not a regular object, but defined from the native side, so that may be the culprit for server rendering regression: and So this introduced a getter in quite time-sensitive places (around invariants etc) in your otherwise clean codebase. Can you reproduce the issue? /cc
Lately I have been simply using a wrapped module Works great. You could consider switching npm package to some such scheme if there are no downsides.
My first attempt was to just add to the top of every file, but unfortunately uglify isn't smart enough to do dead code removal then. I wonder if we should have essentially make two copies of the code -- one for dev, one for prod, so transforms into so we only pay the getter cost once (per module) at require time. Is doing this easy with recast? It's not obvious to me if interacts well with cloning the AST.
I would love to see this get some attention. 30% improvement out of the box would be awesome. Is there a lot of work to do here?
I think eventually we will want people to do a build step for server rendering, i.e. webpack's mode. Especially if people start expressing static asset dependencies as statements.
I'm using webpack and was enough to solve it for me. Is there no such thing in browserify?
For browserify there's transform which automatically activates for package. You just need to set before bundling: Thus browserify also can be used for bundling for server rendering.
Call me all crazy, just had a left field idea. Could the transformer that builds the npm module create 2 complete copies of react? one for dev and one for production?

In the the normal version of react could you there look at the and swap which module is returned? This way on server you only get the performance hit once;
That's not too crazy. It's a bit annoying from a build process though. I'd love to know what's happening at a larger scale in the node community. It seems like we shouldn't be the first people to encounter this in a larger scale. A couple other ideas… What if we set in our main module and leave in our code everywhere else. There's some obvious bad behavior there (setting globals). So we could do variants. Only set it when it's not already set. Change to something more unique at build time () and then set that. If we switch to webpack for building the browser bundles, then the solution is super easy, and I'm sure there's a way to do this in browserify too. Another idea: Have a modules which memoizes . This is sounding like something node should do itself, but the code linked to uses ObjectTemplate (which if I'm understand a bit of V8 right doesn't do any caching because values can change). There would still be a lookup cost, but it would just be a property access, not a getter and not a call out to get current environment variables (). This one is trickier because it would mean more code and we won't do this internally. I'd prefer a different solution, even if it's more hacky. If all you're using is React and nothing from , then you could do something like mentioned above. We started shipping the browerified bundles in the npm package, so and will end up giving you the bundles which don't access .
I don't think we're going to do anything specifically for server rendering other than bundling the builds in like mentioned, but we might change the npm package eventually to be prebuilt using closure or similar.
just curious why and not ?
It was just an example. If that was the actual code I'd do the direct assignment like you suggested.
ah, ok - thanks :)
any movement on this?
No movement, though you can already require the builds from react/dist as mentioned above.
since you mentioned Webpack, do you use Webpack for server side code?
If you're already using babel on your server-side code (say, via or ), you can add the to get around this problem.

I wonder why react just can't export from for production env when react package ships with .
Because then results in a different copy of code, which will have issues. As long as that is remotely supported (and it's currently how and our addons packages work), we can't do that. we might do something like that in the future though.
true that it's not recommended to run babel on libraries? I've seen a few warnings about this. Have you tried the babel transform-inline-environment-variables plugin in production? Did it work?
Technically, you have to (which is slow) to get this to work. How do you feel about compiling not into in non-dist builds, but rather require() some module that caches the env? This is just a guess, but I believe will optimize well (function call vs. getter (which doesn't optimize in v8) + call to ). I found the babel plugin in I'll give it a try & profile.
thanks! However, I've seen a warning that is . I've only used on files in my app. I'm curious if people use it on node modules commonly in production.
The catch here is that people use envify to do dead-code elimination to remove non- blocks so changing our pattern here will force downstream changes.
Understood. I suppose it becomes a question of priorities unless we can think of something more creative. Unfortunately with the introduction of react-dom, it's not possible to use react minified builds on the server anymore unless you use a packager or the without duplicating , due to the new halfway-shimmed packages that directly.
should work, no?
Ah you're correct, since the deprecation notice will get taken out due to the production check.
Oh wait, you're right that react-dom does require react directly…
Hah got confused myself. You'd have to just require and pretend it was ReactDOM, knowing that the deprecation warnings would be removed. Doesn't seem portable to 0.15.
Initial bench results show a wider performance gap (last two runs) than the OP. In bench 4, I replace with , eliminating the getter.
I wonder if performance can just be improved in node core (by caching).
I've asked about that, but they're not interested because programs may be relying on catching ENV changes as it is possible to change the ENV of a running process.

I've been able to manage a great improvement in server-side rendering (about 100%) by hosting to the top of the file as a , so it is only evaluated once. The best part is, when uglifyJS sees a const, it replaces the member in a condition, leaving which is then removed entirely. So we maintain the same code size, no backcompat hacks, and better perf. Only issue is that we may need to then post-process replace the for a in case of use with Browserify with old browsers.
Can I ask why this was closed? This is by far the number one bottleneck for us on the server-side. Having to change all code to , for example, is a leaky abstraction and very un-Node-like.
Technically you can fix the problem in your own code by doing , converting it from a live object that calls down a plain JS object. You'll get the same performance benefits, with the only downside that any code that was relying on live edits to the env (does anyone really do that?) will fail.
cool, good to know – neat idea! Still, massively leaky abstraction right? Like, suddenly React pollutes your entire app
Yeah. I've been working on , but it requires a change in UglifyJS to allow marking statements with an annotation (e.g. ) so it knows that it won't change and safe to eliminate dead code.
killer little hack btw – immediately increased our server throughput by 50% I'd still love for this issue to be reopened, or tracked elsewhere (will improve things for all React code?) should work on speeding it up as well (I believe they've made ), but having littered throughout hot code is just not ideal practice IMO – if not being able to hoist that up, cache it, memoize it, whatever, is prevented by build tools, then let's fix the build tools.
They're . is meant to be live.
oh for sure it is – I completely agree with that – I don't think it should be cached by Node either, just the current implementation has (or had) room for improvement.
As I mention in that ticket, this is the main problem: A annotation in UglifyJS will fix this.
That seems like a decent solution to me.

I'm personally not a fan of the use of a global everywhere in the React code – again, it feels really build-tool specific. I'd prefer it be imported from a config file or declared in each module or something similar. Principle of least surprise and all that.
I would be happy to do that, but it is important that we have a way to eliminate dev-only code in prod builds and that users of React from npm have a way to do the same. Obviously we can use whatever tools we want for our stack easily but for npm currently we suggest envify/webpack.DefinePlugin. Not inherently opposed to changing that but we'd need a good proposal and reason.
yeah, I hear ya – there's a lot of code now in React that depends on that behaviour. Not sure I fully understand your comment "for npm currently we suggest envify/webpack.DefinePlugin" – what do you mean "for npm"? React code is compiled before it's published to npm, right? My general feeling is that it would be great if there were no FB/React-specific idioms in the code – so that it's treated as though, if v8 (or other engines) had all the ES2015/2016 features needed, then you could run the code on without even needing a compiler. Currently that's not really the case. (I'm sure you could do some sort of trick or something before requiring any React modules, but still, that would be a polluting hack) If there were a way such that was required, or declared, per module – and code elimination still worked as it does now for the builds – would you be amenable to a PR along those lines?
I mean: if you use webpack or browserify in conjunction with react from npm, you should be able to eliminate React dev-only code from your prod builds. envify lets us do that easily in browserify as it copies the NODEENV from when you make your build, and webpack.DefinePlugin lets you configure your build to replace with a constant which then can get constant-folded and minified out. This use case is important. Yes, if it works for the case of React devs using browserify/webpack too, not just our premade builds.

as an aside, just looking through the code now, and aside from the global , I haven't seen anything that's not supported out of the box in right now – is there a reason, aside from , that the non- code is even compiled and transformed into a different structure before publishing to npm?
Well, it does set up the team to move to ES6 for , which will be important in the near future. I've submitted a PR to UglifyJS2 as you can see above. If it's accepted this will solve the problem.
We'd still need everyone using React to upgrade to that version of UglifyJS so I can't promise that we'll take it…
Just everyone using React in combination with webpack or browserify and not using the build. Alternatively they could use the DefinePlugin to set to false to get the dead code elimination.
just to clarify, do you mean "everyone using React who also currently uses UglifyJS with it"?
Just so I'm clear, there are a few users here that I can think of. Those, on the browser: everywhere already, or as a global browserify/webpack + envify/DefinePlugin browserify/webpack + envify/DefinePlugin + UglifyJS browserify/webpack + plugin to transform to or So 1 and 4 are taken care of by the compilation in . What's the main reason for even supporting 2 and 3? Is it because of things like ?
2 and 3 are the most natural for many people. If you are using browserify then envify gets used automatically because of our config in Almost everyone minifies their code in prod. It is true that we could recommend instead for many cases, but it does fall apart in the case of requiring submodules. We don't support this for external users because we consider the modules private but the addons packages use this pattern. Various third-party projects (unsupported by us) also make use of this.
I think the only reason 2 and 3 are "most natural" is just because is used everywhere so you have to use something just to get it to even work out of the box. It would be equally easy to setup the config in to use or or whatever.

I use 4 whenever I can and it's no more complicated than 2 or 3 for normal usage – I guess it's just a pity that users are encouraged to "reach in" to for various addons. Thanks for the clarification. So it's those doing 3 who are expecting their current UglifyJS setup to eliminate any code using that you're concerned about?
To clarify: we recommend users require or similar, which (currently) reaches into react but that's an implementation detail. Yes.
Ah cool, good to know.
We have been bitten by this one too. Would be great if some note about this behavior was present on , it's a large performance impact, and is hard to find this issue unless you have already done all the investigation work.
I would like to add that this issue also affects applications. Now the work arounds seem to be: Include the minified version of React globally via tag, it would only work in Electron and it isn't the node way, where one should be able to track every used object just seeing the . It also makes it difficult to switch between dev/prod. Use the to replace with a regular object. Not good, as we are forced to overwrite node api just because we want to use React. If using babel: ... by default babel doesn't transpile nodemodules, this can be configured but doesn't look like a work around. Note that replace every to isn't a solution because automatically requires from root, not from . Why is this issue closed? It seems to me that React should be able to initialize its configuration using , then rely on its own objects, and optionally offer a function to change the value later. Is there any reason why this wouldn't work?
Technically this could be fixed now as UglifyJS supports annotations, and it may be easier still as the team moves the build to Rollup in . In combination with Rollup, it would be simple to export a var from a constants file and have it effectively tagged by Uglify for dead code elimination in production mode.
Adding my two cents here, I was able to work around this by adding the following to the top of my I had previously wrapped React using local modules as was suggested above, but this caused a lot of issues with . This seems to get the job done without too much overhead or complexity.

For future reference, the above snippet is broken per:
Referencing which will fix this now that UglifyJS can properly eliminate dev code (even if it references a that never changes) with its new option, which is a default. See for more context.


Question: "memoize-one": "^5.1.1", "nullthrows": "^1.1.1", "pretty-ms": "^7.0.0", <del> "react-virtualized-auto-sizer": "^1.0.2", </del> <ins> "react-virtualized-auto-sizer": "^1.0.6", </ins> "regenerator-runtime": "^0.13.7" }, "devDependencies": {

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: } }); <ins> it('should allow extension of native prototypes', function() { /*eslint-disable no-extend-native */ String.prototype.key = 'react'; Number.prototype.key = 'rocks'; /*eslint-enable no-extend-native */ var instance = ( <div> {'a'} {13} </div> ); var traverseFn = jasmine.createSpy(); traverseAllChildren(instance.props.children, traverseFn, null); expect(traverseFn.calls.length).toBe(2); expect(traverseFn).toHaveBeenCalledWith( null, 'a', '.0' ); expect(traverseFn).toHaveBeenCalledWith( null, 13, '.1' ); delete String.prototype.key; delete Number.prototype.key; }); </ins> it('should throw on object', function() { expect(function() { traverseAllChildren({a: 1, b: 2}, function() {}, null);

I came across this one because I'd extended with a custom key generator. React ends up treating the function itself as the child key, so it hides any strings that come after it. Object key handling is documented and makes sense. Not sure it makes sense to handle string keys this way.
what do you want to do here?
I think the issue is actually here yeah? Should probably be changed to
Nice catch. I think that we might actually have more of these flaws. We should be more careful as this prevents browsers to add to the string prototype. that if branch can be separated and we just use the implicit key for string/number.


Question: title: Web Components - id: glossary title: React (Virtual) DOM Terminology <del> - title: Flux items: - id: flux-overview title: Flux Overview href: https://facebook.github.io/flux/docs/overview.html - id: flux-todo-list title: Flux TodoMVC Tutorial href: https://facebook.github.io/flux/docs/todo-list.html </del>

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: A slow loading script does not seem to cause React to suspend as expected from this description. a with a deliberate delay on the response that React canary does not suspend while the script is loading <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --This example contains a script where the server takes six seconds to respond. It changes the text to once executed. Note that it immediately displays . I expect it to display the Suspense fallback message for six seconds before switching to around the same time that the switch is made.
I have the same problem with . suspense does not fallback
Thank you for raising this. This was actually an oversight when writing the documention. Script tags don't suspend since they're not blocking rendering HTML unlike CSS. We're just removing any mention of Suspense from this page:


Question:
```javascript{3-5} render: function() { return (  <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}>   <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}>
Fading at Initial Mount
 </ReactCSSTransitionGroup> );

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


Question: <script type="text/javascript" src="//use.typekit.net/vqa1hcx.js"></script> <script type="text/javascript">try{Typekit.load();}catch(e){}</script> <ins> <!--[if lte IE 8]> <script type="text/javascript" src="/react/js/es5-shim.js"></script> <script type="text/javascript" src="/react/js/es5-sham.js"></script> <![endif]--> </ins> <script type="text/javascript" src="/react/js/codemirror.js"></script> <script type="text/javascript" src="/react/js/javascript.js"></script> <script type="text/javascript" src="/react/js/react.min.js"></script>

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


Question: ReactTestUtils.renderIntoDocument(<select value={null}><option value="test"/></select>); expect(console.error.argsForCall.length).toBe(1); }); <ins> it('should refresh state on change', function() { var stub = <select value="giraffe" onChange={noop}> <option value="monkey">A monkey!</option> <option value="giraffe">A giraffe!</option> <option value="gorilla">A gorilla!</option> </select>; stub = ReactTestUtils.renderIntoDocument(stub); var node = ReactDOM.findDOMNode(stub); ReactTestUtils.Simulate.change(node); expect(node.value).toBe('giraffe'); }); </ins> });

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


Question: var SyntheticEvent = require('SyntheticEvent'); var assign = require('Object.assign'); <ins> var emptyObject = require('emptyObject'); </ins> var findDOMNode = require('findDOMNode'); var topLevelTypes = EventConstants.topLevelTypes;

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


Question: const [prevValue, setValue] = updateState(value); updateEffect( () => { <del> Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); </del> <ins> const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setValue(value); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } </ins> }, [value, config], ); return prevValue; } <ins> function startTransition(setPending, config, callback) { const priorityLevel = getCurrentPriorityLevel(); runWithPriority( priorityLevel < UserBlockingPriority ? UserBlockingPriority : priorityLevel, () => { setPending(true); }, ); runWithPriority( priorityLevel > NormalPriority ? NormalPriority : priorityLevel, () => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setPending(false); callback(); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }, ); } </ins> function mountTransition( config: SuspenseConfig | void | null, ): [(() => void) => void, boolean] { const [isPending, setPending] = mountState(false); <del> const startTransition = mountCallback( callback => { setPending(true); Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setPending(false); callback(); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); }, [config, isPending], ); return [startTransition, isPending]; </del> <ins> const start = mountCallback(startTransition.bind(null, setPending, config), [ setPending, config, ]); return [start, isPending]; </ins> } function updateTransition( config: SuspenseConfig | void | null, ): [(() => void) => void, boolean] { const [isPending, setPending] = updateState(false); <del> const startTransition = updateCallback( callback => { setPending(true); Scheduler.unstable_next(() => { const previousConfig = ReactCurrentBatchConfig.suspense; ReactCurrentBatchConfig.suspense = config === undefined ? null : config; try { setPending(false); callback(); } finally { ReactCurrentBatchConfig.suspense = previousConfig; } }); }, [config, isPending], ); return [startTransition, isPending]; </del> <ins> const start = updateCallback(startTransition.bind(null, setPending, config), [ setPending, config, ]); return [start, isPending]; </ins> } function dispatchAction<S, A>(

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


Question: - [`createFragment`](create-fragment.html), to create a set of externally-keyed children. - [`update`](update.html), a helper function that makes dealing with immutable data in JavaScript easier. - [`PureRenderMixin`](pure-render-mixin.html), a performance booster under certain situations. <del> - (DEPRECATED) [`classSet`](class-name-manipulation.html), for manipulating the DOM `class` string a bit more cleanly. </del> The add-ons below are in the development (unminified) version of React only:

Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors


Question: return { "debug": true, "mocking": true, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": true

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


Question: * CSS properties which accept numbers but are not in units of "px". */ var isUnitlessNumber = { <ins> columnCount: true, </ins> fillOpacity: true, <ins> flex: true, flexGrow: true, flexShrink: true, </ins> fontWeight: true, lineHeight: true, opacity: true, <ins> order: true, </ins> orphans: true, <ins> pitchRange: true, richness: true, stress: true, volume: true, widows: true, </ins> zIndex: true, zoom: true };

Firs, it's unitless. I've seen a hack where the value is being specified as to make it pass the check and skip our adding of 'px'. Further, is actually a shorthand property, so we should support the expansion into the right properties.
I don't think we need to do anything special for shorthand properties except for the list needed only for IE8.
related: there are also some obscure css properties that can be unitless: Edit: + widow, - counter-*
While we're at it, is also unitless. The properties mentioned in the above link don't actually take a single number.
I'm not saying it's a great idea, just putting it out there... but what if we switched over to , , , , , etc. Not the prettiest, but perhaps prettier than and you can now access unmodified traditional CSS behavior and if you want to use the short-hand style, it's obvious and unambiguous, and not limited to just . It doesn't modify expected behavior, it doesn't conflict... philosophically that's up to you. :) ...speaking with people in the chat, I agree that it's a bad idea... however, seeing other peoples gripes with how React doesn't vendor-prefix, etc, etc. Perhaps the real solution is for React to export a settable where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix , use the addon. And this is a bad idea as well as it would prevent reliably sharing components. is currently ambiguous as it supports unitless and and thus we cannot auto-suffix it...
line-height 'px' is used 15x-50x more times than unitless, em or percentage on fb codebase. I feel like this should be the default and we should provide a more verbose way to use it in an unitless way.
I agree, my only issue with that is that we would explicitly break with the CSS standard then.
My view on this is that the CSS standard is only using strings. So if you say '1.5', React is just going to output '1.5'. Now if you say 23 (the number), then React is going to be able to add any convenience it wants, such as adding 'px' as it's the most common use case.
It doesn't conflict today (probably never will but still).

Also, do we now want to add , , (and so on for each numeric unit)? I think I'm more likely to go for forcing a unit if you want one. (eg, doesn't get converted to , you have to put the in yourself).
My idea with having the units as a suffix of the name is that it could be a universal test for all properties (for simplicity). If , or whatever is at the end the property name, we remove it and add it to the value instead. That way the only thing we would need to hard-code is which units are allowed, so the implementation would be minimal and barring any new units, future proof. While it theoretically could conflict, I don't see how it ever could, the units have very non-wordy names (case would obviously be taken into account as it already is). However, a practical issue is what to do if there are multiple units specified for the same property. So I definitely see that this may not be the favored way to go, just putting it out there :) I like idea, but I feel like it would be hair thin separation of the two and possibly "dangerous"... but it is neat, and likely what the user intended.
Fixed by -- we can discuss units more on a separate issue if needed.


Question: var instantiateReactComponent = require('instantiateReactComponent'); var invariant = require('invariant'); var keyMirror = require('keyMirror'); <ins> var keyOf = require('keyOf'); </ins> var merge = require('merge'); var mixInto = require('mixInto'); var monitorCodeUse = require('monitorCodeUse');

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


Question: const requiredBackends = new Set<string>(); <del> function registerRenderer(renderer: ReactRenderer) { </del> <ins> function registerRenderer(renderer: ReactRenderer, hook: DevToolsHook) { </ins> let version = renderer.reconcilerVersion || renderer.version; if (!hasAssignedBackend(version)) { version = COMPACT_VERSION_NAME; } <del> requiredBackends.add(version); </del> <ins> // Check if required backend is already activated, no need to require again if (!hook.backends.has(version)) { requiredBackends.add(version); } </ins> } function activateBackend(version: string, hook: DevToolsHook) {

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


Question: } } <del> function clearDirtyComponents() { dirtyComponents.length = 0; } function flushBatchedUpdatesOnce(transaction) { // Run these in separate functions so the JIT can optimize try { runBatchedUpdates(transaction); } finally { clearDirtyComponents(); } } </del> var flushBatchedUpdates = ReactPerf.measure( 'ReactUpdates', 'flushBatchedUpdates', function() { <del> // flushBatchedUpdatesOnce will clear the dirtyComponents array, but // mount-ready handlers (i.e., componentDidMount/Update) may enqueue more // state updates which we should apply immediately </del> <ins> // ReactUpdatesFlushTransaction's wrappers will clear the dirtyComponents // array and perform any updates enqueued by mount-ready handlers (i.e., // componentDidUpdate) but we need to check here too in order to catch // updates enqueued by setState callbacks. </ins> while (dirtyComponents.length) { <del> var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(); transaction.perform(flushBatchedUpdatesOnce, null, transaction); ReactUpdates.ReactReconcileTransaction.release(transaction); </del> <ins> var transaction = ReactUpdatesFlushTransaction.getPooled(); transaction.perform(runBatchedUpdates, null, transaction); ReactUpdatesFlushTransaction.release(transaction); </ins> } } );

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

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

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


Question:
expect(childEnterCalls).toBe(1); expect(parentEnterCalls).toBe(0); });  // Test for https://github.com/facebook/react/issues/16763. it('should call mouseEnter once from sibling rendered inside a rendered component', done => { const mockFn = jest.fn(); class Parent extends React.Component { constructor(props) { super(props); this.parentEl = React.createRef(); } componentDidMount() { ReactDOM.render(<MouseEnterDetect />, this.parentEl.current); } render() { return
; } } class MouseEnterDetect extends React.Component { constructor(props) { super(props); this.firstEl = React.createRef(); this.siblingEl = React.createRef(); } componentDidMount() { this.siblingEl.current.dispatchEvent( new MouseEvent('mouseout', { bubbles: true, cancelable: true, relatedTarget: this.firstEl.current, }), ); expect(mockFn.mock.calls.length).toBe(1); done(); } render() { return ( <React.Fragment>

 </React.Fragment> ); } } ReactDOM.render(<Parent />, container); });  });

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: // Check that the version we're exporting is the same one we expect in the // package. This is not an ideal way to do this, but makes sure that we keep // them in sync. <ins> var reactVersionExp = /bReact.versions*=s*['"]([^'"]+)['"];/; </ins> grunt.registerTask('version-check', function() { <del> var version = require('./build/modules/React').version; </del> <ins> var version = reactVersionExp.exec( grunt.file.read('./build/modules/React.js') )[1]; </ins> var expectedVersion = grunt.config.data.pkg.version; if (version !== expectedVersion) { grunt.log.error('Versions do not match. Expected %s, saw %s', expectedVersion, version);

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


Question: #### Events <del> React attaches event handlers to components using a camelCase naming convention. We attach an onKeyUp handler to the text field, check if the user has entered text and pressed the enter key and then clear the form fields. </del> <ins> React attaches event handlers to components using a camelCase naming convention. We attach an `onSubmit` handler to the form that clears the form fields when the form is submitted with valid input. We always return `false` from the event handler to prevent the browser's default action of submitting the form. (If you prefer, you can instead take the event as an argument and call `preventDefault()` on it – read more about [event handling](event-handling.html).) </ins> `React.autoBind()` is a simple way to ensure that a method is always bound to its component. Inside the method, `this` will be bound to the component instance.

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


Question: <del> 'use strict'; var grunt = require('grunt'); module.exports = function() { var done = this.async(); grunt.util.spawn({ cmd: 'node_modules/eslint-tester/node_modules/mocha/bin/mocha', args: ['eslint-rules/__tests__'], opts: {stdio: 'inherit'}, // allows colors to passthrough }, function(err, result, code) { if (err) { grunt.log.error('Custom linter rules are broken'); } else { grunt.log.ok('Custom linter rules are okay'); } done(code === 0); }); }; </del>

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: }); it('accepts custom comparison function', async () => { <del> const {Suspense} = React; </del> function Counter({count}) { return <Text text={count} />; }

<!-- 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: getInitialStateWasCalled = true; return {}; } <ins> getDefaultProps() { getDefaultPropsWasCalled = true; return {}; } </ins> render() { return <span className="foo" />; } } test(<Foo />, 'SPAN', 'foo'); expect(getInitialStateWasCalled).toBe(false); <del> expect(console.error.calls.length).toBe(3); </del> <ins> expect(getDefaultPropsWasCalled).toBe(false); expect(console.error.calls.length).toBe(4); </ins> expect(console.error.calls[0].args[0]).toContain( 'getInitialState was defined on Foo, a plain JavaScript class.' ); expect(console.error.calls[1].args[0]).toContain( <del> 'propTypes was defined as an instance property on Foo.' </del> <ins> 'getDefaultProps was defined on Foo, a plain JavaScript class.' </ins> ); expect(console.error.calls[2].args[0]).toContain( <ins> 'propTypes was defined as an instance property on Foo.' ); expect(console.error.calls[3].args[0]).toContain( </ins> 'contextTypes was defined as an instance property on Foo.' ); });

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


Question: TransitionGroup: ReactTransitionGroup, batchedUpdates: ReactUpdates.batchedUpdates, <del> classSet: cx, </del> cloneWithProps: cloneWithProps, createFragment: ReactFragment.create, shallowCompare: shallowCompare,

Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors


Question: case 'form': case 'video': case 'audio': <del> this._wrapperState = { listeners: null, }; transaction.getReactMountReady().enqueue(trapBubbledEventsLocal, this); </del> <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> break; case 'button': props = ReactDOMButton.getNativeProps(this, props, nativeParent); break; case 'input': <ins> this._setupTrapBubbledEventsLocal(transaction); </ins> ReactDOMInput.mountWrapper(this, props, nativeParent); props = ReactDOMInput.getNativeProps(this, props); break;

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


Question: * @internal */ instantiateChildren: function(nestedChildNodes, transaction, context) { <del> var children = flattenChildren(nestedChildNodes); for (var name in children) { if (children.hasOwnProperty(name)) { var child = children[name]; // The rendered children must be turned into instances as they're // mounted. var childInstance = instantiateReactComponent(child, null); children[name] = childInstance; } </del> <ins> if (nestedChildNodes == null) { return null; </ins> } <del> return children; </del> <ins> var childInstances = {}; traverseAllChildren(nestedChildNodes, instantiateChild, childInstances); return childInstances; </ins> }, /**

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


Question: <del> 'use strict'; var _extends = Object.assign || function(target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; }; /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @providesModule Wedge.art * @typechecks * * Example usage: * <Wedge *   outerRadius={50} *   startAngle={0} *   endAngle={360} *   fill="blue" * /> * * Additional optional property: *   (Int) innerRadius * */ var PropTypes = require('prop-types'); var React = require('react'); var ReactART = require('..'); var createReactClass = require('create-react-class'); var Shape = ReactART.Shape; var Path = ReactART.Path; /** * Wedge is a React component for drawing circles, wedges and arcs.  Like other * ReactART components, it must be used in a <Surface>. */ var Wedge = createReactClass({ displayName: 'Wedge', propTypes: { outerRadius: PropTypes.number.isRequired, startAngle: PropTypes.number.isRequired, endAngle: PropTypes.number.isRequired, innerRadius: PropTypes.number, }, circleRadians: Math.PI * 2, radiansPerDegree: Math.PI / 180, /** * _degreesToRadians(degrees) * * Helper function to convert degrees to radians * * @param {number} degrees * @return {number} */ _degreesToRadians: function _degreesToRadians(degrees) { if (degrees !== 0 && degrees % 360 === 0) { // 360, 720, etc. return this.circleRadians; } else { return degrees * this.radiansPerDegree % this.circleRadians; } }, /** * _createCirclePath(or, ir) * * Creates the ReactART Path for a complete circle. * * @param {number} or The outer radius of the circle * @param {number} ir The inner radius, greater than zero for a ring * @return {object} */ _createCirclePath: function _createCirclePath(or, ir) { var path = Path(); path.move(0, or).arc(or * 2, 0, or).arc(-or * 2, 0, or); if (ir) { path .move(or - ir, 0) .counterArc(ir * 2, 0, ir) .counterArc(-ir * 2, 0, ir); } path.close(); return path; }, /** * _createArcPath(sa, ea, ca, or, ir) * * Creates the ReactART Path for an arc or wedge. * * @param {number} startAngle The starting degrees relative to 12 o'clock * @param {number} endAngle The ending degrees relative to 12 o'clock * @param {number} or The outer radius in pixels * @param {number} ir The inner radius in pixels, greater than zero for an arc * @return {object} */ _createArcPath: function _createArcPath(startAngle, endAngle, or, ir) { var path = Path(); // angles in radians var sa = this._degreesToRadians(startAngle); var ea = this._degreesToRadians(endAngle); // central arc angle in radians var ca = sa > ea ? this.circleRadians - sa + ea : ea - sa; // cached sine and cosine values var ss = Math.sin(sa); var es = Math.sin(ea); var sc = Math.cos(sa); var ec = Math.cos(ea); // cached differences var ds = es - ss; var dc = ec - sc; var dr = ir - or; // if the angle is over pi radians (180 degrees) // we will need to let the drawing method know. var large = ca > Math.PI; // TODO (sema) Please improve theses comments to make the math // more understandable. // // Formula for a point on a circle at a specific angle with a center // at (0, 0): // x = radius * Math.sin(radians) // y = radius * Math.cos(radians) // // For our starting point, we offset the formula using the outer // radius because our origin is at (top, left). // In typical web layout fashion, we are drawing in quadrant IV // (a.k.a. Southeast) where x is positive and y is negative. // // The arguments for path.arc and path.counterArc used below are: // (endX, endY, radiusX, radiusY, largeAngle) path .move(or + or * ss, or - or * sc) // move to starting point .arc(or * ds, or * -dc, or, or, large) // outer arc .line(dr * es, dr * -ec); // width of arc or wedge if (ir) { path.counterArc(ir * -ds, ir * dc, ir, ir, large); // inner arc } return path; }, render: function render() { // angles are provided in degrees var startAngle = this.props.startAngle; var endAngle = this.props.endAngle; if (startAngle - endAngle === 0) { return; } // radii are provided in pixels var innerRadius = this.props.innerRadius || 0; var outerRadius = this.props.outerRadius; // sorted radii var ir = Math.min(innerRadius, outerRadius); var or = Math.max(innerRadius, outerRadius); var path; if (endAngle >= startAngle + 360) { path = this._createCirclePath(or, ir); } else { path = this._createArcPath(startAngle, endAngle, or, ir); } return React.createElement(Shape, _extends({}, this.props, {d: path})); }, }); module.exports = Wedge; </del>

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


Question: ); } }); <ins> PageTwoContent = React.createFactory(PageTwoContent); </ins> /** Application popup page component. */ var PagePopUpContent = React.createClass({

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


Question: break; } case 'unknown': { <del> // If we don't know how this extension was built, we can't reliably detect if there // are other installations of DevTools present. // In this case, assume there are no duplicate exensions and show a warning about // potential conflicts. console.error(UNRECOGNIZED_EXTENSION_ERROR); chrome.devtools.inspectedWindow.eval( `console.error("${UNRECOGNIZED_EXTENSION_ERROR}")`, ); </del> <ins> // TODO: Support duplicate extension detection in other browsers if (IS_CHROME) { // If we don't know how this extension was built, we can't reliably detect if there // are other installations of DevTools present. // In this case, assume there are no duplicate exensions and show a warning about // potential conflicts. console.error(UNRECOGNIZED_EXTENSION_ERROR); chrome.devtools.inspectedWindow.eval( `console.error("${UNRECOGNIZED_EXTENSION_ERROR}")`, ); } </ins> callback(false); break; }

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


Question: render: function() { // Clone `this.props` so we don't mutate the input. var props = merge(this.props); <del> var value = LinkedValueUtils.getValue(this); </del> invariant( props.dangerouslySetInnerHTML == null,

creates invalid html markup and appears to be unnecessary for proper functionality of the . Admittedly my test here was very minimal, but removing from the object using rendered valid html and the component still worked properly in the browser and passed all it's tests. Other than perhaps supporting server-side rendering, is there a purpose to rendering into the real dom?
Good catch :+1: The reason is set is because is , i.e, it's treated as a property rather than an attribute at run-time (which is correct). But like you say, it should not generate markup for the attribute (because it's wrong). I'm not 100% sure what the preferred fix is here, add another "directive" ex: ?
I don't think it's invalid markup. just isn't used (unless you use , which we don't do for ). I was surprised that just deleting value would work, but I guess we're applying updates to value of the actual node manually, not relying on render. This seems like a good enough approach to me. We already render the initial value as a text child so we don't use this for server rendering. another directive could make sense if we get scoped properties in there since this is only true for <textareabut not for other inputs. But until then... Want to submit a PR (cc
By invalid I meant the generated markup will not validate via the W3C html validator, throwing the error "Attribute value not allowed on element textarea at this point." Yes, I will submit a PR.


Question: instance.log('after unmount'); expect(ops).toEqual([ 'getInitialState: false', <ins> 'mixin.componentWillMount: false', </ins> 'componentWillMount: false', 'render: false', <ins> 'mixin.componentDidMount: true', </ins> 'componentDidMount: true', <ins> 'mixin.componentWillUpdate: true', </ins> 'componentWillUpdate: true', 'render: true', <ins> 'mixin.componentDidUpdate: true', </ins> 'componentDidUpdate: true', <del> 'componentWillUnmount: false', </del> <ins> 'mixin.componentWillUnmount: true', 'componentWillUnmount: true', </ins> 'after unmount: false', ]);

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


Question: }, "dependencies": { "base62": "~0.1.1", <del> "commoner": "~0.6.8", </del> <ins> "commoner": "~0.7.0", </ins> "esprima": "git://github.com/facebook/esprima#fb-harmony", <del> "recast": "~0.3.3", </del> <ins> "recast": "~0.4.5", </ins> "source-map": "~0.1.22" }, "devDependencies": {

React version: 16.8.0 an app that toggles between rendering a text input and a date input. the of each to some arbitrary input, valid for either one toggling occurs that the value of the date input is not preserved upon toggle The date input's value is not preserved The date input's value should be preserved We discovered a simple workaround--add a unique property to each input, and the value will be respected.
It seems to be the default correct behaviour. You can read more about how works here. The reason it seems to work by adding the key prop is because the component gets re-rendered from scratch and therefore the "works". I think what you want to achieve is pretty date display when not in edit mode. Maybe something like this. Demo Prototype code
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!


Question: debug: false, standalone: 'React', transforms: [envify({NODE_ENV: 'development'})], <del> after: [es3ify.transform, simpleBannerify] </del> <ins> after: [es3ify.transform, derequire, simpleBannerify] </ins> }; <del> var min = _.merge({}, basic, { </del> <ins> var min = { entries: [ './build/modules/React.js' ], </ins> outfile: './build/react.min.js', debug: false, <ins> standalone: 'React', </ins> transforms: [envify({NODE_ENV: 'production'}), uglifyify], <del> after: [minify, bannerify] }); </del> <ins> after: [es3ify.transform, derequire, minify, bannerify] }; </ins> var transformer = { entries:[

Do you want to request a feature or report a bug? It's more of a bug -- I don't think this behaviour should occur, but it's not a problem in production. What is the current behavior? Warning appears. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). . I'll paste the code here too, just in case: What is the expected behavior? No warning. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Fiddle uses React 15.0.1. Tested in Chrome on Ubuntu. I didn't test previous versions of React, but I suspect it's always been this way. Notes If I'm not mistaken, the HTML generated via cannot be updated by React because the essential DOM attributes are stripped away. This means that s should not be necessary because React will never need to match up the elements during a re-render. Supplying s that will never be used just to avoid a warning is tedious. Ergo, warning should be suppressed when JSX is rendered via .
Yeah, technically true. There were some talks a while back about potentially doing , in which case, and could become a single function because React wouldn't need any additional data in the DOM. That would make this don't-emit-key-warning difference much harder to justify. There is also something to be said for remaining consistent. If you are writing components that don't specify a key, then your components can't be shared/used with nor in the future (decreases reusability, increases fragmentation). Maybe it would be too opinionated for us to enforce that, but I could make the argument that maintaining a single cohesive component ecosystem is more important. Honestly, this would be pretty low priority for us. If you see an easy fix and want to submit a PR, I'd say it has a 50/50 chance (coin toss) of getting merged, probably depending primarily on complexity. We don't want to introduce any global state or do a whole ton of routing to decide if this warning needs to be emitted. Probably your best bet would be to move the warning to a devtool, and have the devtool become aware of what type of render is being performed.

Nested renders would need to be considered. I'm going to close this out because this isn't a clear win for us, and it is almost certainly something that our team would not have the bandwidth to do internally. If someone in the community is passionate about fixing this, we'd take a look at any PRs, but can't make any promises a priori.
That's fair enough, I wouldn't rate it as high priority either. Thank you for taking the time to respond


Question: export function flushSync<A, R>(fn: A => R, a: A): R { const prevExecutionContext = executionContext; <del> if ((prevExecutionContext & (RenderContext | CommitContext)) !== NoContext) { if (__DEV__) { console.error( 'flushSync was called from inside a lifecycle method. React cannot ' + 'flush when React is already rendering. Consider moving this call to ' + 'a scheduler task or micro task.', ); } return fn(a); } </del> executionContext |= BatchedContext; const previousPriority = getCurrentUpdatePriority();

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


Question: var ReactComponent = require('ReactComponent'); var ReactDOM = require('ReactDOM'); var ReactMount = require('ReactMount'); <ins> var ReactProps = require('ReactProps'); </ins> var ReactServerRendering = require('ReactServerRendering'); var ReactDefaultInjection = require('ReactDefaultInjection');

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


Question: <ins> /** * Copyright 2014-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; require('mock-modules') .dontMock('shallowEqual'); var shallowEqual; describe('shallowEqual', function() { beforeEach(function() { shallowEqual = require('shallowEqual'); }); it('returns false if either argument is null', function() { expect(shallowEqual(null, {})).toBe(false); expect(shallowEqual({}, null)).toBe(false); }); it('returns true if both arguments are null or undefined', function() { expect(shallowEqual(null, null)).toBe(true); expect(shallowEqual(undefined, undefined)).toBe(true); }); it('returns true if arguments are shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2, c: 3} ) ).toBe(true); }); it('returns false if first argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2} ) ).toBe(false); }); it('returns false if second argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2}, {a: 1, b: 2, c: 3} ) ).toBe(false); }); it('returns false if arguments are not shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: {}}, {a: 1, b: 2, c: {}} ) ).toBe(false); }); }); </ins>

Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1


Question: ); } }); <ins> it('should not warn about transition updates scheduled during commit phase', async () => { function Component() { const [value, setValue] = React.useState(0); // eslint-disable-next-line no-unused-vars const [isPending, startTransition] = React.useTransition(); Scheduler.unstable_yieldValue( `Component rendered with value ${value}`, ); // Fake a long render if (value !== 0) { Scheduler.unstable_yieldValue('Long render'); startTime += 20000; } React.useLayoutEffect(() => { startTransition(() => { setValue(1); }); }, []); return value; } if (gate(flags => flags.enableSchedulingProfiler)) { const cpuProfilerSample = creactCpuProfilerSample(); const root = ReactDOM.createRoot(document.createElement('div')); act(() => { root.render(<Component />); }); expect(Scheduler).toHaveYielded([ 'Component rendered with value 0', 'Component rendered with value 0', 'Component rendered with value 1', 'Long render', ]); const testMarks = []; clearedMarks.forEach(markName => { if (markName === '--component-render-start-Component') { // Fake a long running render startTime += 20000; } testMarks.push({ pid: ++pid, tid: ++tid, ts: ++startTime, args: {data: {}}, cat: 'blink.user_timing', name: markName, ph: 'R', }); }); const data = await preprocessData([ cpuProfilerSample, ...createBoilerplateEntries(), ...testMarks, ]); data.schedulingEvents.forEach(event => { expect(event.warning).toBeNull(); }); } }); it('should not warn about deferred value updates scheduled during commit phase', async () => { function Component() { const [value, setValue] = React.useState(0); const deferredValue = React.useDeferredValue(value); Scheduler.unstable_yieldValue( `Component rendered with value ${value} and deferredValue ${deferredValue}`, ); // Fake a long render if (deferredValue !== 0) { Scheduler.unstable_yieldValue('Long render'); startTime += 20000; } React.useLayoutEffect(() => { setValue(1); }, []); return value + deferredValue; } if (gate(flags => flags.enableSchedulingProfiler)) { const cpuProfilerSample = creactCpuProfilerSample(); const root = ReactDOM.createRoot(document.createElement('div')); act(() => { root.render(<Component />); }); expect(Scheduler).toHaveYielded([ 'Component rendered with value 0 and deferredValue 0', 'Component rendered with value 1 and deferredValue 0', 'Component rendered with value 1 and deferredValue 1', 'Long render', ]); const testMarks = []; clearedMarks.forEach(markName => { if (markName === '--component-render-start-Component') { // Fake a long running render startTime += 20000; } testMarks.push({ pid: ++pid, tid: ++tid, ts: ++startTime, args: {data: {}}, cat: 'blink.user_timing', name: markName, ph: 'R', }); }); const data = await preprocessData([ cpuProfilerSample, ...createBoilerplateEntries(), ...testMarks, ]); data.schedulingEvents.forEach(event => { expect(event.warning).toBeNull(); }); } }); </ins> }); describe('errors thrown while rendering', () => {

This feature is meant to warn about sync priority updates that block paint (e.g. set state in layout effect) but it appears to also warn for transition priority updates. We should fix this.