Question: Scheduler.flushAll(); expect(root).toMatchRenderedOutput('hello'); }); <ins> // Regression test for https://github.com/facebook/react/issues/15732 it('resets hooks when an error is thrown in the middle of a list of hooks', async () => { const {useEffect, useState} = React; class ErrorBoundary extends React.Component { state = {hasError: false}; static getDerivedStateFromError() { return {hasError: true}; } render() { return ( <Wrapper> {this.state.hasError ? 'Error!' : this.props.children} </Wrapper> ); } } function Wrapper({children}) { return children; } let setShouldThrow; function Thrower() { const [shouldThrow, _setShouldThrow] = useState(false); setShouldThrow = _setShouldThrow; if (shouldThrow) { throw new Error('Throw!'); } useEffect(() => {}, []); return 'Throw!'; } const root = ReactTestRenderer.create( <ErrorBoundary> <Thrower /> </ErrorBoundary>, ); expect(root).toMatchRenderedOutput('Throw!'); act(() => setShouldThrow(true)); expect(root).toMatchRenderedOutput('Error!'); }); </ins> });

I’ve seen the “rendered fewer hooks than expected” invariant a couple times now pointing at a component rendered as a part of an error boundary that just caught an error when that component does not use hooks at all. I’ve been able to fix this issue by un-commenting: I haven’t been able to produce a minimal test-case yet . I’m reporting anyway with the temporary fix that worked for me in case you have any insight on what a minimal test-case could be. I’ll update this issue if I keep running into the problem and I can create a minimal test-case.
I ran into the issue again and was able to produce a small repro: Pressing the “throw” button results in the invariant: With a component stack of: Which is weird since has no hooks!
Wanna look into fixing? Should be easy — there must be a missing call somewhere. Or maybe doesn't reset everything we need.
I looked into it, wrote a test, and discovered it’s fixed on master The test is broken on 16.8.6, I didn’t bother bisecting to find the commit that fixed it. PR for the test: .
I thought I was seeing this in 16.9, but it turns out we were on and , and both need to be updated for this to work.


Question: if (config != null) { ref = config.ref === undefined ? null : config.ref; <del> key = config.key === undefined ? null : '' + config.key; </del> <ins> if (__DEV__) { warning( config.key !== null, 'createElement(...): Encountered component with a `key` of null. In ' + 'a future version, this will be treated as equivalent to the string ' + ''null'; instead, provide an explicit key or use undefined.' ); } // TODO: Change this back to `config.key === undefined` key = config.key == null ? null : '' + config.key; </ins> // Remaining properties are added to a new props object for (propName in config) { if (config.hasOwnProperty(propName) &&

In 0.11, the code assigned implicit keys to both children. In 0.12, it gives the error and renders only "foo", because the key is cast to a string in ReactElement before it gets checked against null in traverseAllChildren: I guess it's okay if this is intentional but it broke a part of KA in the upgrade. (cc
hm. Yea, this was intentional to ensure more stable types through out the system. I don't think null should be treated as a valid "non-value" to align it with defaultProps, default arguments and default values in destructuring. The intention of "null" is to symbolize a missing object. However, this can be of any type. It's weird that is coerced into . It should be left as . For refs, we expect them to become objects so it is valid to have there to represent a missing value. We have a two options: 1) Allow any value to be coerced to strings. 2) Throw on non-string values. 3) Don't coerce to string and start using maps as keys. E.g. Dates would become by reference instead of by value. would be treated as a key and would still be duplicate.
Maybe we can support meaning no key for a 0.12 with a warning, then drop support in 0.13? Just trying to avoid breaking things (that are impossible to grep for) without a warning. (I have no idea if we have other places in our code that do this by accident…)
They don't in prod though, right? I thought we had a fallback for duplicate values that would be essentially the same?
No, that code previously outputted and outputs just with 0.12. We ignore all children after the first with a given key.
oh. fine, warning for one version and then swap behavior. Want to send a PR?
Will do.


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

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


Question: * @flow */ <ins> import {copy} from 'clipboard-js'; </ins> import React, {useCallback, useContext} from 'react'; import {TreeDispatcherContext, TreeStateContext} from './TreeContext'; import {BridgeContext, StoreContext} from '../context';

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

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

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


Question: expect(a.getDOMNode().childNodes[0].id).toBe('two'); expect(a.getDOMNode().childNodes[1].id).toBe('one'); }); <ins> describe('with an undefined child', function () { it('should fail silently', function () { var a = React.renderComponent( <ReactTransitionGroup transitionName="yolo"> </ReactTransitionGroup>, container ); }); }); </ins> });

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


Question: // register renderers that inject themselves later. hook.sub('renderer', ({renderer}) => { <del> registerRenderer(renderer); </del> <ins> registerRenderer(renderer, hook); </ins> updateRequiredBackends(); });

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: warnedStyleNames[name] = true; warning( false, <del> 'Unsupported style property ' + name + '. Did you mean ' + camelizeStyleName(name) + '?' </del> <ins> 'Unsupported style property %s. Did you mean %s?', name, camelizeStyleName(name) </ins> ); };

Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks


