Question: * The result should be HTML-escaped before insertion into the DOM. * * @param {object} styles <ins> * @param {ReactDOMComponent} component </ins> * @return {?string} */ <del> createMarkupForStyles: function(styles) { </del> <ins> createMarkupForStyles: function(styles, component) { </ins> var serialized = ''; for (var styleName in styles) { if (!styles.hasOwnProperty(styleName)) {

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


Question: expect(/style=".*"/.test(root.innerHTML)).toBe(false); }); <ins> it('should warn when using hyphenated style names', function() { spyOn(console, 'warn'); expect(CSSPropertyOperations.createMarkupForStyles({ 'background-color': 'crimson' })).toBe('background-color:crimson;'); expect(console.warn.argsForCall.length).toBe(1); expect(console.warn.argsForCall[0][0]).toContain('backgroundColor'); }); it('should warn when updating hyphenated style names', function() { spyOn(console, 'warn'); var root = document.createElement('div'); var styles = { '-ms-transform': 'translate3d(0, 0, 0)', '-webkit-transform': 'translate3d(0, 0, 0)' }; React.renderComponent(<div />, root); React.renderComponent(<div style={styles} />, root); expect(console.warn.argsForCall.length).toBe(2); expect(console.warn.argsForCall[0][0]).toContain('msTransform'); expect(console.warn.argsForCall[1][0]).toContain('WebkitTransform'); }); </ins> });

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: React = require('react'); ReactDOM = require('react-dom'); ReactDOMServer = require('react-dom/server'); <del> ReactDOMFeatureFlags = require('ReactDOMFeatureFlags'); </del> ReactTestUtils = require('react-dom/test-utils'); });

When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.