Question: import React from 'react'; import {isForwardRef} from 'react-is'; <del> import {warnAboutDeprecatedLifecycles} from 'shared/ReactFeatureFlags'; </del> import describeComponentFrame from 'shared/describeComponentFrame'; import getComponentName from 'shared/getComponentName'; import emptyObject from 'fbjs/lib/emptyObject'; import invariant from 'fbjs/lib/invariant'; <del> import lowPriorityWarning from 'shared/lowPriorityWarning'; </del> import shallowEqual from 'fbjs/lib/shallowEqual'; import checkPropTypes from 'prop-types/checkPropTypes'; <del> import warning from 'fbjs/lib/warning'; let didWarnAboutLegacyWillMount; let didWarnAboutLegacyWillReceiveProps; let didWarnAboutLegacyWillUpdate; let didWarnAboutUndefinedDerivedState; let didWarnAboutUninitializedState; let didWarnAboutLegacyLifecyclesAndDerivedState; if (__DEV__) { if (warnAboutDeprecatedLifecycles) { didWarnAboutLegacyWillMount = {}; didWarnAboutLegacyWillReceiveProps = {}; didWarnAboutLegacyWillUpdate = {}; } didWarnAboutUndefinedDerivedState = {}; didWarnAboutUninitializedState = {}; didWarnAboutLegacyLifecyclesAndDerivedState = {}; } </del> class ReactShallowRenderer { static createRenderer = function() {

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


Question: }, "dependencies": { "base62": "~0.1.1", <del> "commoner": "~0.8.0", </del> <ins> "commoner": "~0.8.3", </ins> "esprima": "https://github.com/facebook/esprima/tarball/a3e0ea3979eb8d54d8bfade220c272903f928b1e", "recast": "~0.4.8", "source-map": "~0.1.22"

Basically what the title says. After install react-tools, using jsx -w <srcdir<destdirwill correctly detect existing files (but not transform them), and upon any write to any watched file jsx will exit with error code 1. Commoner tests all pass. Exact steps I followed, in Ubuntu 12.10: 0) Install via manual instructions at for Ubuntu/Mint 1) Install react-tools with 'sudo npm install -g react-tools' 2) Create file in <src, as described by the Getting Started tutorial. 3) In a new terminal, jsx -w <src<dest4) Edit and add a comment. 5) Notice that jsx exited, echo $? prints 1. akrieger ls js/ akrieger ls html/js/ akrieger jsx -w js/ html/js/ ["helloworld"] <edit , save editakrieger 1 akrieger ls html/js/ akrieger
Hypothesis: The only thing that keeps commoner from exiting in mode right now is the option passed to . That means the process will stay alive while there are any files left to watch. But some text editors save files by deleting and then re-writing them, which causes to un-watch the file (because the original inode that inotify cared about got discarded). When there's only one file, unwatching it causes Node to think no files need to be watched, so the process exits. cc
Opened a new Commoner issue: Even though said the Commoner tests pass for him, that's only because mode test coverage is… lacking. :frowning:
That didn't seem to work for me, unless the file is supposed to be a valid JSX file with something to transform.
It also doesn't solve the issue that jsx doesn't seem to be doing any static transformation anyway, even in the example getting started tutorial.
That's another regrettable but known issue: I suspect you're missing the comment at the top of the file (which won't be necessary soon, but currently is still important). cc
I copy pasted the sample code exactly: <code/ React.DOM */ React.renderComponent( blah blah );</code
Just to try something else: can take a single file name on the command line: . Does that also not show any transformations? Or did you try that already?
bin/jsx does the right thing.

Furthermore, if I have a file named in the destination directory, it is deleted when I try to run jsx on the source and dest directory, in either watch or go mode.
The deletion is by design, at least. The files that end up in the output directory are actually hard-linked with master versions that are kept (by default) in . Each build unlinks and then relinks the files in the output directory, so if the relink fails it will look like the file was just deleted. Not sure why the relinking might be failing. In case is on a different device from , you could try relocating the cache:
Yeah, they are on different devices. Moving the cache dir worked. Thanks!
Accidental close, sorry. Still need to mitigate that cache dir problem.
How important is the cache behavior? Could we disable it? I'd trade perf for ease of use with this tool
:thumbsup: to what said. I'd also take defaulting the cachedir to the src/current dir (I think this is how sass does it's cache)
pretty important; the incremental speedup is significant for a codebase the size of It's a one-line change to switch the default location, and it won't break anything for anyone. Kicking myself now because I actually considered whether ~/.commoner was likely ever to be a different device, and clearly I guessed wrong :(
I wonder if the requirements that we need for the react codebase are the same as those for end users. I think most people just want a simple syntax transform and watcher ala coffee script.
Also +1 on just moving the cache dir :)
true, but I don't think we can pretend that is a fully-featured source transform tool if it doesn't do any caching (coffeescript and sass clearly suggest that caching is worthwhile for enough people) The original location of the cache directory was , but I moved it when I support for printing the transformed code to STDIN, in which case there's no . Definitely okay with skipping the cache logic in that case.
So I've been looking through various implementations of Dir watchers (gaze, chokidar) in NodeJS and they're all pretty clowny - a pretty easy test case that breaks them is making a new directory and adding files to that directory.

So since someone on the internet was wrong, I wrote another FS watcher last night that I think is way more stable: I'll try to merge this new file watcher with the transformer I made a couple days ago () and see what happens just as proof of concept. - I'll probably have something for you to play w/ in an hour or two =]
I had pretty good results with a makefile and running make every 2s :P
now you're trolling me :P
I can't wait.
Not trolling; it's very reliable and easy to reason about. Is comparing file mtimes to determine if they need to be rebuilt bad relative to a module cache?
give a shot - still a work-in-progress, but lmk how it goes
Dear Your question deserves a careful response. I know this looks long-winded, but if you read it through you'll know everything that I was thinking. The primary virtue of the module cache is that the cache filenames are hashes of all the relevant input variables: source, module name, build steps, configuration properties, Commoner version, and more. Change any one of those input variables and you get a different hash. If you find a file called in the module cache, you can be completely certain that the cached file contains the right contents. I believe that's a useful guarantee. A secondary benefit is that old versions of a file don't go away just because the file was recently rebuilt. If you revert a file to a version that has ever been built before, you don't have to rebuild it again. In order to make the same promise under the strategy, you'd have to find some way of storing all those distinct versions, and I'm confident the method you would come up with would closely resemble my hashing strategy. It's what every sensible version control system does. The goal of both strategies is to determine whether you can trust the contents of a file that was built some time in the past. This decision is completely reliable under a hashing strategy, and if it ever fails then there must be some additional piece of information that you neglected to incorporate into the hash. None of the bugs that I've fixed in Commoner had anything to do with module cache inconsistency. When's the last time you had to wipe your module cache? And no, doesn't qualify, because I made sure it left the cache untouched.

With that background, let me answer your orginal question: "Is comparing file s to determine if they need to be rebuilt bad relative to a module cache?" Yes, because the only input variables considered by the strategy are (name of source file, of source file), which allows you to avoid rebuilding the file if corresponding output file has a later , and know no other input variables have changed in the meantime, such as build steps, configuration properties, new files /removed whose presence/absence affects the build, independent build processes racing to update files in the output directory, etc. Requirement 1 is too strong because you don't necessarily have to rebuild source files that appear newer than their output files (see my second paragraph above). Requirement 2 is too strong because you don't have to "know" any of those things if they can be accounted for automatically, as they are under the hashing strategy. Is the strategy good enough? Maybe it is for you, because you know how to spot signs of inconsistency and you have trained yourself to predict when a is finally necessary. I don't think we can expect the same of new users of React. They're much more likely to attribute subtle problems to the library itself instead of guessing that the build tool messed up. Sometimes we reinvent the wheel just so that we know exactly how the wheel we're using works, quirks and all. I'm guilty of this myself, but in my defense I really am trying to get us to a point where we don't have to make any apologies at all for the way our tools work. I know there are still bugs in Commoner, but I'm committed to squashing all of them.
I'm not hating on commoner. It's an excellent CommonJS build system and is totally the right choice to build react and any jsx project that uses CommonJS modules with transforms. The problem is that users think it is a simple syntax transform (like coffee?) when in reality it doesn't behave that way. Specifically it assumes that everything you're desugaring is a CommonJS module and it assumes specifics of the implementations path resolution methods, which in requirejs, browserify and haste are all different, by relativizing. If you aren't using CommonJS and define your own unrelated require() function the arguments will get rewritten, weird missing module warnings will fire and fake modules will be created.

It's actually really freaking awesome to have this tooling for CommonJS projects but really confusing if you're not in a CommonJS project or using a different module resolver. Some of the annoyances we've with r.js are because it tries to be too clever in this area (we have eval('req'+'uire')(...) somewhere in the insta codebase because of this). As a user since I know jsx is willing to rewrite my code I find it hard to predict exactly how it will transform. What if instead jsx had a --relativize option that we disabled by default and it just treated everything like a file and transformed it, either with a cache or based on mtime? We'd continue to use the option on react itself and perhaps even advertise commoner+a browser packager (brigade?) as our recommended module system since they'll likely want debranching and other goodies even though they don't know it yet :)
The original issue still needs fixing, by the way. Still working on that.
One of the reasons I was not able to get the jsx transformed files was I didnt close the terminal window first time after installation. I closed the terminal window and re-opened it again and then I was able to transform any JSX file located anywhere on my disk to any folder. :) possible solution.