Question: } else { if (propKey === STYLE) { if (propValue) { <ins> if (__DEV__) { // See `_updateDOMProperties`. style block this._previousStyle = propValue; } </ins> propValue = this._previousStyleCopy = assign({}, props.style); } propValue = CSSPropertyOperations.createMarkupForStyles(propValue);

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: require('jstransform/visitors/es7-spread-property-visitors'); var react = require('./transforms/react'); var reactDisplayName = require('./transforms/reactDisplayName'); <ins> var reservedWords = require('jstransform/visitors/reserved-words-visitors'); </ins> /** * Map from transformName => orderedListOfVisitors.

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:
'    in Foo (at **)', ); });  if (ReactDOMFeatureFlags.useFiber) { describe('with new features', () => { beforeEach(() => { require('ReactFeatureFlags').disableNewFiberFeatures = false; }); it('warns on function as a return value from a function', () => { function Foo() { return Foo; } spyOn(console, 'error'); var container = document.createElement('div'); ReactDOM.render(<Foo />, container); expectDev(console.error.calls.count()).toBe(1); expectDev(normalizeCodeLocInfo(console.error.calls.argsFor(0)[0])).toBe( 'Warning: Functions are not valid as a React child. This may happen if ' + 'you return a Component instead of <Component /> from render. ' + 'Or maybe you meant to call this function rather than return it.n' + '    in Foo (at **)', ); }); it('warns on function as a return value from a class', () => { class Foo extends React.Component { render() { return Foo; } } spyOn(console, 'error'); var container = document.createElement('div'); ReactDOM.render(<Foo />, container); expectDev(console.error.calls.count()).toBe(1); expectDev(normalizeCodeLocInfo(console.error.calls.argsFor(0)[0])).toBe( 'Warning: Functions are not valid as a React child. This may happen if ' + 'you return a Component instead of <Component /> from render. ' + 'Or maybe you meant to call this function rather than return it.n' + '    in Foo (at **)', ); }); it('warns on function as a child to host component', () => { function Foo() { return
{Foo}
; } spyOn(console, 'error'); var container = document.createElement('div'); ReactDOM.render(<Foo />, container); expectDev(console.error.calls.count()).toBe(1); expectDev(normalizeCodeLocInfo(console.error.calls.argsFor(0)[0])).toBe( 'Warning: Functions are not valid as a React child. This may happen if ' + 'you return a Component instead of <Component /> from render. ' + 'Or maybe you meant to call this function rather than return it.n' + '    in span (at **)n' + '    in div (at **)n' + '    in Foo (at **)', ); }); it('does not warn for function-as-a-child that gets resolved', () => { function Bar(props) { return props.children(); } function Foo() { return <Bar>{() => 'Hello'}</Bar>; } spyOn(console, 'error'); var container = document.createElement('div'); ReactDOM.render(<Foo />, container); expect(container.innerHTML).toBe('Hello'); expectDev(console.error.calls.count()).toBe(0); }); }); }  });

When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.


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

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


Question: 'use strict'; <ins> var DisabledInputUtils = require('DisabledInputUtils'); </ins> var LinkedValueUtils = require('LinkedValueUtils'); var ReactDOMComponentTree = require('ReactDOMComponentTree'); var ReactUpdates = require('ReactUpdates');

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


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

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


Question: if (parseHookNames) { if ( inspectedElement !== null && <del> inspectedElement.type === ElementTypeFunction && </del> inspectedElement.hooks !== null && loadHookNamesFunction !== null ) {

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: // warns when classic properties are defined on the instance, // but does not invoke them. var getInitialStateWasCalled = false; <ins> var getDefaultPropsWasCalled = false; </ins> class ClassicProperties extends React.Component { contextTypes = {}; propTypes = {}; <ins> getDefaultProps() { getDefaultPropsWasCalled = true; return {}; } </ins> getInitialState() { getInitialStateWasCalled = true; return {};

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


Question: }); describe('inline errors and warnings', () => { <del> // Some actions require the Fiber id. // In those instances you might want to make assertions based on the ID instead of the index. function getErrorsAndWarningsForElement(id: number) { const index = ((store.getIndexOfElementID(id): any): number); return getErrorsAndWarningsForElementAtIndex(index); } </del> async function getErrorsAndWarningsForElementAtIndex(index) { const id = ((store.getElementIDAtIndex(index): any): number); <ins> if (id == null) { throw Error(`Element at index "${index}"" not found in store`); } </ins> let errors = null; let warnings = null;

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


Question: }); }); <ins> it('inspecting nested renderers should not throw', async () => { // Ignoring react art warnings spyOn(console, 'error'); const ReactArt = require('react-art'); const ArtSVGMode = require('art/modes/svg'); const ARTCurrentMode = require('art/modes/current'); store.componentFilters = []; ARTCurrentMode.setCurrent(ArtSVGMode); const {Surface, Group} = ReactArt; function Child() { return ( <Surface width={1} height={1}> <Group /> </Surface> ); } function App() { return <Child />; } await utils.actAsync(() => { legacyRender(<App />, document.createElement('div')); }); expect(store).toMatchInlineSnapshot(` [root] ▾ <App> ▾ <Child> ▾ <Surface> <svg> [root] <Group> `); const inspectedElement = await inspectElementAtIndex(4); expect(inspectedElement.owners).toMatchInlineSnapshot(` Array [ Object { "displayName": "Child", "hocDisplayNames": null, "id": 3, "key": null, "type": 5, }, Object { "displayName": "App", "hocDisplayNames": null, "id": 2, "key": null, "type": 5, }, ] `); }); </ins> describe('error boundary', () => { it('can toggle error', async () => { class LocalErrorBoundary extends React.Component<any> {

Run the Next app, open up react dev tools and inspect the Box component, rendered by Every time react-devtools-extensions 23.0- Could not find ID for Fiber "App"
Hey, thanks for reporting this issue, and sorry it's blocking your workflow. Edit: The reason for this issue seems to be that there are multiple instances, and the one that we are using to get the fiber's ID when we inspect doesn't have the App fiber (a recursive owner of Box). We'll look into why this is occurring soon!
Fixed via


Question: return {default: result}; } <ins> it('warns when giving a ref (simple)', async () => { // This test lives outside sharedTests because the wrappers don't forward // refs properly, and they end up affecting the current owner which is used // by the warning (making the messages not line up). function App() { return null; } App = React.memo(App); function Outer() { return <App ref={() => {}} />; } ReactNoop.render(<Outer />); expect(ReactNoop.flush).toWarnDev([ 'Warning: Function components cannot be given refs. Attempts to access ' + 'this ref will fail.', ]); }); it('warns when giving a ref (complex)', async () => { // defaultProps means this won't use SimpleMemoComponent (as of this writing) // SimpleMemoComponent is unobservable tho, so we can't check :) function App() { return null; } App.defaultProps = {}; App = React.memo(App); function Outer() { return <App ref={() => {}} />; } ReactNoop.render(<Outer />); expect(ReactNoop.flush).toWarnDev([ 'Warning: Function components cannot be given refs. Attempts to access ' + 'this ref will fail.', ]); }); </ins> // Tests should run against both the lazy and non-lazy versions of `memo`. // To make the tests work for both versions, we wrap the non-lazy version in // a lazy function component.

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


Question: "object-assign": "^4.1.1" }, "peerDependencies": { <del> "react": "^17.0.0" </del> <ins> "react": "^16.8.0 || ^17.0.0" </ins> }, "devDependencies": { "rxjs": "^5.5.6"

React version: . . Note the React peer dependency error. Notably, this currently affects (see ). will refuse to perform this installation entirely. peer-depends on whereas peer-depends on , which is generally considered a breaking change in a minor version. This might have been an oversight in how interacted with (It's considered a breaking change because a like the below should always result in a valid install.) Here are two potential solutions: Cut a release of that peer-depends on , strictly widening the peer dep range from that of 1.4.1. Cut a major release of that peer-depends on , and cut a release of that reverts its peer dependency to .
Happy to take a PR that fixes this by making the range more permissible. I think we need a bump after that to increase the major and simply keep 17-only. If you send a PR like this, please check if any of the other React packages had a similar problem with 17.
If you send a PR like this, please check if any of the other React packages had a similar problem with 17. Sure, I'll send a PR. I noticed a few similar cases in but they all seemed to be for "internal"/"experimental" packages: - - - - - Do you care about fixing any of these since they (AFAIK) don't really have public consumers?
(Retitling per your comment and my reply Sorry about that.)


Question: import FixtureSet from '../../FixtureSet'; import MouseMovement from './mouse-movement'; <ins> import MouseEnter from './mouse-enter'; </ins> const React = window.React;

Do you want to request a feature or report a bug? I want to report a bug. What is the current behavior? Event handlers on elements are fired twice, when hovering from one element onto the next. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: What is the expected behavior? Event handlers should only fire once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.8.4 ReactDOM 16.8.4 Chrome 76.0.3809.132 Firefox 69.0 (64-Bit) Edge 44..267.0
After testing it again and again, I found how to reproduce it: Step 1, render a new component inside a rendered component; Step 2, inside the new component, mouse enter a node from its sibling. Current result: onMouseEnter is called more than once. Demo: We may change the issue title because it's not related with . I've made a test and fixture for this: Hope the information can be helpful. I still have no idea how to fix it. If there's no one working on this, I would like to pick this up. There's a similar issue Do you have any advice?
Go for it,
Let's close this? I see the fix was merged in .


Question:
expect(scryResults.length).toBe(1); });  it('can scryRenderedDOMComponentsWithClass with multiple classes', function() { var Wrapper = React.createClass({ render: function() { return
Hello Jim
; }, }); var renderedComponent = ReactTestUtils.renderIntoDocument(<Wrapper />); var scryResults1 = ReactTestUtils.scryRenderedDOMComponentsWithClass( renderedComponent, 'x y' ); expect(scryResults1.length).toBe(1); var scryResults2 = ReactTestUtils.scryRenderedDOMComponentsWithClass( renderedComponent, 'x z' ); expect(scryResults2.length).toBe(1); var scryResults3 = ReactTestUtils.scryRenderedDOMComponentsWithClass( renderedComponent, ['x', 'y'] ); expect(scryResults3.length).toBe(1); expect(scryResults1[0]).toBe(scryResults2[0]); expect(scryResults1[0]).toBe(scryResults3[0]); var scryResults4 = ReactTestUtils.scryRenderedDOMComponentsWithClass( renderedComponent, ['x', 'a'] ); expect(scryResults4.length).toBe(0); var scryResults5 = ReactTestUtils.scryRenderedDOMComponentsWithClass( renderedComponent, ['x a'] ); expect(scryResults5.length).toBe(0); });  it('traverses children in the correct order', function() { var Wrapper = React.createClass({ render: function() {

The function isn't quite working for me anymore after upgrading from 0.14-rc1 and 0.14. The error stack looks something like this:
Can you post a minimal repro case please?
The minimal repro for me is this: If I use an element -- I get the error reported above. If I use a element -- there is no error. I tried dropping this as a Jest test in the React source code -- but it passed. However, running this exact same test in my local project -- it fails. I've confirmed that all React libs are 0.14. Could there be some kind of build process that's causing the issue? The line that fails is this when is the element.
Sounds like what mentioned here:
Indeed. Looks like this is the same issue. I hope you can push that out fix in 0.14.1 soon as this is a blocking issue for my team for upgrading to 0.14. Thanks for the fast response.
We'll try. In the meantime, you could copy the definition from here since it doesn't rely on any React internals:


Question: // Jest Snapshot v1, https://goo.gl/fbAQLP <ins> exports[`ReactFreshBabelPlugin can handle implicit arrow returns 1`] = ` var _s = $RefreshSig$(), _s2 = $RefreshSig$(), _s3 = $RefreshSig$(), _s4 = $RefreshSig$(), _s5 = $RefreshSig$(), _s6 = $RefreshSig$(); export default _s(() => { _s(); return useContext(X); }, "useContext{}"); export const Foo = () => { _s2(); return useContext(X); }; _s2(Foo, "useContext{}"); _c = Foo; module.exports = _s3(() => { _s3(); return useContext(X); }, "useContext{}"); const Bar = () => { _s4(); return useContext(X); }; _s4(Bar, "useContext{}"); _c2 = Bar; const Baz = _c4 = memo(_c3 = _s5(() => { _s5(); return useContext(X); }, "useContext{}")); const Qux = () => { _s6(); return 0, useContext(X); }; _s6(Qux, "useContext{}"); _c5 = Qux; var _c, _c2, _c3, _c4, _c5; $RefreshReg$(_c, "Foo"); $RefreshReg$(_c2, "Bar"); $RefreshReg$(_c3, "Baz$memo"); $RefreshReg$(_c4, "Baz"); $RefreshReg$(_c5, "Qux"); `; </ins> exports[`ReactFreshBabelPlugin does not consider require-like methods to be HOCs 1`] = ` const A = require('A');

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


Question: - Facebook has dynamic charts that render to `<canvas>` instead of HTML. - Instagram is a "single page" web app built entirely with React and `Backbone.Router`. Designers regularly contribute React code with JSX. <del> - We've built an internal prototype that runs React apps in a web worker. </del> <ins> - We've built internal prototypes that run React apps in a web worker and use React to drive **native iOS views** via an Objective-C bridge. </ins> - You can run React [on the server](http://github.com/petehunt/react-server-rendering) for SEO, performance, code sharing and overall flexibility.

Do you want to request a feature or report a bug? bug What is the current behavior? Selecting of the same value for the twice in a row results in triggering of change event twice for the same value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template: ). Open and click twice on any option. As the result you'll see in console that change event is triggered each time (even if the changed value is equal to the previous one). For comparison you may check the native html implementation: What is the expected behavior? The change event should not trigger again for the same value. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? macOS Sierra 10.12.5, Safari 10.1.1
cc
Thanks for the report It looks like this . We'll look into this and see if we can include a fix in the 15.6 release.
If you extend the given example with 4 radio elements (), fires only once per radio. In other words, the event is not fired if a value for a name changes. Might as well rename to () so it is clear when the callback is fired. But it seems to be a different problem than what is describing. Tested on Google Chrome Version 59.0.3071.86 (Official Build) (64-bit).
Same as mentioned above, uncontrolled radio inputs in my project just stopped working as was expected, they stopped calling the onChange function if a radio button was checked before.
This particular issue was filed before 15.6 release so I don't think what you're describing is related to it. Can you confirm your bug is the same as
yes i think this particular issue is not related indeed. I am almost certain the is the same bug I have the example here: sorry about the confusion
Thanks to and comments in I managed to understand that my reported issue is only affecting uncontrolled radio inputs. Here is a working example of controlled radios working as expected:
While solutions works, I would love to see this fixed in React 15.6 release. Any news on this, it's been a few months. Thanks!

I'm unable to reproduce the issue reported with the latest React 15 release: The issue where it only fires a single change event per input seems to still be a problem, which we will investigate separately. Thanks!


Question: } } <ins> // Determines whether incoming hook is a primitive hook that gets assigned to variables. function isUnnamedBuiltInHook(hook: HooksNode) { return ['Effect', 'ImperativeHandle', 'LayoutEffect', 'DebugValue'].includes( hook.name, ); } </ins> function updateLruCache( locationKeyToHookSourceData: Map<string, HookSourceData>, ): Promise<*> {

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


Question: var event = SyntheticCompositionEvent.getPooled( eventType, topLevelTargetID, <del> nativeEvent </del> <ins> nativeEvent, nativeEventTarget </ins> ); if (fallbackData) {

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


Question: `React` is the entry point to the React framework. If you're using one of the prebuilt packages it's available as a global; if you're using CommonJS modules you can `require()` it. <del> ### DOM </del> <ins> #### React.DOM </ins> `React.DOM` provides all of the standard HTML tags needed to build a React app. You generally don't use it directly; instead, just include it as part of the `/** @jsx React.DOM */` docblock. <del> ### initializeTouchEvents(boolean shouldUseTouch) </del> <ins> #### React.initializeTouchEvents ```javascript initializeTouchEvents(boolean shouldUseTouch) ``` </ins> Configure React's event system to handle touch events on mobile devices. <del> ### function autoBind(function method) </del> <ins> #### React.autoBind ```javascript function autoBind(function method) ``` </ins> Marks the provided function to be automatically bound to each React component instance created. This allows React components to define automatically bound methods and ensure that when called they will always reference their current instance.

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


Question: warnedStyleNames[name] = true; warning( false, <del> 'Unsupported vendor-prefixed style property ' + name + '. Did you mean ' + name.charAt(0).toUpperCase() + name.slice(1) + '?' </del> <ins> 'Unsupported vendor-prefixed style property %s. Did you mean %s?', name, name.charAt(0).toUpperCase() + name.slice(1) </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> ReactDOM.render( <input type="checkbox" onChange={onChange} checked={true} data-unrelated={true} />, container, ); expect(nodeValueSetter).toHaveBeenCalledTimes(0); expect(() => { ReactDOM.render( <input type="checkbox" onChange={onChange} />, container, ); }).toErrorDev( 'A component is changing a controlled input to be uncontrolled. This is likely caused by ' + 'the value changing from a defined to undefined, which should not happen. Decide between ' + 'using a controlled or uncontrolled input element for the lifetime of the component.', ); // This leaves the current checked value in place, just like text inputs. </del> <ins> ReactDOM.render(<audio muted={true} data-unrelated="yes" />, container); </ins> expect(nodeValueSetter).toHaveBeenCalledTimes(0); <del> expect(() => { ReactDOM.render( <input type="checkbox" onChange={onChange} checked={false} />, container, ); }).toErrorDev( ' A component is changing an uncontrolled input to be controlled. This is likely caused by ' + 'the value changing from undefined to a defined value, which should not happen. Decide between ' + 'using a controlled or uncontrolled input element for the lifetime of the component.', ); </del> <ins> ReactDOM.render(<audio muted={false} data-unrelated="ok" />, container); </ins> expect(nodeValueSetter).toHaveBeenCalledTimes(1); <del> ReactDOM.render( <input type="checkbox" onChange={onChange} checked={true} />, container, ); expect(nodeValueSetter).toHaveBeenCalledTimes(2); </del> }); it('should ignore attribute list for elements with the "is" attribute', () => {

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 18.3.0-canary-- radio buttons that toggle in selecting each radio button, is no longer called <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: The following CodeSandbox demonstrates the issue with the current react canary version. The issue is not present when react & react-dom versions are changed to stable 18.2.0 <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --'s prop is not called on subsequent clicks of the input 's prop should be called on subsequent clicks of the input
As far as I an tell this also repros without toggling : So it's just about changing the controlled delayed.
The problem was introduced with . The previous version works.
It looks like it was this change that introduced this bug:
what are ways to fix this issue?
FYI, I find something by investigating, as below: : isn't called because here is falsy in that process. PS: In our case, should be equal to . Diving into the inner functions as the followings. : : : We can find the key is that the tracked value should be different from the value get from () in our case. We can believe the tracked value was not updated after the delayed state change, which cause the issue.

Analysis by reproduction steps (Please visit , which can print the tracked values): : One: checked ( is ), and the tracked value is Two: unchecked, and the tracked value is 'Two', and wait for delayed : is called One: unchecked, and the tracked value is Two: checked, and the tracked value is 'One', and wait for the delayed : is called One: checked, and the tracked value is Two: unchecked, and the tracked value is 'Two', won't call again PS: The tracked value can be updated at the end of the event handler (by ), so Step 2 will result in the correct tracked values. So, I think one solution is to update the tracked value (at the end of the commit mutation phase) when the checked prop changes. I'd like to submit a PR to fix it. Any corrections or suggestions will be appreciated, (for I'm not sure if I miss anything important).
I tried another way to understand what caused the bug. I just checked the between a working commit () and non-working commit () and figured out that the bug happens after removing in function of . just restoring or just adding the bug disappear. Maybe the problem is explained in this is not updated and will result null/undefined and the radio is no more controlled? You can check this . I've also made a change to to start devtools server with a simple radio example. To run the server: run in the root directory and in directory. from to the root directory run from folder execute (better to open another shell for this command) go to


Question: ), }; <del> const builtModulesDir = resolve( __dirname, '..', '..', 'build', 'oss-experimental', ); </del> module.exports = { mode: __DEV__ ? 'development' : 'production', devtool: __DEV__ ? 'eval-cheap-source-map' : 'source-map',

in a project that has and node error: Published package contains the following code: No absolute paths in bundle. successful evaluation.
Edit: Looks like was what broke this. My bad.
Fix has been published as 4.22.1. Sorry again.


Question: <ins> --- title: "React v0.14" author: spicyj --- We’re happy to announce the release of React 0.14 today! This release has a few major changes, primarily designed to simplify the code you write every day and to better support environments like React Native. If you tried the release candidate, thank you – your support is invaluable and we've fixed a few bugs that you reported. As with all of our releases, we consider this version to be stable enough to use in production and recommend that you upgrade in order to take advantage of our latest improvements. ## Upgrade Guide Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain. If your code is free of warnings when running under React 0.13, upgrading should be easy. We have two new small breaking changes that didn't give a warning in 0.13 (see below). Every new change in 0.14, including the major changes below, is introduced with a runtime warning and will work as before until 0.15, so you don't have to worry about your app breaking with this upgrade. See the changelog below for more details. ## Installation We recommend using React from `npm` and using a tool like browserify or webpack to build your code into a single bundle. To install the two packages: * `npm install --save react react-dom` Remember that by default, React runs extra checks and provides helpful warnings in development mode. When deploying your app, set the `NODE_ENV` environment variable to `production` to use the production build of React which does not include the development warnings and runs significantly faster. If you can’t use `npm` yet, we provide pre-built browser builds for your convenience, which are also available in the `react` package on bower. * **React** Dev build with warnings: <https://fb.me/react-0.14.0.js> Minified build for production: <https://fb.me/react-0.14.0.min.js> * **React with Add-Ons** Dev build with warnings: <https://fb.me/react-with-addons-0.14.0.js> Minified build for production: <https://fb.me/react-with-addons-0.14.0.min.js> * **React DOM** (include React in the page before React DOM) Dev build with warnings: <https://fb.me/react-dom-0.14.0.js> Minified build for production: <https://fb.me/react-dom-0.14.0.min.js> ## Changelog ### Major changes - #### Two Packages: React and React DOM As we look at packages like [react-native](https://github.com/facebook/react-native), [react-art](https://github.com/reactjs/react-art), [react-canvas](https://github.com/Flipboard/react-canvas), and [react-three](https://github.com/Izzimach/react-three), it has become clear that the beauty and essence of React has nothing to do with browsers or the DOM. To make this more clear and to make it easier to build more environments that React can render to, we’re splitting the main `react` package into two: `react` and `react-dom`. **This paves the way to writing components that can be shared between the web version of React and React Native.** We don’t expect all the code in an app to be shared, but we want to be able to share the components that do behave the same across platforms. The `react` package contains `React.createElement`, `.createClass`, `.Component`, `.PropTypes`, `.Children`, and the other helpers related to elements and component classes. We think of these as the [_isomorphic_](http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/) or [_universal_](https://medium.com/@mjackson/universal-javascript-4761051b7ae9) helpers that you need to build components. The `react-dom` package has `ReactDOM.render`, `.unmountComponentAtNode`, and `.findDOMNode`. In `react-dom/server` we have server-side rendering support with `ReactDOMServer.renderToString` and `.renderToStaticMarkup`. ```js var React = require('react'); var ReactDOM = require('react-dom'); var MyComponent = React.createClass({ render: function() { return <div>Hello World</div>; } }); ReactDOM.render(<MyComponent />, node); ``` The old names will continue to work with a warning until 0.15 is released, and we’ve published the [automated codemod script](https://github.com/facebook/react/blob/master/packages/react-codemod/README.md) we used at Facebook to help you with this transition. The add-ons have moved to separate packages as well: - `react-addons-clone-with-props` - `react-addons-create-fragment` - `react-addons-css-transition-group` - `react-addons-linked-state-mixin` - `react-addons-perf` - `react-addons-pure-render-mixin` - `react-addons-shallow-compare` - `react-addons-test-utils` - `react-addons-transition-group` - `react-addons-update` - `ReactDOM.unstable_batchedUpdates` in `react-dom`. For now, please use matching versions of `react` and `react-dom` (and the add-ons, if you use them) in your apps to avoid versioning problems. - #### DOM node refs The other big change we’re making in this release is exposing refs to DOM components as the DOM node itself. That means: we looked at what you can do with a `ref` to a React DOM component and realized that the only useful thing you can do with it is call `this.refs.giraffe.getDOMNode()` to get the underlying DOM node. Starting with this release, `this.refs.giraffe` _is_ the actual DOM node. **Note that refs to custom (user-defined) components work exactly as before; only the built-in DOM components are affected by this change.** ```js var Zoo = React.createClass({ render: function() { return <div>Giraffe name: <input ref="giraffe" /></div>; }, showName: function() { // Previously: var input = this.refs.giraffe.getDOMNode(); var input = this.refs.giraffe; alert(input.value); } }); ``` This change also applies to the return result of `ReactDOM.render` when passing a DOM node as the top component. As with refs, this change does not affect custom components. With this change, we’re deprecating `.getDOMNode()` and replacing it with `ReactDOM.findDOMNode` (see below). If your components are currently using `.getDOMNode()`, they will continue to work with a warning until 0.15. - #### Stateless functional components In idiomatic React code, most of the components you write will be stateless, simply composing other components. We’re introducing a new, simpler syntax for these components where you can take `props` as an argument and return the element you want to render: ```js // A functional component using an ES2015 (ES6) arrow function: var Aquarium = (props) => { var fish = getFish(props.species); return <Tank>{fish}</Tank>; }; // Or with destructuring and an implicit return, simply: var Aquarium = ({species}) => ( <Tank> {getFish(species)} </Tank> ); // Then use: <Aquarium species="rainbowfish" /> ``` These components behave just like a React class with only a `render` method defined. Since no component instance is created for a functional component, any `ref` added to one will evaluate to `null`. Functional components do not have lifecycle methods, but you can set `.propTypes` and `.defaultProps` as properties on the function. This pattern is designed to encourage the creation of these simple components that should comprise large portions of your apps. In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. - #### Deprecation of react-tools The `react-tools` package and `JSXTransformer.js` browser file [have been deprecated](/react/blog/2015/06/12/deprecating-jstransform-and-react-tools.html). You can continue using version `0.13.3` of both, but we no longer support them and recommend migrating to [Babel](http://babeljs.io/), which has built-in support for React and JSX. - #### Compiler optimizations React now supports two compiler optimizations that can be enabled in Babel 5.8.23 and newer. Both of these transforms **should be enabled only in production** (e.g., just before minifying your code) because although they improve runtime performance, they make warning messages more cryptic and skip important checks that happen in development mode, including propTypes. **Inlining React elements:** The `optimisation.react.inlineElements` transform converts JSX elements to object literals like `{type: 'div', props: ...}` instead of calls to `React.createElement`. **Constant hoisting for React elements:** The `optimisation.react.constantElements` transform hoists element creation to the top level for subtrees that are fully static, which reduces calls to `React.createElement` and the resulting allocations. More importantly, it tells React that the subtree hasn’t changed so React can completely skip it when reconciling. ### Breaking changes In almost all cases, we change our APIs gradually and warn for at least one release to give you time to clean up your code. These two breaking changes did not have a warning in 0.13 but should be easy to find and clean up: - `React.initializeTouchEvents` is no longer necessary and has been removed completely. Touch events now work automatically. - Add-Ons: Due to the DOM node refs change mentioned above, `TestUtils.findAllInRenderedTree` and related helpers are no longer able to take a DOM component, only a custom component. These three breaking changes had a warning in 0.13, so you shouldn’t have to do anything if your code is already free of warnings: - The `props` object is now frozen, so mutating props after creating a component element is no longer supported. In most cases, [`React.cloneElement`](/react/docs/top-level-api.html#react.cloneelement) should be used instead. This change makes your components easier to reason about and enables the compiler optimizations mentioned above. - Plain objects are no longer supported as React children; arrays should be used instead. You can use the [`createFragment`](/react/docs/create-fragment.html) helper to migrate, which now returns an array. - Add-Ons: `classSet` has been removed. Use [classnames](https://github.com/JedWatson/classnames) instead. ### New deprecations, introduced with a warning Each of these changes will continue to work as before with a new warning until the release of 0.15 so you can upgrade your code gradually. - Due to the DOM node refs change mentioned above, `this.getDOMNode()` is now deprecated and `ReactDOM.findDOMNode(this)` can be used instead. Note that in most cases, calling `findDOMNode` is now unnecessary – see the example above in the “DOM node refs” section. With each returned DOM node, we've added a `getDOMNode` method for backwards compatibility that will work with a warning until 0.15. If you have a large codebase, you can use our [automated codemod script](https://github.com/facebook/react/blob/master/packages/react-codemod/README.md) to change your code automatically. - `setProps` and `replaceProps` are now deprecated. Instead, call ReactDOM.render again at the top level with the new props. - ES6 component classes must now extend `React.Component` in order to enable stateless function components. The [ES3 module pattern](/react/blog/2015/01/27/react-v0.13.0-beta-1.html#other-languages) will continue to work. - Reusing and mutating a `style` object between renders has been deprecated. This mirrors our change to freeze the `props` object. - Add-Ons: `cloneWithProps` is now deprecated. Use [`React.cloneElement`](/react/docs/top-level-api.html#react.cloneelement) instead (unlike `cloneWithProps`, `cloneElement` does not merge `className` or `style` automatically; you can merge them manually if needed). - Add-Ons: To improve reliability, `CSSTransitionGroup` will no longer listen to transition events. Instead, you should specify transition durations manually using props such as `transitionEnterTimeout={500}`. ### Notable enhancements - Added `React.Children.toArray` which takes a nested children object and returns a flat array with keys assigned to each child. This helper makes it easier to manipulate collections of children in your `render` methods, especially if you want to reorder or slice `this.props.children` before passing it down. In addition, `React.Children.map` now returns plain arrays too. - React uses `console.error` instead of `console.warn` for warnings so that browsers show a full stack trace in the console. (Our warnings appear when you use patterns that will break in future releases and for code that is likely to behave unexpectedly, so we do consider our warnings to be “must-fix” errors.) - Previously, including untrusted objects as React children [could result in an XSS security vulnerability](http://danlec.com/blog/xss-via-a-spoofed-react-element). This problem should be avoided by properly validating input at the application layer and by never passing untrusted objects around your application code. As an additional layer of protection, [React now tags elements](https://github.com/facebook/react/pull/4832) with a specific [ES2015 (ES6) `Symbol`] (http://www.2ality.com/2014/12/es6-symbols.html) in browsers that support it, in order to ensure that React never considers untrusted JSON to be a valid element. If this extra security protection is important to you, you should add a `Symbol` polyfill for older browsers, such as the one included by [Babel’s polyfill](http://babeljs.io/docs/usage/polyfill/). - When possible, React DOM now generates XHTML-compatible markup. - React DOM now supports these standard HTML attributes: `capture`, `challenge`, `inputMode`, `is`, `keyParams`, `keyType`, `minLength`, `summary`, `wrap`. It also now supports these non-standard attributes: `autoSave`, `results`, `security`. - React DOM now supports these SVG attributes, which render into namespaced attributes: `xlinkActuate`, `xlinkArcrole`, `xlinkHref`, `xlinkRole`, `xlinkShow`, `xlinkTitle`, `xlinkType`, `xmlBase`, `xmlLang`, `xmlSpace`. - The `image` SVG tag is now supported by React DOM. - In React DOM, arbitrary attributes are supported on custom elements (those with a hyphen in the tag name or an `is="..."` attribute). - React DOM now supports these media events on `audio` and `video` tags: `onAbort`, `onCanPlay`, `onCanPlayThrough`, `onDurationChange`, `onEmptied`, `onEncrypted`, `onEnded`, `onError`, `onLoadedData`, `onLoadedMetadata`, `onLoadStart`, `onPause`, `onPlay`, `onPlaying`, `onProgress`, `onRateChange`, `onSeeked`, `onSeeking`, `onStalled`, `onSuspend`, `onTimeUpdate`, `onVolumeChange`, `onWaiting`. - Many small performance improvements have been made. - Many warnings show more context than before. - Add-Ons: A [`shallowCompare`](https://github.com/facebook/react/pull/3355) add-on has been added as a migration path for `PureRenderMixin` in ES6 classes. - Add-Ons: `CSSTransitionGroup` can now use [custom class names](https://github.com/facebook/react/blob/48942b85/docs/docs/10.1-animation.md#custom-classes) instead of appending `-enter-active` or similar to the transition name. ### New helpful warnings - React DOM now warns you when nesting HTML elements invalidly, which helps you avoid surprising errors during updates. - Passing `document.body` directly as the container to `ReactDOM.render` now gives a warning as doing so can cause problems with browser extensions that modify the DOM. - Using multiple instances of React together is not supported, so we now warn when we detect this case to help you avoid running into the resulting problems. ### Notable bug fixes - Click events are handled by React DOM more reliably in mobile browsers, particularly in Mobile Safari. - SVG elements are created with the correct namespace in more cases. - React DOM now renders `<option>` elements with multiple text children properly and renders `<select>` elements on the server with the correct option selected. - When two separate copies of React add nodes to the same document (including when a browser extension uses React), React DOM tries harder not to throw exceptions during event handling. - Using non-lowercase HTML tag names in React DOM (e.g., `React.createElement('DIV')`) no longer causes problems, though we continue to recommend lowercase for consistency with the JSX tag name convention (lowercase names refer to built-in components, capitalized names refer to custom components). - React DOM understands that these CSS properties are unitless and does not append “px” to their values: `animationIterationCount`, `boxOrdinalGroup`, `flexOrder`, `tabSize`, `stopOpacity`. - Add-Ons: When using the test utils, `Simulate.mouseEnter` and `Simulate.mouseLeave` now work. - Add-Ons: ReactTransitionGroup now correctly handles multiple nodes being removed simultaneously. </ins>

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: var mocks = require('mocks'); <ins> var ExecutionEnvironment; </ins> var React; <ins> var ReactMarkupChecksum; </ins> var ReactMount; <ins> var ReactReconcileTransaction; </ins> var ReactTestUtils; var ReactServerRendering; <del> var ReactMarkupChecksum; var ExecutionEnvironment; </del> var ID_ATTRIBUTE_NAME;

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:
--- layout: default  sectionid: blog  ---

{{ page.title }}

{{ page.date | date_to_string }}

 {{ content }}
 {% include nav_blog.html %}
 {% include blog_post.html %}

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


Question: assertInputTrackingIsCurrent(container); }); <ins> it('should control radio buttons if the tree updates during render (case 2; #26876)', () => { let thunk = null; function App() { const [disabled, setDisabled] = React.useState(false); const [value, setValue] = React.useState('one'); function handleChange(e) { setDisabled(true); // Pretend this is in a setTimeout or something thunk = () => { setDisabled(false); setValue(e.target.value); }; } return ( <> <input type="radio" name="fruit" value="one" checked={value === 'one'} onChange={handleChange} disabled={disabled} /> <input type="radio" name="fruit" value="two" checked={value === 'two'} onChange={handleChange} disabled={disabled} /> </> ); } ReactDOM.render(<App />, container); const [one, two] = container.querySelectorAll('input'); expect(one.checked).toBe(true); expect(two.checked).toBe(false); expect(isCheckedDirty(one)).toBe(true); expect(isCheckedDirty(two)).toBe(true); assertInputTrackingIsCurrent(container); // Click two setUntrackedChecked.call(two, true); dispatchEventOnNode(two, 'click'); expect(one.checked).toBe(true); expect(two.checked).toBe(false); expect(isCheckedDirty(one)).toBe(true); expect(isCheckedDirty(two)).toBe(true); assertInputTrackingIsCurrent(container); // After a delay... ReactDOM.unstable_batchedUpdates(thunk); expect(one.checked).toBe(false); expect(two.checked).toBe(true); expect(isCheckedDirty(one)).toBe(true); expect(isCheckedDirty(two)).toBe(true); assertInputTrackingIsCurrent(container); // Click back to one setUntrackedChecked.call(one, true); dispatchEventOnNode(one, 'click'); expect(one.checked).toBe(false); expect(two.checked).toBe(true); expect(isCheckedDirty(one)).toBe(true); expect(isCheckedDirty(two)).toBe(true); assertInputTrackingIsCurrent(container); // After a delay... ReactDOM.unstable_batchedUpdates(thunk); expect(one.checked).toBe(true); expect(two.checked).toBe(false); expect(isCheckedDirty(one)).toBe(true); expect(isCheckedDirty(two)).toBe(true); assertInputTrackingIsCurrent(container); }); </ins> it('should warn with value and no onChange handler and readOnly specified', () => { ReactDOM.render( <input type="text" value="zoink" readOnly={true} />,

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 18.3.0-canary-- radio buttons that toggle in selecting each radio button, is no longer called <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: The following CodeSandbox demonstrates the issue with the current react canary version. The issue is not present when react & react-dom versions are changed to stable 18.2.0 <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --'s prop is not called on subsequent clicks of the input 's prop should be called on subsequent clicks of the input
As far as I an tell this also repros without toggling : So it's just about changing the controlled delayed.
The problem was introduced with . The previous version works.
It looks like it was this change that introduced this bug:
what are ways to fix this issue?
FYI, I find something by investigating, as below: : isn't called because here is falsy in that process. PS: In our case, should be equal to . Diving into the inner functions as the followings. : : : We can find the key is that the tracked value should be different from the value get from () in our case. We can believe the tracked value was not updated after the delayed state change, which cause the issue.

Analysis by reproduction steps (Please visit , which can print the tracked values): : One: checked ( is ), and the tracked value is Two: unchecked, and the tracked value is 'Two', and wait for delayed : is called One: unchecked, and the tracked value is Two: checked, and the tracked value is 'One', and wait for the delayed : is called One: checked, and the tracked value is Two: unchecked, and the tracked value is 'Two', won't call again PS: The tracked value can be updated at the end of the event handler (by ), so Step 2 will result in the correct tracked values. So, I think one solution is to update the tracked value (at the end of the commit mutation phase) when the checked prop changes. I'd like to submit a PR to fix it. Any corrections or suggestions will be appreciated, (for I'm not sure if I miss anything important).
I tried another way to understand what caused the bug. I just checked the between a working commit () and non-working commit () and figured out that the bug happens after removing in function of . just restoring or just adding the bug disappear. Maybe the problem is explained in this is not updated and will result null/undefined and the radio is no more controlled? You can check this . I've also made a change to to start devtools server with a simple radio example. To run the server: run in the root directory and in directory. from to the root directory run from folder execute (better to open another shell for this command) go to


Question: return inst.state; } <ins> if (replace && queue.length === 1) { return queue[0]; } </ins> var nextState = assign({}, replace ? queue[0] : inst.state); for (var i = replace ? 1 : 0; i < queue.length; i++) { var partial = queue[i];

I'm still learning React, so it's possible I'm misunderstanding something. I'm trying to use React with , and hit a stumbling block, by upgrading to React 0.13. There is on the repository, that explains how to use immutable as a react state, and it provides the following example (I transpiled it to ES3): This works great in 0.12, but in 0.13, you will receive the following error when clicking on the div: Putting a breakpoint on the error, and inspecting with a debugger reveals that all the methods on have disappeared. Is this the expected behavior in 0.13?
should be a plain object, you're not allowed to put classes in there.
So the wiki page I linked to is incorrect? It would make working with (and probably other immutable implementions) a pita, since you would have to pack/unpack the object every time you store/retrieve it.
Seems so... cc
I encountered the same thing in 0.12, storing an immutable-js object on the state directly clobbers it,but simply putting it under an attribute works fine. E.g. .
I am experiencing this after upgrading to 0.13 as well. It didn't seem to be a problem in react 0.12. It seems to almost make sense that state could be an immutable object since equality comparison is cheap. I could nest my state object under state ( yuck) but it seems like it would create a lot of boilerplate code that I didn't need in 0.12
I think you can +1 in
Yeah this bit me bad... I used an as all my state and not a plain object, which worked absolutely great in 0.12 and broke in 0.13. This forces me to add a bunch of useless vanilla objects with a single child prop to hold my immutable map.
Since I was working with a simple map structure, toObject saved me... e.g. Not sure how well this work with more complex object structures however.
Has there been any movement on this? My project has been on hold since I don't know if I should: a.) stay on React 0.12 where I could use Immutable maps for state. b.) Move all my immutable maps to child of a single-item map. or c.)

leave things as they are and this will be supported in the future.
AFAIK this is not going to change. Personally I still don't understand why people want to put third-party objects as state, I don't see what benefit there is. What's wrong with just using ?
For me there were two main advantages. ) My stores already deal in immutable hashes, With react 0.12 I didn't have to bother converting them ) Deep comparison for updates is simple with immutable objects. With react 0.12 when you setState with an immutable object, if any of it's contents had changed, it would re-render. If it was the same, it would not. Comparing immutable objects is cheap. Deep comparing hashes is not. There is more upfront cost with the immutable objects, but they are way easier to reason about wether or not they have changed. If there is definitely no plan to support this then I suppose the best plan of action is to to_js everything and manually deep compare?
There is movement on which would get rid of replaceState and add better immutable-js support (and perhaps other libraries) in the core. However, it was not our intention to break the old behavior of replaceState in 0.13 so this seems like a bug to me. Do we maybe want to patch release this if there is an easy fix?
1) I can't speak for this, but using a store's data for the singular state object seems rather limiting, you're now unable to include any other stores or introduce any other locally relevant state for the component right? 2) Is straight-forward with objects as well, immutability is not a concept that is unique to immutable-js. Depending on the underlying behaviors you can use just or a simple reusable shallow equality test with plain objects too. But does actually intend to allow replacing the "state object" vs just simply understanding how to iterate over generic maps/sets?
) Yes, I do have some components that use data from multiple stores, and those end up as different elements under a hash. When I have a component that only uses the data from one store, it is sort of silly to have it nested as a single element in a hash. ) "you can use just === or a simple reusable shallow equality test with plain objects too" is my point exactly, usually my objects are just one level deep and this is fine.

I sometimes they are not though and with Immutable-js objects I can use === with deeply nested objects. If I use immutable-js for everything, I don't have to worry about it.
not sure that it will be the cleanest thing. This is a result of your changes . Right now we just have a but we don't know what each thing in the queue is (did it come from a or ). We could wrap each item in the queue so we know what it came from, so instead of we have . That would allow us to stack and calls (which I don't think we actually handle correctly now). But the simplest case where you're only using , we can probably just change this line:
We could take something in 0.13.4 (not 0.13.3, shipping that today). But it needs to bake first. Both changes I mentioned would change behavior so there's some risk. The first is more complete, the latter trades 1 bug for a slightly less bad bug (setState(), replaceState() in the same update queue will result in the object passed to setState being used as the replacement since we only have a single pendingReplace flag)
Actually, this came from . There is a simple fix: Because the queue is emptied for every replaceState, since nothing earlier in the queue could've affected the result:
Ah, truth. is fixing and it's small and let's just take it in 0.13.3 so we don't have to do another patch release so soon after.
So, the issue was fixed in , but what about components using ? I'm seeing this when I use
setState merges. Using a non-plain object with it isn't supported. You can put whatever object you want on an inner state key (, , etc.).


Question: break; } case 'SELECT_NEXT_ELEMENT_WITH_ERROR_OR_WARNING_IN_TREE': { <del> if (store.errorCount === 0 && store.warningCount === 0) { </del> <ins> const elementIndicesWithErrorsOrWarnings = store.getElementsWithErrorsAndWarnings(); if (elementIndicesWithErrorsOrWarnings.length === 0) { </ins> return state; } <del> const elementIndicesWithErrorsOrWarnings = store.getElementsWithErrorsAndWarnings(); </del> let flatIndex = -1; if (selectedElementIndex !== null) { // Resume from the current position in the list.

Unfortunately I don't know how to reproduce this bug. It was just logged to Sentry. It seems like there's a logic bug here though: If is null or is empty, then would be 0 still– and this statement would result in an undefined entry: Only once react-devtools-inline 24.4 Error: can't access property "id", n is undefined No response No response
Not sure if will fix your issue. Let me know if you can get a repro!


Question: var bankForRegistrationName = listenerBank[registrationName]; // TODO: This should never be null -- when is it? if (bankForRegistrationName) { <del> delete bankForRegistrationName[inst._rootNodeID]; </del> <ins> var key = getDictionaryKey(inst); delete bankForRegistrationName[key]; </ins> } },

In my javascript frameworks benchmark I ran into a performance regression for react. To reproduce open and open the console. Repeat three times the following: Click "Create 10,000" then click "Clear" You'll get a result like that: runLots took 1905. clear took 1997. runLots took 1813. clear took 4208.895 runLots took 1806. clear took 401. Now repeat the same for and you'll get something like that: unLots took 2938. clear took 399. runLots took 2726.365 clear took 383. runLots took 2872.625 clear took 381. (Measurement on Chrome 51 on MacOS 10.11.5 on a MBP 15) Notice that clear is a lot slower for the first two runs for React v 15, but the third clear run performs about the same for both react versions. The source code can be found in the of my benchmark.
In general we don’t advise you to render 10K items. Use something like instead. However, this indeed seems like a perf regression. <sIt appears that we’re spending a little time in per each item, and it adds up with 10K items.</s(Scratch that, doesn’t appear to be the cause.)
This is a very simple scenario: we are unmounting 10,000 components. The bottleneck is somewhere in reconciliation. React 0.14 is reconciling fast right away: <img width="762" alt="screen shot 2016-07-08 at 22 06 01" src=""React 15 is reconciling slow at first (notice how long is compared to applying DOM updates): <img width="1097" alt="screen shot 2016-07-08 at 22 03 56" src=""But it warms up exactly after two mount-unmount cycles (notice how its size is less relative to DOM updates): <img width="928" alt="screen shot 2016-07-08 at 22 04 07" src=""
It looks like there is some sort of V8 optimization that doesn’t kick in until you unmount a lot of components.

I was able to drastically reduce time (from 2 seconds to 300 milliseconds) on React 15 by replacing statements with assignment in these two places:   This is probably not a real solution (I think just leaving them as means memory keeps growing, even if just for property keys). Still, I wonder why 0.14.x is not similarly penalized.
Replacing objects with ES6 Maps gives similar performance improvements there.
This was fixed in . Thank you very much for caring and providing specific instructions.
As a quick experiment, I ran the benchmarks under Firefox: both versions ran in the same speed as the 15.2 in Chrome (I mean: slow). I surely hope the fix would fix it in Firefox too !
Maybe putting these fields on the internal instances instead of global maps will help it in Firefox. Would you like to investigate why it's slow?
I gave it a look, and Firefox slowness is due to DOM being slow. I don’t think we can fix it.
I'd really appreciate a Firefox bug report with testcase here!
I filed with the information of this bug. I don't have the time to do a reduced testcase now though.
FWIW, removeChild is slow in Gecko because of layout. No idea whether setting display: none before removal or some such might speed up the process. It might help if done on the element on which removeChild is being called.
Thank you for filing!


Question: var event = SyntheticEvent.getPooled( eventTypes.change, activeElementID, <del> nativeEvent </del> <ins> nativeEvent, nativeEvent.target </ins> ); EventPropagators.accumulateTwoPhaseDispatches(event);

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


Question: import type {SuspenseConfig} from './ReactFiberSuspenseConfig'; import type {ReactPriorityLevel} from './SchedulerWithReactIntegration'; <del> import * as Scheduler from 'scheduler'; </del> import ReactSharedInternals from 'shared/ReactSharedInternals'; import {NoWork} from './ReactFiberExpirationTime';

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: jest.runOnlyPendingTimers(); let data = [ <del> await getErrorsAndWarningsForElement(1), await getErrorsAndWarningsForElement(2), </del> <ins> await getErrorsAndWarningsForElementAtIndex(0), await getErrorsAndWarningsForElementAtIndex(1), </ins> ]; expect(data).toMatchInlineSnapshot(` Array [

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


Question: "README.md", "addons.js", "react.js", <ins> "dist/", </ins> "lib/" ], "main": "react.js",

It's nice to have prebuilt binaries available through the current package managers. Right now there's a prebuilt package for , but it'd be nice to also have them on npm / component / What do you think is the best way to create and maintain these packages? cc/
See also .
cc -- Not a blocker for 0.11, but it would be nice if could be merged.
By "binaries" do you actually mean prebuilt versions of React that you can just include on a web page? React doesn't really have binary components.
Yep, that's what I mean.
I'm using in a project and I would love to be able to include react that way. The last conversation about this ended in
We don't have plans to do this right now.


Question: ReactDebugTool.endProfiling(); } <ins> function isRunning() { return ReactDebugTool.isProfiling(); } </ins> var ReactPerfAnalysis = { getLastMeasurements: getFlushHistory, getExclusive,

I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR


Question: ); } <ins> bundles = bundles.filter(([bundle, bundleType]) => { return !shouldSkipBundle(bundle, bundleType); }); </ins> if (process.env.CIRCLE_NODE_TOTAL) { // In CI, parallelize bundles across multiple tasks. const nodeTotal = parseInt(process.env.CIRCLE_NODE_TOTAL, 10);

Please make "requireable" npm release, already fixed and only new version on npm is needed. I've developed a source transform for JSX for browserify — which doesn't work properly because of
1 pushed to npm:


Question: (typeof instance.UNSAFE_componentWillReceiveProps === 'function' || typeof instance.componentWillReceiveProps === 'function') ) { <del> if (oldProps !== newProps || oldContext !== nextContext) { </del> <ins> if ( unresolvedOldProps !== unresolvedNewProps || oldContext !== nextContext ) { </ins> callComponentWillReceiveProps( workInProgress, instance,

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


Question: { "name": "react-devtools-core", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "description": "Use react-devtools outside of the browser", "license": "MIT", "main": "./dist/backend.js",

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


Question: <!DOCTYPE html> <ins> <!--[if IE]><![endif]--> </ins> <html> <head> <meta charset="utf-8">

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


Question: maybeMessage: any, ...inputArgs: $ReadOnlyArray<any> ): string { <del> if (typeof maybeMessage !== 'string') { return [maybeMessage, ...inputArgs].join(' '); } const re = /(%?)(%([jds]))/g; </del> const args = inputArgs.slice(); <del> let formatted: string = maybeMessage; if (args.length) { formatted = formatted.replace(re, (match, escaped, ptn, flag) => { let arg = args.shift(); switch (flag) { case 's': arg += ''; break; case 'd': case 'i': arg = parseInt(arg, 10).toString(); break; case 'f': arg = parseFloat(arg).toString(); break; } if (!escaped) { return arg; } args.unshift(arg); return match; }); </del> <ins> // Symbols cannot be concatenated with Strings. let formatted: string = typeof maybeMessage === 'symbol' ? maybeMessage.toString() : '' + maybeMessage; // If the first argument is a string, check for substitutions. if (typeof maybeMessage === 'string') { if (args.length) { const REGEXP = /(%?)(%([jds]))/g; formatted = formatted.replace(REGEXP, (match, escaped, ptn, flag) => { let arg = args.shift(); switch (flag) { case 's': arg += ''; break; case 'd': case 'i': arg = parseInt(arg, 10).toString(); break; case 'f': arg = parseFloat(arg).toString(); break; } if (!escaped) { return arg; } args.unshift(arg); return match; }); } </ins> } <del> // arguments remain after formatting </del> <ins> // Arguments that remain after formatting. </ins> if (args.length) { <del> formatted += ' ' + args.join(' '); </del> <ins> for (let i = 0; i < args.length; i++) { const arg = args[i]; // Symbols cannot be concatenated with Strings. formatted += ' ' + (typeof arg === 'symbol' ? arg.toString() : arg); } </ins> } <del> // update escaped %% values </del> <ins> // Update escaped %% values. </ins> formatted = formatted.replace(/%{2,2}/g, '%'); return '' + formatted;

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


Question: ## Transferring with `...` in JSX <ins> > NOTE: > > In the example below, the `--harmony ` flag is required as this syntax is an experimental ES7 syntax. If using the in-browser JSX transformer, simply open your script with `<script type="text/jsx;harmony=true">`. See the [Rest and Spread Properties ...](http://facebook.github.io/react/docs/transferring-props.html#rest-and-spread-properties-...) section below for more details. </ins> Sometimes it's fragile and tedious to pass every property along. In that case you can use [destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) with rest properties to extract a set of unknown properties. List out all the properties that you would like to consume, followed by `...other`.

New to React. I was following the tutorial and ran into a snag. Copy pasting the example example lead to on line 2 on Chrome. I was using the in-browser JSX transformer. It took me awhile to figure out this is a proposed JavaScript thing and not a built-in React thing. needed to be . This is super unclear from the documentation/tutorial. To me, it reads as if somehow React is taking care of this or it's a React specific syntax; not ES6. The docs link out to the Destructuring assignment, but I think the docs should clearly state "Your browser / environment must support ES6 harmony for this to work."
Well, the docs do say this... Perhaps move this up further as people (like me) following along the tutorial may not bother to keep reading.
Want to send a PR to improve upon the tutorial?
Sure. I'll mess with it tonight.


Question: restorePendingUpdaters, addTransitionStartCallbackToPendingTransition, addTransitionCompleteCallbackToPendingTransition, <ins> setIsRunningInsertionEffect, </ins> } from './ReactFiberWorkLoop.new'; import { NoFlags as NoHookEffect,

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


Question: } }; <ins> var MixinBWithReverseSpec = { componentDidMount: function() { this.props.listener('MixinBWithReverseSpec didMount'); }, mixins: [MixinA] }; </ins> var MixinC = { statics: { staticC: function() {}

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: expect(instance.props.fruit).toBe('persimmon'); }); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> it('should normalize props with default values', function() { var Component = React.createClass({ getDefaultProps: function() {

The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.


Question: var invariant = require('fbjs/lib/invariant'); var ExecutionEnvironment = require('fbjs/lib/ExecutionEnvironment'); <del> // TODO: There's no way to cancel these, because Fiber doesn't atm. let rAF: (callback: (time: number) => void) => number; </del> <ins> // TODO: There's no way to cancel, because Fiber doesn't atm. </ins> let rIC: (callback: (deadline: Deadline) => void) => number; if (!ExecutionEnvironment.canUseDOM) { <del> rAF = function(frameCallback: (time: number) => void): number { setTimeout(frameCallback, 16); return 0; }; </del> rIC = function(frameCallback: (deadline: Deadline) => void): number { setTimeout(() => { frameCallback({

We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.


Question: 'use strict'; <del> // NOTE: We're explicitly not using JSX in this file. This is intended to test // classic JS without JSX. </del> var React; var ReactDOM; var ReactTestUtils;

The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.