Trying to run jsx to build into a subdir seems to just exit with no error message: (public/js does exist) However, if run in directly in public it works without a hitch:
Are there any files in yet? Also potentially useful: what are you running, and what OS?
There is a file in src which builds when not using a subdir in the public dir. node version is 0.8.23 and im on OS X Mountain Lion
Installed 0.8.23 but no luck reproducing. Will try on a Mountain Lion machine tomorrow. Thanks for the report. Do you see this failure with an empty file? If using an empty file makes the failure go away, perhaps you can try cutting out different parts of the file to figure out the minimal contents that trigger the failure? It could be a problem with on Mountain Lion, though. That's my hunch.
One more idea: the module cache might have gotten into a bad state somehow. Try clearing it by deleting the directory ?
The same file builds fine if I use (note the lack of public/js). Deleting that directory didn't work for me.
I know this is still broken. Still working on a fix.
:heart:
I had same problem on ubuntu. Yesterday "jsx --watch" worked just fine for me. Today when I ssh-ed again and ran "jsx --watch reactjs/ js/" it just silently does nothing.
- I was having issues w/ vim file writes not being caught so I hacked together - Feel free to try it and let me know if it works (Haven't had the time to test on Ubuntu yet...) - We might use the file watcher in that repo in Commoner / JSX in the future.
:+1: Work like a charm. Thank you very much!
Ok. I think I now know what the issue is. jsx created a file in the output directory. If that file is still there when running jsx again it will quick silently.
Awesome!


Question: '* put files on CDN', '* push changes to git repositories', '* publish npm module (`npm publish .`)', <del> '* publish gem (`gem push react-source-' + VERSION + '.gem`)', </del> '* announce it on FB/Twitter/mailing list', ].forEach(function(ln) { grunt.log.writeln(ln);

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


Question: --- <ins> ### 4.27.8 May 17, 2023 #### Bugfixes * Fixed duplicated backend activation with multiple renderers ([hoxyq](https://github.com/hoxyq) in [#26807](https://github.com/facebook/react/pull/26807)) --- </ins> ### 4.27.7 May 4, 2023

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


Question: return { memoizedState: hook.memoizedState, <del> baseState: hook.memoizedState, </del> <ins> baseState: hook.baseState, </ins> queue: hook.queue, baseUpdate: hook.baseUpdate,

Do you want to request a feature or report a bug? Report a bug What is the current behavior? There are cases where actions dispatched by 's dispatch function are reduced twice (in concurrent mode). As far as I can tell from my first quick read of the code of react-dom (so I might be totally wrong!), this happens, when a higher priority action is to a queue that already contains lower priority actions. On the first run, that is caused by for example an onClick handler (higher priority), the dispatched action is appended to the queue. On processing the queue the lower priority actions (for example from setInterval events) are ignored and the "onClick action" is reduced, but stays on the end of the queue, so that on the next time the queue is processed, that action gets reduced a second time. See a testcase at: Pressing the button increments the button (most of the time not always, depending if 'TICK' actions are in the queue) by two. What is the expected behavior? I'd expect a dispatched action to be only reduced once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with React 16.7.0-alpha.2 on Chrome (70.0.3538.110) and Safari (12.0.1) both on macOs
This does look like a bug. Want to dig into it?
I'd love to, but I am not sure I understand the implications on messing with the action queue, there are quit a lot of special cases and as I wrote that was my first read of any react implementation code :) Also it might take me a week or so, as I am pretty busy at the moment.
Actually I was wrong, the higher priority action should be reduced twice, the error is in where the memoizedState (action applied) overwrites the baseState (which should stay the last state before updates were skipped). I have a test that reproduced my bug and is fixed by correcting (while the other tests are still passing). I'll have that cleaned up tomorrow or Monday, so I'd take this issue.
Nice find :-)


Question: "url": "https://github.com/facebook/react" }, "dependencies": { <del> "commoner": "~0.8.14", </del> <ins> "commoner": "~0.9.0", </ins> "esprima-fb": "~2001.1001.0-dev-harmony-fb", "jstransform": "~2.0.2" },

When I run jsx --watch src/ build/ it compiles the jsx files and create a file in the build directory. On the next jsx file modification, the jsx process crashes. Once the is present, jsx won't compile jsx files even when ran manually. I use OSX Maverick and jsx 0.8.13.
AFAIK this is a "bug" with or whatever JSX relies on to expose that feature. Just make sure to close the watch instance instead of just closing the terminal/powering down and it should be fine.
Does it work again if you remove the file?
Yes it does. Oh or wait, the crashing.
It seems like there are two ways of fixing this. We can either out why is not cleaning up the file when the process exits, or the functionality and just hope people don't accidentally have multiple processes targeting the same output directory. I'm pretty comfortable with option 2, honestly. Thoughts,
Yeah, no lock seems fine for me, it could warn if it was found perhaps? Another thing to mention that has been happening to me, I'm using React through a Linux VM and accessing the filesystem through samba. When saving a file it immediately triggers a recompile before the file has finished saving, causing it to error. Shortly after it recompiles it again, so no harm, but it's worth noting.
I'm fine with no locking. I didn't even know that existed. Do what works!


Question: object-assign "^4.1.0" prop-types "^15.5.10" <ins> "react-dom-16-8@npm:react-dom@16.8.0": version "16.8.0" resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-16.8.0.tgz#18f28d4be3571ed206672a267c66dd083145a9c4" integrity sha512-dBzoAGYZpW9Yggp+CzBPC7q1HmWSeRc93DWrwbskmG1eHJWznZB/p0l/Sm+69leIGUS91AXPB/qB3WcPnKx8Sw== dependencies: loose-envify "^1.1.0" object-assign "^4.1.1" prop-types "^15.6.2" scheduler "^0.13.0" </ins> react-is@^16.12.0, react-is@^16.8.1: version "16.13.1" resolved "https://registry.yarnpkg.com/react-is/-/react-is-16.13.1.tgz#789729a4dc36de2999dc156dd6c1d9c18cea56a4"

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: // logging too much when using transferPropsTo. warning( standardName == null, <del> 'Unknown DOM property ' + name + '. Did you mean ' + standardName + '?' </del> <ins> 'Unknown DOM property %s. Did you mean %s?', name, standardName </ins> ); };

Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks


Question: } } <del> // For IE8 and IE9. </del> function handleEventsForInputEventIE( topLevelType, topLevelTarget,

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

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


Question: 'use strict'; import { <ins> REACT_ASYNC_MODE_TYPE, </ins> REACT_CONCURRENT_MODE_TYPE, REACT_CONTEXT_TYPE, REACT_ELEMENT_TYPE,

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

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


Question: // events and have it go through ReactEventTopLevelCallback. Since it // doesn't, we manually listen for the propertychange event and so we // have to enqueue and process the abstract event manually. <del> EventPluginHub.enqueueAbstractEvents(abstractEvent); EventPluginHub.processAbstractEventQueue(); </del> <ins> EventPluginHub.enqueueEvents(abstractEvent); EventPluginHub.processEventQueue(); </ins> } } };

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: opacity: true, order: true, orphans: true, <ins> scale: true, </ins> tabSize: true, widows: true, zIndex: true,

we have property in css . In Plain JavaScript, we can directly pass a Number type and change the scale value like below scale:2.5 simulates the shorthand for transform: scale(2.5) Similarly I tried to do the Above in React, but it does not work as of now and only can work with string, the fix i took is adding it as a unitless Number in the file since it accepts the css properties accepting number , doing the same and running the fixtures standalone file , it is working the way as i expected Before the changes https://user- After the changes https://user-
cc


Question: selection.removeAllRanges(); selection.addRange(range); clipboard.writeText(event.target.textContent); <ins> const $promptDiv = $("#box-content-prompt"); const $confirmationDiv = $("#box-content-confirmation"); </ins> $promptDiv.classList.add('hidden'); $confirmationDiv.classList.remove('hidden');

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


Question: "README.md", "index.js", "cjs/", <del> "umd/" </del> <ins> "umd/", "Circle.js", "Rectangle.js", "Wedge.js" </ins> ], "browserify": { "transform": [

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: itemRef: MUST_USE_ATTRIBUTE, // property is supported for OpenGraph in meta tags. property: null, <ins> // IE-only attribute that specifies security restrictions on an iframe // as an alternative to the sandbox attribute on IE<10 security: MUST_USE_ATTRIBUTE, </ins> // IE-only attribute that controls focus behavior unselectable: MUST_USE_ATTRIBUTE, },

The attribute allows for restrictions to be placed on iframes, regardless of domain. It's useful if you're dealing with IE versions less than 10 that don't have the attribute. More info: (v=vs.85).aspx


Question: } if (propKey === STYLE) { if (nextProp) { <ins> if (__DEV__) { checkAndWarnForMutatedStyle( this._previousStyleCopy, this._previousStyle, this ); this._previousStyle = nextProp; } </ins> nextProp = this._previousStyleCopy = assign({}, nextProp); } if (lastProp) {

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


Question: "manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Chrome Developer Tools.", <del> "version": "5.3.1", "version_name": "5.3.1", </del> <ins> "version": "6.0.0", "version_name": "6.0.0", </ins> "minimum_chrome_version": "102", "icons": { "16": "icons/16-production.png",

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: var fakeNode = document.createElement('react'); ReactErrorUtils.invokeGuardedCallback = function(name, func, a, b) { var boundFunc = func.bind(null, a, b); <del> fakeNode.addEventListener(name, boundFunc, false); </del> <ins> var evtType = `react-${name}`; fakeNode.addEventListener(evtType, boundFunc, false); </ins> var evt = document.createEvent('Event'); <del> evt.initEvent(name, false, false); </del> <ins> evt.initEvent(evtType, false, false); </ins> fakeNode.dispatchEvent(evt); <del> fakeNode.removeEventListener(name, boundFunc, false); </del> <ins> fakeNode.removeEventListener(evtType, boundFunc, false); </ins> }; } }

Count up with 0.14.0 But can't count up 0.14.1 I got this issue on IE 10 and 11 + Windows 8, 7. And Windows 10 + IE 11 is move fine.
:+1: I'm seeing the same issue when I use react-dom 0.14.1
:+1: same
cc seems bad.
Fix incoming. Worth noting (as reminded me) that this is only an issue in dev mode.
:+1:
:+1: Makes our app difficult to test on Windows 7 / 8. I can confirm that switching to production mode does resolve it for us.
Yea sorry about the issues, we'll be shipping 0.14.2 tomorrow with this fixed.
:+1:
Is this related only to anchor tags, or other elements as well? I've seen this when applying onClick to div elements as well as anchors in IE10 and IE11.
All elements.


Question: <del> module React module Source def self.bundled_path_for(build) File.expand_path("../../../build/#{build}", __FILE__) end end end </del>

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


Question: ); if (!batchingStrategy.isBatchingUpdates) { <del> var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(); transaction.perform( component.performUpdateIfNecessary, component, transaction ); ReactUpdates.ReactReconcileTransaction.release(transaction); callback && callback.call(component); </del> <ins> batchingStrategy.batchedUpdates(enqueueUpdate, component, callback); </ins> return; }

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: ```css .example-leave { <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> transition: opacity .5s ease-in; }

Hello, Today I have spotted the bug(?) in IE10/IE11: while setting the inner HTML on any element (, , ) using property the browser will raise an error . I use this with SSR, but the actual HTML received from the server is good, so probably there's a problem with func. Some code: where is some string that contains HTML. !
Hey! This was fixed in and is a known issue. A fix should be out in the next release. However thank you for the great write up!
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
Hi Dan, everything is working now, thank you!


Question: } } <del> React.version = '0.14.0-alpha'; </del> module.exports = React;

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

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

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

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

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

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

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


Question: ); } }); <ins> JQueryMobilePage = React.createFactory(JQueryMobilePage); </ins> /** Application page one component. */ var PageOneContent = 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: // Most of the real functionality is covered in other unit tests, this just // makes sure we're wired up correctly. describe('ReactTransitionGroup', function() { <ins> var container; </ins> beforeEach(function() { React = require('React'); ReactTransitionGroup = require('ReactTransitionGroup'); mocks = require('mocks'); <ins> container = document.createElement('div'); </ins> }); it('should warn after time with no transitionend', function() { <del> var container; var a; container = document.createElement('div'); a = React.renderComponent( </del> <ins> var a = React.renderComponent( </ins> <ReactTransitionGroup transitionName="yolo"> <span key="one" id="one" /> </ReactTransitionGroup>,

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


Question: // componentDidUpdate) but we need to check here too in order to catch // updates enqueued by setState callbacks. while (dirtyComponents.length) { <ins> var allUnmounted = true; for (var i = 0, l = dirtyComponents.length; i < l; i++) { if (dirtyComponents[i].isMounted()) { allUnmounted = false; break; } } if (allUnmounted) { // All the "dirty" components are unmounted, which probably means that // they were marked dirty due to setState calls in componentWillMount // handlers and the components are currently in the process of mounting. // `runBatchedUpdates` will be a noop. In that case, initializing the // DOM-dependent ReactReconcileTransaction is thus not what we want to // do, especially when using server rendering, so we skip it. dirtyComponents.length = 0; return; } </ins> var transaction = ReactUpdatesFlushTransaction.getPooled(); transaction.perform(runBatchedUpdates, null, transaction); ReactUpdatesFlushTransaction.release(transaction);

After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!


Question: import is from 'shared/objectIs'; import {markWorkInProgressReceivedUpdate} from './ReactFiberBeginWork'; import {requestCurrentSuspenseConfig} from './ReactFiberSuspenseConfig'; <del> import {getCurrentPriorityLevel} from './SchedulerWithReactIntegration'; </del> <ins> import { UserBlockingPriority, NormalPriority, runWithPriority, getCurrentPriorityLevel, } from './SchedulerWithReactIntegration'; </ins> const {ReactCurrentDispatcher, ReactCurrentBatchConfig} = ReactSharedInternals;

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: ); }, ); <ins> // Regression test for https://github.com/facebook/react/issues/14188 it('can call findDOMNode() in a suspended component commit phase', async () => { const log = []; const Lazy = React.lazy( () => new Promise(resolve => resolve({ default() { return 'lazy'; }, }), ), ); class Child extends React.Component { componentDidMount() { log.push('cDM ' + this.props.id); ReactDOM.findDOMNode(this); } componentDidUpdate() { log.push('cDU ' + this.props.id); ReactDOM.findDOMNode(this); } render() { return 'child'; } } const buttonRef = React.createRef(); class App extends React.Component { state = { suspend: false, }; handleClick = () => { this.setState({suspend: true}); }; render() { return ( <React.Suspense fallback="Loading"> <Child id="first" /> <button ref={buttonRef} onClick={this.handleClick}> Suspend </button> <Child id="second" /> {this.state.suspend && <Lazy />} </React.Suspense> ); } } ReactDOM.render(<App />, container); expect(log).toEqual(['cDM first', 'cDM second']); log.length = 0; buttonRef.current.dispatchEvent(new MouseEvent('click', {bubbles: true})); await Lazy; expect(log).toEqual(['cDU first', 'cDU second']); }); </ins> });

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? I have a component which listens for resize events (via a BlueprintJS ResizeSensor). When loading a component dynamically with / , an exception occurs as the resize sensor appears to be unmounted: The resize sensor . Demo: Related: What is the expected behavior? No exception is thrown. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with: React 16.6.1, fails React 16.6.0, works
Can you test if it works on master?
Nope, it's broken on master, and after bisecting, I confirmed the regression was caused by EDIT: Something else I found is that before the regression, doesn't execute, but now it does. EDIT 2: Yeah, throws when invoked with a suspended component, here's how you can reproduce. This is true both before and after the aforementioned PR, so in any case it looks like it helped us discover this :smile:
EDIT: Something else I found is that before the regression, ResizeSensor.componentDidUpdate doesn't execute, but now it does. This sounds like a separate problem, can you provide a test case for it?
Here's a minimal repro with ReactDOM:
Okay, so a part of this is covered by It got first broken by and got fixed in . However I think repro case in might be a separate issue. Looking into it.
This sounds like a separate problem, can you provide a test case for it? Welp, turns out I'm wrong, I actually made a mistake when mocking which resulted in it not being called :stuckouttongueclosedeyes:
Another reproducible example: When does it throw: 16.6.0: never 16.6.1: on every "display lazy" click 16.7.0 until 16.8.6: on every "display lazy" click if the number of "force update" clicks is odd (meaning even number of render?)
This was likely fixed in Can you verify on master?
Yes, current fixes for me.
This will get into the next release then.
Seems it still happens.

~I tried to get mini reproduce but it seems happened in complex environment.~ User report reproduce: Quick click the nav item will throw with ref: Update: Create a mini reproduce about this:
Sorry, we didn’t release the fix yet.
any ETA on when this will be available?
We are blocked by this, too (without a pretty significant workaround). Any sense of a release timeframe? Is there some way to find out (in general) when the "next" release is? Sorry if this is covered somewhere.. For the record, this is surfacing for us through Semantic UI React Dropdown. So we're beholden to them as well, but they point us here for the fix. :)
any new updates?
We've published of all packages, which includes this fix. It is likely to be a release candidate for . You can give it a try now and see whether it resolves the issue for you. Thanks.
(You should still ask packages to migrate away from though as it's eventually going to get deprecated.)
0 hadn't fix this bug!
All reproductions linked in this issue ( and ) no longer crash with 16.9. If you still encounter this error message with 16.9 please open a new issue.


Question: Dev build with warnings: <https://fb.me/react-dom-0.14.0-rc1.js> Minified build for production: <https://fb.me/react-dom-0.14.0-rc1.min.js> <del> These builds are also available in the `react` and `react-dom` packages on bower. </del> <ins> These builds are also available in the `react` package on bower. </ins> ## Changelog

I tried doing the following to pick up react-dom: However, it said that the only version available was Poking around on Github yielded a repo called that appears to be linked to Bower. I'm guessing this isn't the right library; what's the dependency installation story going to look like with Bower?
Never mind, just found that it shipped in the same package. However, the documentation is misleading on the :
Thanks, we should fix that.


Question: */ getValue: function(input) { if (input.props.valueLink) { <del> _assertLink(input); </del> <ins> _assertValueLink(input); </ins> return input.props.valueLink.value; } return input.props.value;

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


Question:
hooks
  {enableHookNameParsing && !parseHookNames && (   {enableHookNameParsing && (!parseHookNames || hookParsingFailed) && (  <Toggle  className={hookParsingFailed ? styles.ToggleError : null}  isChecked={parseHookNamesOptimistic}  isDisabled={parseHookNamesOptimistic}   isDisabled={parseHookNamesOptimistic || hookParsingFailed}  onChange={handleChange}  title={ parseHookNames ? 'Parse hook names' : 'Parse hook names (may be slow)' }>   title={toggleTitle}>  <ButtonIcon type="parse-hook-names" /> </Toggle> )}

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


Question: } const {types: t} = babel; <ins> const refreshReg = t.identifier(opts.refreshReg || '$RefreshReg$'); const refreshSig = t.identifier(opts.refreshSig || '$RefreshSig$'); </ins> const registrationsByProgramPath = new Map(); function createRegistration(programPath, persistentID) {

Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.


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 Rectangle.art * @typechecks * * Example usage: * <Rectangle *   width={50} *   height={50} *   stroke="green" *   fill="blue" * /> * * Additional optional properties: *   (Number) radius *   (Number) radiusTopLeft *   (Number) radiusTopRight *   (Number) radiusBottomLeft *   (Number) radiusBottomRight * */ 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; /** * Rectangle is a React component for drawing rectangles. Like other ReactART * components, it must be used in a <Surface>. */ var Rectangle = createReactClass({ displayName: 'Rectangle', propTypes: { width: PropTypes.number.isRequired, height: PropTypes.number.isRequired, radius: PropTypes.number, radiusTopLeft: PropTypes.number, radiusTopRight: PropTypes.number, radiusBottomRight: PropTypes.number, radiusBottomLeft: PropTypes.number, }, render: function render() { var width = this.props.width; var height = this.props.height; var radius = this.props.radius ? this.props.radius : 0; // if unspecified, radius(Top|Bottom)(Left|Right) defaults to the radius // property var tl = this.props.radiusTopLeft ? this.props.radiusTopLeft : radius; var tr = this.props.radiusTopRight ? this.props.radiusTopRight : radius; var br = this.props.radiusBottomRight ? this.props.radiusBottomRight : radius; var bl = this.props.radiusBottomLeft ? this.props.radiusBottomLeft : radius; var path = Path(); // for negative width/height, offset the rectangle in the negative x/y // direction. for negative radius, just default to 0. if (width < 0) { path.move(width, 0); width = -width; } if (height < 0) { path.move(0, height); height = -height; } if (tl < 0) { tl = 0; } if (tr < 0) { tr = 0; } if (br < 0) { br = 0; } if (bl < 0) { bl = 0; } // disable border radius if it doesn't fit within the specified // width/height if (tl + tr > width) { tl = 0; tr = 0; } if (bl + br > width) { bl = 0; br = 0; } if (tl + bl > height) { tl = 0; bl = 0; } if (tr + br > height) { tr = 0; br = 0; } path.move(0, tl); if (tl > 0) { path.arc(tl, -tl); } path.line(width - (tr + tl), 0); if (tr > 0) { path.arc(tr, tr); } path.line(0, height - (tr + br)); if (br > 0) { path.arc(-br, br); } path.line(-width + (br + bl), 0); if (bl > 0) { path.arc(-bl, -bl); } path.line(0, -height + (bl + tl)); return React.createElement(Shape, _extends({}, this.props, {d: path})); }, }); module.exports = Rectangle; </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: set: function(value) { warning( false, <del> 'Don't set the ' + key + ' property of the React element. Instead, ' + 'specify the correct value when initially creating the element.' </del> <ins> 'Don't set the %s property of the React element. Instead, ' + 'specify the correct value when initially creating the element.', key </ins> ); this._store[key] = value; }

Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks


Question: sourceMap: this.options.sourceMapInline, stripTypes: this.options.stripTypes, es6module: this.options.es6module, <del> nonStrictEs6Module: this.options.nonStrictEs6Module </del> <ins> nonStrictEs6Module: this.options.nonStrictEs6Module, target: this.options.target </ins> }; return transform(source, options); });

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


Question: } } <del> class Pure extends React.PureComponent { render() { return this.props.children; } } </del> const renderer = ReactTestRenderer.create( <React.Profiler id="outer" onRender={callback}> <Updater> <del> <React.Profiler id="middle" onRender={callback}> <Pure> <React.Profiler id="inner" onRender={callback}> <div /> </React.Profiler> </Pure> </del> <ins> <React.Profiler id="inner" onRender={callback}> <div /> </ins> </React.Profiler> </Updater> </React.Profiler>, ); // All profile callbacks are called for initial render <del> expect(callback).toHaveBeenCalledTimes(3); </del> <ins> expect(callback).toHaveBeenCalledTimes(2); </ins> callback.mockReset();

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


Question: var shouldUpdateReactComponent = require('shouldUpdateReactComponent'); var warning = require('warning'); <ins> var MIXINS_KEY = keyOf({mixins: null}); </ins> /** * Policies that describe methods in `ReactCompositeComponentInterface`. */

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: }; case 'string': <del> return data.length <= 500 ? data : data.slice(0, 500) + '...'; </del> <ins> isPathAllowedCheck = isPathAllowed(path); if (isPathAllowedCheck) { return data; } else { return data.length <= 500 ? data : data.slice(0, 500) + '...'; } </ins> case 'bigint': cleaned.push(path);

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