Question: Follow-up for : The react-addons-* packages should have a entry in their files.

CSSTransitionGroup: { module: 'ReactCSSTransitionGroup', name: 'css-transition-group', <ins> docs: 'animation', </ins> }, LinkedStateMixin: { module: 'LinkedStateMixin', name: 'linked-state-mixin', <ins> docs: 'two-way-binding-helpers', </ins> }, Perf: { module: 'ReactDefaultPerf', name: 'perf', <ins> docs: 'perf', </ins> }, PureRenderMixin: { module: 'ReactComponentWithPureRenderMixin', name: 'pure-render-mixin', <ins> docs: 'pure-render-mixin', </ins> }, TestUtils: { module: 'ReactTestUtils', name: 'test-utils', <ins> docs: 'test-utils', </ins> }, TransitionGroup: { module: 'ReactTransitionGroup', name: 'transition-group', <ins> docs: 'animation', </ins> }, cloneWithProps: { module: 'cloneWithProps', name: 'clone-with-props', <ins> docs: 'clone-with-props', </ins> }, createFragment: { module: 'ReactFragment', method: 'create', name: 'create-fragment', <ins> docs: 'create-fragment', </ins> }, shallowCompare: { module: 'shallowCompare',

updates: { module: 'update', name: 'update', <ins> docs: 'update', </ins> }, };

pkgData.name = pkgName; grunt.file.mkdir(destDir); <ins> var link = info.docs ? info.docs : 'addons'; link = `https://facebook.github.io/react/docs/${link}.html`; </ins> fs.writeFileSync(path.join(destDir, 'index.js'), generateSource(info)); fs.writeFileSync(path.join(destDir, 'package.json'), JSON.stringify(pkgData, null, 2)); fs.writeFileSync(path.join(destDir, 'LICENSE'), license); fs.writeFileSync(path.join(destDir, 'PATENTS'), patents); fs.writeFileSync( path.join(destDir, 'README.md'), <del> '# ' + pkgName + 'nn' + 'This package provides the React ' + k + ' add-on. See ' + 'http://facebook.github.io/react/docs/addons.html for more information.n' </del> <ins> ` # ${pkgName} This package provides the React ${k} add-on. See <${link}> for more information.`.slice(1) </ins> ); });

{ <del> "name": "react-addons", </del> <ins> "name": "react-addons-template", </ins> "version": "0.15.0-alpha", "main": "index.js", <ins> "repository": "facebook/react", "keywords": [ "react", "react-addon" ], </ins> "license": "BSD-3-Clause", "peerDependencies": { "react": "^0.15.0-alpha"

"version": "0.15.0-alpha", "description": "React package for working with the DOM.", "main": "index.js", <del> "repository": { "type": "git", "url": "git+https://github.com/facebook/react.git" }, </del> <ins> "repository": "facebook/react", </ins> "keywords": [ "react" ],


Question:
Not sure if this is intentional, but if I run this: The resulting inner div has its set to . the resulting DOM string is: but if I remove the key the result is: If is used as the key, the result is the latter above.
This is intentional. is an intentional value whereas is the lack of a specified value.
If that's the case then IMHO we should escape it properly, as it is now and are treated equally by React (this should be trivial by translating it to or whatever. Although personally I'm not sure when it ever makes sense to have as a key, how about a warning too?

Get Started Download React v{{site.react_version}}   Get Started Download React v{{site.react_version}}


Question:
Calling results in: (this is on a page internally at Facebook so I assume it's a fairly recent React version)
Are you still experiencing this issue internally? If so, can you create an internal task with details and repro steps? Assign to the oncall, cc the React team. Our internal configuration is a bit different, and we don't want to discuss internal code/details/configurations on github. I'm going to close this out, and we can help you debug using internal tools if you're still running into problems.
Small note for anyone experiencing a similar error message who arrived here by Googling: I got bit by this because I updated and without updating at the same time.
I'm getting this issue after upgrading to react 15.0.1. All my React packages (including perf) is 15.0.1. printExclusive() etc. works, but printWasted gives the exception shown above.
Are you running before using it?
Yes. , and the rest of the Perf API works, for example , but not . I changed over to my 0.14.7 branch, and there everything works like it should, and I double checked that both ReactPerf and React was on 15.0.1. ! I can dig around a bit more if this isn't anything known.
Let’s reopen until we hear more.
I had it working for a few minutes and then it started failing without me doing anything strange.
Thanks for the info, do you also have the same stack trace and error message as the first post?
Yes. I was exposing the object as . I tried again exposing it as and it's working again. Puzzling. I'm using the full 15.0.1 ecosystem, on Babel 6, Webpack and Webpack dev server, testing on Chrome.
Any chance you have a public project where you can more or less consistently reproduce this?
Technically this means there was for which there was no . This code is super fragile so it’s hard to pin it down without having a specific component hierarchy that happens to cause this.
If someone wants to spend some effort tracking it down, I would recommend: just before in . just before in . Then please share the relevant logs that correspond to the ID you see in the message.
Thanks Dan, I'll try setting up that to see if I can help. Unfortunately I cannot share my project right now because of client terms.
Yeah, I thought this might be the case. Thanks for taking the time to investigate.
OK I the lines and I managed to also reproduce the error. . FYI, my app is a SPA, I captured this on a route where I have a long list of items that can be filtered by certain criteria and doing before filtering and after some of those items were removed because of the filtering.
Thank you, this is very helpful! I’ll dig into it and see if I can repro this given the new info.

// the amount of time it took to render the entire subtree. var cleanComponents = {}; var writes = measurement.writes; <ins> var hierarchy = measurement.hierarchy; </ins> var dirtyComposites = {}; Object.keys(writes).forEach(function(id) { writes[id].forEach(function(write) { // Root mounting (innerHTML set) is recorded with an ID of '' <del> if (id !== '') { measurement.hierarchy[id].forEach((c) => dirtyComposites[c] = true); </del> <ins> if (id !== '' && hierarchy.hasOwnProperty(id)) { hierarchy[id].forEach((c) => dirtyComposites[c] = true); </ins> } }); });

expect(summary).toEqual([]); }); <ins> it('should not fail on input change events', function() { var container = document.createElement('div'); var onChange = () => {}; var input = ReactDOM.render( <input checked={true} onChange={onChange} />, container ); expectNoWaste(() => { ReactTestUtils.Simulate.change(input); }); }); </ins> it('should print a table after calling printOperations', function() { var container = document.createElement('div'); var measurements = measure(() => {


Question:
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.

{{ page.title }}

{{ page.date | date_to_string }} by {{ page.author }}

 {% if content != '' %} {{ content }} {% else %} {{ page.content }} {% endif %}

Recent posts

 {% for post in site.posts %}
{{ post.title }}
 {% endfor %}

 --- layout: default sectionid: blog ---
 {% include nav_blog.html %}
 {% for page in site.posts %} {% include blog_post.html %} {% endfor %}

--- layout: default  sectionid: blog  ---

{{ page.title }}

{{ page.date | date_to_string }}

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

 --- title: JSFiddle Integration layout: post author: Vjeux --- [JSFiddle](http://jsfiddle.net) just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this **[base React JSFiddle](http://jsfiddle.net/vjeux/kb3gN/)**, fork it and share it! A [fiddle without JSX](http://jsfiddle.net/vjeux/VkebS/) is also available .

React (by Facebook) is now available on JSFiddle. facebook.github.io/react/
— JSFiddle (@jsfiddle) June 2, 2013


Question:
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.

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

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


Question:
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.

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


Question:
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.

## JSRomandie Meetup <del> [Renault John Lecoultre](https://twitter.com/renajohn/) did a React introduction talk at a JS meetup called [JS Romandie](https://twitter.com/jsromandie) last week. </del> <ins> [Renault John Lecoultre](https://twitter.com/renajohn/) from [BugBuster](http://www.bugbuster.com) did a React introduction talk at a JS meetup called [JS Romandie](https://twitter.com/jsromandie) last week. </ins> <script async class="speakerdeck-embed" data-id="888a9d50c01b01300df36658d0894ac1" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


Question:
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.

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


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

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

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


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

var ReactCurrentOwner = require('ReactCurrentOwner'); var assign = require('Object.assign'); <ins> var warning = require('warning'); </ins> var canDefineProperty = require('canDefineProperty'); // The Symbol used to tag the ReactElement type. If there is no native Symbol

__source: true, }; <ins> var specialPropKeyWarningShown, specialPropRefWarningShown; </ins> /** * Factory method to create a new React element. This no longer adheres to * the class pattern, so do not use new to call it. Also, no instanceof check

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

} } } <ins> if (__DEV__) { // Create dummy `key` and `ref` property to `props` to warn users // against its use if (typeof props.$$typeof === 'undefined' || props.$$typeof !== REACT_ELEMENT_TYPE) { if (!props.hasOwnProperty('key')) { Object.defineProperty(props, 'key', { get: function() { if (!specialPropKeyWarningShown) { specialPropKeyWarningShown = true; warning( false, '%s: `key` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)', 'displayName' in type ? type.displayName: 'Element' ); } return undefined; }, configurable: true, }); } if (!props.hasOwnProperty('ref')) { Object.defineProperty(props, 'ref', { get: function() { if (!specialPropRefWarningShown) { specialPropRefWarningShown = true; warning( false, '%s: `ref` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)', 'displayName' in type ? type.displayName: 'Element' ); } return undefined; }, configurable: true, }); } } } </ins> return ReactElement( type, key,

expect(element.props).toEqual(expectation); }); <ins> it('should warn when `key` is being accessed', function() { spyOn(console, 'error'); var container = document.createElement('div'); var Child = React.createClass({ render: function() { return <div> {this.props.key} </div>; }, }); var Parent = React.createClass({ render: function() { return ( <div> <Child key="0" /> <Child key="1" /> <Child key="2" /> </div> ); }, }); expect(console.error.calls.length).toBe(0); ReactDOM.render(<Parent />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Child: `key` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)' ); }); it('should warn when `ref` is being accessed', function() { spyOn(console, 'error'); var container = document.createElement('div'); var Child = React.createClass({ render: function() { return <div> {this.props.ref} </div>; }, }); var Parent = React.createClass({ render: function() { return ( <div> <Child ref="childElement" /> </div> ); }, }); expect(console.error.calls.length).toBe(0); ReactDOM.render(<Parent />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Child: `ref` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)' ); }); </ins> it('allows a string to be passed as the type', function() { var element = React.createFactory('div')(); expect(element.type).toBe('div');


Question:
A component should either be using uncontrolled inputs or controlled inputs, but not both (they should pick a single paradigm, for the lifetime of the component). As a result, an instance of an input should never switch from controlled to uncontrolled (or vice versa). We should warn when an input that was previously controlled becomes uncontrolled, or vice versa.
Could you provide some code as to how a controlled input becomes uncontrolled and vice versa?
I just got this warning, can anyone point me to an explanation with a bit more detail? ty
put your code in a stackoverflow question, and link it here.
newswim Read about controlled components and uncontrolled components. Choose one (preferably controlled components), and don't ever use uncontrolled components. If you are using controlled components, make sure you never pass a or to React. And yes, is correct, this is better addressed on StackOverflow.
I don't consider an input's value being null or undefined as a qualifying factor in determining if an input is controlled or uncontrolled. Controlled forms are a paradigm that may share some qualities with uncontrolled forms. It's about listening to changes and updating the state of the value, but React shouldn't stipulate that the value can't be undefined. It's an additional burden to those following good practice in using controlled forms. This warning should occur if both defaultValue and value props are used throughout the input's lifecycle.
I agree, but in the sense that they shouldn't be a single component at all, they should be two separate. Regardless I would say that actually providing the correct string value to an interactive component that expects a string value seems like a rather good practice. Otherwise you will have two distinct value states and , but both being intended to mean the exact same thing. No, because being or makes it uncontrolled by definition and you shouldn't switch between controlled and uncontrolled.

var didWarnValueNull = false; var didWarnValueDefaultValue = false; var didWarnCheckedDefaultChecked = false; <ins> var didWarnControlledToUncontrolled = false; var didWarnUncontrolledToControlled = false; </ins> function forceUpdateIfMounted() { if (this._rootNodeID) {

listeners: null, onChange: _handleChange.bind(inst), }; <ins> if (__DEV__) { inst._wrapperState.controlled = props.checked !== undefined || props.value !== undefined; } </ins> }, updateWrapper: function(inst) {

if (__DEV__) { warnIfValueIsNull(props); <ins> var initialValue = inst._wrapperState.initialChecked || inst._wrapperState.initialValue; var defaultValue = props.defaultChecked || props.defaultValue; var controlled = props.checked !== undefined || props.value !== undefined; var owner = inst._currentElement._owner; if ( (initialValue || !inst._wrapperState.controlled) && controlled && !didWarnUncontrolledToControlled ) { warning( false, '%s is changing a uncontrolled input of type %s to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components', owner && owner.getName() || 'A component', props.type ); didWarnUncontrolledToControlled = true; } if ( inst._wrapperState.controlled && (defaultValue || !controlled) && !didWarnControlledToUncontrolled ) { warning( false, '%s is changing a controlled input of type %s to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components', owner && owner.getName() || 'A component', props.type ); didWarnControlledToUncontrolled = true; } </ins> } // TODO: Shouldn't this be getChecked(props)?

expect(console.error.argsForCall.length).toBe(1); }); <ins> it('should warn if controlled input switches to uncontrolled', function() { var stub = <input type="text" value="controlled" onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="text" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type text to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled input switches to uncontrolled with defaultValue', function() { var stub = <input type="text" value="controlled" onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="text" defaultValue="uncontrolled" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type text to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if uncontrolled input switches to controlled', function() { var stub = <input type="text" />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="text" value="controlled" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a uncontrolled input of type text to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled checkbox switches to uncontrolled', function() { var stub = <input type="checkbox" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="checkbox" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type checkbox to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled checkbox switches to uncontrolled with defaultChecked', function() { var stub = <input type="checkbox" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="checkbox" defaultChecked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type checkbox to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if uncontrolled checkbox switches to controlled', function() { var stub = <input type="checkbox" />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="checkbox" checked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a uncontrolled input of type checkbox to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled radio switches to uncontrolled', function() { var stub = <input type="radio" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="radio" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type radio to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled radio switches to uncontrolled with defaultChecked', function() { var stub = <input type="radio" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="radio" defaultChecked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type radio to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if uncontrolled radio switches to controlled', function() { var stub = <input type="radio" />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="radio" checked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a uncontrolled input of type radio to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); </ins> it('sets type before value always', function() { var log = []; var originalCreateElement = document.createElement;


Question:
is currently only supported as element, not as attribute in . Since it is unknown to react it's thrown away on render.
I'd like to take this!
It's yours Let me know if you have any questions.
Cool! :+1:
Can we get this into a PR pretty please? :o)
Umm this was merged 3 years ago already...
my apologies. I came across this from a Google search after using cite in blockquote in React 16.8.6 was throwing an error for me at build time. I'll have to dig deeper into the cause.

charSet: null, challenge: null, checked: MUST_USE_PROPERTY | HAS_BOOLEAN_VALUE, <ins> cite: null, </ins> classID: null, className: null, cols: HAS_POSITIVE_NUMERIC_VALUE,


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

// For quickly matching children type, to test if can be treated as content. var CONTENT_TYPES = {'string': true, 'number': true}; <del> var CHILDREN = keyOf({children: null}); </del> var STYLE = keyOf({style: null}); var HTML = keyOf({__html: null}); <ins> var RESERVED_PROPS = { children: null, dangerouslySetInnerHTML: null, suppressContentEditableWarning: null, }; </ins> function getDeclarationErrorAddendum(internalInstance) { if (internalInstance) {

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

deleteListener(this, propKey); } } else if (isCustomComponent(this._tag, nextProps)) { <del> if (propKey === CHILDREN) { nextProp = null; </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { DOMPropertyOperations.setValueForAttribute( getNode(this), propKey, nextProp ); </ins> } <del> DOMPropertyOperations.setValueForAttribute( getNode(this), propKey, nextProp ); </del> } else if (this._namespaceURI === DOMNamespaces.svg) { <del> DOMPropertyOperations.setValueForSVGAttribute( getNode(this), propKey, nextProp ); </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { DOMPropertyOperations.setValueForSVGAttribute( getNode(this), propKey, nextProp ); } </ins> } else if ( DOMProperty.properties[propKey] || DOMProperty.isCustomAttribute(propKey)) {

expect(stubStyle.display).toEqual(''); }); <del> it('should skip child object attribute on web components', function() { </del> <ins> it('should skip reserved props on web components', function() { </ins> var container = document.createElement('div'); <del> // Test initial render to null ReactDOM.render(<my-component children={['foo']} />, container); </del> <ins> ReactDOM.render( <my-component children={['foo']} suppressContentEditableWarning={true} />, container ); </ins> expect(container.firstChild.hasAttribute('children')).toBe(false); <ins> expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); </ins> <del> // Test updates to null ReactDOM.render(<my-component children={['foo']} />, container); </del> <ins> ReactDOM.render( <my-component children={['bar']} suppressContentEditableWarning={false} />, container ); </ins> expect(container.firstChild.hasAttribute('children')).toBe(false); <ins> expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); }); it('should skip dangerouslySetInnerHTML on web components', function() { var container = document.createElement('div'); ReactDOM.render( <my-component dangerouslySetInnerHTML={{__html: 'hi'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); ReactDOM.render( <my-component dangerouslySetInnerHTML={{__html: 'bye'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); }); it('should skip reserved props on SVG components', function() { var container = document.createElement('div'); ReactDOM.render( <svg children={['foo']} suppressContentEditableWarning={true} />, container ); expect(container.firstChild.hasAttribute('children')).toBe(false); expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); ReactDOM.render( <svg children={['bar']} suppressContentEditableWarning={false} />, container ); expect(container.firstChild.hasAttribute('children')).toBe(false); expect( container.firstChild.hasAttribute('suppressContentEditableWarning') ).toBe(false); }); it('should skip dangerouslySetInnerHTML on SVG components', function() { var container = document.createElement('div'); ReactDOM.render( <svg dangerouslySetInnerHTML={{__html: 'hi'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); ReactDOM.render( <svg dangerouslySetInnerHTML={{__html: 'bye'}} />, container ); expect( container.firstChild.hasAttribute('dangerouslySetInnerHTML') ).toBe(false); </ins> }); it('should remove attributes', function() {


Question: Looks like is broken on a fresh checkout. Just doing a and locally results in running jasmine1, but running the same commands on a fresh checkout attempts to run jasmine2 and results in 300+ failing unit tests.

"scriptPreprocessor": "scripts/jest/preprocessor.js", "setupEnvScriptFile": "scripts/jest/environment.js", "setupTestFrameworkScriptFile": "scripts/jest/test-framework-setup.js", <ins> "testRunner": "jasmine1", </ins> "testFileExtensions": [ "coffee", "js",


Question:
Run this: Get this: Not sure if this is a bug but I thought and friends are gone in , no? Also when testing with an old project using - which has a much complex scenario, returned following causing a blank page: Just wondering is the behavior for server rendering changing in ? Thanks.
is gone for client-side rendering, but still exists for server-side rendering. This is expected behavior. However, is NOT desired output. Can you provide an example component/render that generates this output?
This happens when a root composite component returns .
I spent all day trying to trace the root cause of the issue and ended up confirmed it's a false alarm, it was caused by lib which returns a null root component while rendering on the server. I'm currently working on different approaches to implement universal apps on both server and client, will report back if I hit any other issues with v15.
But, to be clear, this is a valid bug in React.
Update: just confirmed that is working fine with other apps in regard to server rendering once removed . One thing to note though I saw a lot of comments for text like this, just wondering is it necessary?
Right, but the use case that mentioned clearly demonstrates the bug. It's necessary for tracking separating the text elements in order to apply updates/diffs.
Understood, thanks for the explanation.

var adler32 = require('adler32'); var TAG_END = //?>/; <ins> var COMMENT_START = /^<!--/; </ins> var ReactMarkupChecksum = { CHECKSUM_ATTR_NAME: 'data-react-checksum',

addChecksumToMarkup: function(markup) { var checksum = adler32(markup); <del> // Add checksum (handle both parent tags and self-closing tags) return markup.replace( TAG_END, ' ' + ReactMarkupChecksum.CHECKSUM_ATTR_NAME + '="' + checksum + '"$&' ); </del> <ins> // Add checksum (handle both parent tags, comments and self-closing tags) if (markup.test(COMMENT_START)) { return markup; } else { return markup.replace( TAG_END, ' ' + ReactMarkupChecksum.CHECKSUM_ATTR_NAME + '="' + checksum + '"$&' ); } </ins> }, /**

); }); <ins> it('should generate comment markup for component returns null', function() { var NullComponent = React.createClass({ render: function() { return null; }, }); var response = ReactServerRendering.renderToString(<NullComponent />); expect(response).toBe('<!-- react-empty: 1 -->'); }); </ins> it('should not register event listeners', function() { var EventPluginHub = require('EventPluginHub'); var cb = jest.genMockFn();


Question:
Pasting the exact code from into a HTML file and opening it through a Python 3.4 HTTP server for some reason gives the following error in Chrome: I'm able to work around this completely by removing the and attributes from the React and React-Dom script tags: I've never had this issue in Chrome before, and I frequently include external scripts with and attributes with no problem, so I'm lead to believe this may have something to do with the way is configured.
I can’t find mentions of or on that page. Can you help me understand where you see it?
Ah, my mistake, this comes when copying over the elements from the Downloads page: , not the tutorial page. I've updated the main post.
Thanks. I can reproduce this. Can you give any insight into this?
Something like might help.
The problem is that the headers aren't being set on the server, so the python gist is irrelevant / will not solve this issue. This is a security feature of browsers, since checking integrity can leak information about the content of the response. fbcdn does allow all origins, but does not, which is the root cause of the error here. Does serve anything directly, or is always just redirects? If it always just redirects, we might be able to blindly enable the CORS headers on without any security impact (thereby relying on the redirect-destination to control the CORS permissions). Otherwise, we would need to enable the cross-origin headers for individual URLs, which will require adding data to the fburl database, which is probably a more intense task. Another option is to use a different URL (not ). Could link directly to the CDN, for instance. I think the shortest term solution is to remove the offending attributes from the script tag, which makes the tags look cleaner/simpler (read: less scary to new user) anyway.
Oh okay, thanks :+1:
is always a redirect, but I thought it was set up right such that this worked. I thought I checked the headers when I those attributes to the docs... maybe not… I think ultimately we shouldn't use but haven't gone and done that yet. We might just set up a little mini-cdn of our own since we have some other issues with the older links (corrupted cache somewhere that we thought we tracked down but still see occasional issues). cdnjs and jsdelivr are both great external third-party options right now so I definitely recommend them over regardless. We just need some control when we ship releases so relying on them entirely isn't in the cards. I think we should keep the attributes (when they work) - moving towards a world with these checks is a good thing and we can help promote these features. But shorter-term, yea that's fine.
I've used CloudFront in the past, and can certify that it's totally awesome. FWIW.

The uncompressed, development version of [react.js](https://fb.me/react-{{site.react_version}}.js) and [react-dom.js](https://fb.me/react-dom-{{site.react_version}}.js) with inline documentation (you need both files). ```html <del> <script src="https://fb.me/react-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.dev}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.dom_dev}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js"></script> </ins> ``` #### React {{site.react_version}} (production) The compressed, production version of [react.js](https://fb.me/react-{{site.react_version}}.min.js) and [react-dom.js](https://fb.me/react-dom-{{site.react_version}}.min.js) (you need both). ```html <del> <script src="https://fb.me/react-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.prod}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.dom_prod}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-{{site.react_version}}.min.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js"></script> </ins> ``` #### React with Add-Ons {{site.react_version}} (development) The uncompressed, development version of React with [optional add-ons](/react/docs/addons.html). ```html <del> <script src="https://fb.me/react-with-addons-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.addons_dev}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js" integrity="sha384-{{site.react_hashes.dom_dev}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-with-addons-{{site.react_version}}.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.js"></script> </ins> ``` #### React with Add-Ons {{site.react_version}} (production) The compressed, production version of React with [optional add-ons](/react/docs/addons.html). ```html <del> <script src="https://fb.me/react-with-addons-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.addons_prod}}" crossorigin="anonymous"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js" integrity="sha384-{{site.react_hashes.dom_prod}}" crossorigin="anonymous"></script> </del> <ins> <script src="https://fb.me/react-with-addons-{{site.react_version}}.min.js"></script> <script src="https://fb.me/react-dom-{{site.react_version}}.min.js"></script> </ins> ``` All scripts are also available via [CDNJS](https://cdnjs.com/libraries/react/).


Question:
Appears to be working in Firefox but at least Chrome & Safari are broken. Should be a really recent regression so very few possible changes to blame... Easiest repo: the todo list on our homepage.
Just a heads up but this still seems to be an issue even on 15.4.1. I've been struggling to reproduce this because it seems to be some sort of ninja bug. Nevertheless, I was wondering if anyone is still dealing with this problem?
I haven't seen anything.
I'm still seeing this issue.
Please open a new issue with a simplified repro case if you're still seeing this!

'use strict'; var ReactChildren = require('ReactChildren'); <ins> var ReactDOMComponentTree = require('ReactDOMComponentTree'); </ins> var ReactDOMSelect = require('ReactDOMSelect'); var warning = require('warning');

inst._wrapperState = {selected: selected}; }, <ins> postMountWrapper: function(inst) { // value="" should make a value attribute (#6219) var props = inst._currentElement.props; if (props.value != null) { var node = ReactDOMComponentTree.getNodeFromInstance(inst); node.setAttribute('value', props.value); } }, </ins> getNativeProps: function(inst, props) { var nativeProps = Object.assign({selected: undefined, children: undefined}, props);

var node = ReactDOM.findDOMNode(stub); expect(node.innerHTML).toBe('foobar'); }); <ins> it('should set attribute for empty value', function() { var container = document.createElement('div'); var option = ReactDOM.render(<option value="" />, container); expect(option.hasAttribute('value')).toBe(true); expect(option.getAttribute('value')).toBe(''); ReactDOM.render(<option value="lava" />, container); expect(option.hasAttribute('value')).toBe(true); expect(option.getAttribute('value')).toBe('lava'); }); </ins> });

var propName = propertyInfo.propertyName; // Must explicitly cast values for HAS_SIDE_EFFECTS-properties to the // property type before comparing; only `value` does and is string. <del> // Must set `value` property if it is not null and not yet set. </del> if (!propertyInfo.hasSideEffects || <del> ('' + node[propName]) !== ('' + value) || !node.hasAttribute(propertyInfo.attributeName)) { </del> <ins> ('' + node[propName]) !== ('' + value)) { </ins> // Contrary to `setAttribute`, object properties are properly // `toString`ed by IE8/9. node[propName] = value;

); } <ins> function optionPostMount() { var inst = this; ReactDOMOption.postMountWrapper(inst); } </ins> // There are so many media events, it makes sense to just // maintain a list rather than create a `trapBubbledEvent` for each var mediaEvents = {

); } break; <ins> case 'option': transaction.getReactMountReady().enqueue( optionPostMount, this ); </ins> } return mountImage;

describe('ReactDOMComponent', function() { var React; var ReactDOM; <del> var ReactDOMFeatureFlags; </del> var ReactDOMServer; beforeEach(function() { jest.resetModuleRegistry(); React = require('React'); <del> ReactDOMFeatureFlags = require('ReactDOMFeatureFlags') </del> ReactDOM = require('ReactDOM'); ReactDOMServer = require('ReactDOMServer'); });

expect(nodeValueSetter.mock.calls.length).toBe(expected); } <del> if (ReactDOMFeatureFlags.useCreateElement) { renderWithValueAndExpect(undefined, 0); renderWithValueAndExpect('', 1); renderWithValueAndExpect('foo', 2); renderWithValueAndExpect('foo', 2); renderWithValueAndExpect(undefined, 3); renderWithValueAndExpect(null, 3); renderWithValueAndExpect('', 4); renderWithValueAndExpect(undefined, 4); } else { renderWithValueAndExpect(undefined, 0); // This differs because we will have created a node with the value // attribute set. This means it will hasAttribute, so we won't try to // set the value. renderWithValueAndExpect('', 0); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect(undefined, 2); renderWithValueAndExpect(null, 2); // Again, much like the initial update case, we will always have the // attribute set so we won't set the value. renderWithValueAndExpect('', 2); renderWithValueAndExpect(undefined, 2); } </del> <ins> renderWithValueAndExpect(undefined, 0); renderWithValueAndExpect('', 0); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect(undefined, 2); renderWithValueAndExpect(null, 2); renderWithValueAndExpect('', 2); renderWithValueAndExpect(undefined, 2); </ins> }); it('should not incur unnecessary DOM mutations for boolean properties', function() {


Question:
Now that react-python is being completely deprecated and will probably cease to function soon with new versions of react ( ) the docs should probably no longer link to it from the Use React and JSX in Python Applications page.
For those following along, I assume is referring to It's an old blog post (with a date), not part of the living docs. We generally don't go back in time and update old posts because things are constantly changing over time and it's hard enough to just keep the main documentation up-to-date. If someone wants to add a red note box that says "Update: PyReact is now deprecated", I think I would be ok with that and we would likely accept such a PR. cc because he feels the strongest about updating historical posts. Anyway, I'm going to close this out to take it off our radar, because we don't generally track/update historical posts.
Meh, If somebody did want to add a note like that, that would be fine. But I don't think we need to change the content of the post. And linking to the actual project is probably good because it has a nice big deprecated notice in the readme.
Ah, I actually hadn't noticed that it's a blog post. It's the thing that comes up when you google "react python" (or anything similar) and is formatted the same as the rest of React's documentation. But yeah, it seems like a shame to have to keep every old blog post up to date. (I suppose after JSXTransformer becomes completely nonfunctional it might be worth making PyReact's deprecation notice a bit stronger, but at this point it's really just nitpicking)

integrity sha512-zIURGIS1E1Q4pcrMjp+nnEh+16G56eG/MUllJH8yEvw7asDo7Ac9uhC9KIH5jzpITueEZolfYglnCGIuSBz39g== axios@^1.6.1: <del> version "1.7.1" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.1.tgz#522145622a09dfaf49359837db9649ff245a35b9" integrity sha512-+LV37nQcd1EpFalkXksWNBiA17NZ5m5/WspmHGmZmdx1qBOg/VNq/c4eRJiA9VQQHBOs+N0ZhhdU10h2TyNK7Q== </del> <ins> version "1.7.4" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.4.tgz#4c8ded1b43683c8dd362973c393f3ede24052aa2" integrity sha512-DukmaFRnY6AzAALSH4J2M3k6PkaC+MfaAGdEERRWcC9q3/TWQwLpHR8ZRLKTdQ3aBDL64EdluRDjJqKw+BPZEw== </ins> dependencies: follow-redirects "^1.15.6" form-data "^4.0.0"


Question:
The does not accept a node engine of version 6.x I don't think that there is some regressions caused by Node v6, so it should be okay?
there is in npm package.
My bad, -- I meant the , you cannot without getting an error with Node v6.0.0.


Question:
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

} } }, <ins> isProfiling() { return isProfiling; }, </ins> beginProfiling() { if (__DEV__) { if (isProfiling) {

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

printOperations, start, stop, <ins> isRunning, </ins> // Deprecated: printDOM, getMeasurementsSummaryMap,

ReactDebugTool.onTestEvent(); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isProfiling state', () => { expect(ReactDebugTool.isProfiling()).toBe(false); ReactDebugTool.beginProfiling(); expect(ReactDebugTool.isProfiling()).toBe(true); ReactDebugTool.endProfiling(); expect(ReactDebugTool.isProfiling()).toBe(false); }); </ins> });

ReactPerf.printDOM(measurements); expect(console.error.calls.length).toBe(1); }); <ins> it('returns isRunning state', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('start has no effect when already running', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.start(); expect(ReactPerf.isRunning()).toBe(true); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); it('stop has no effect when already stopped', () => { expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); ReactPerf.stop(); expect(ReactPerf.isRunning()).toBe(false); }); </ins> });


Question:
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!

var ON_CLICK_KEY = keyOf({onClick: null}); var onClickListeners = {}; <ins> function getDictionaryKey(inst) { return '.' + inst._rootNodeID; } </ins> var SimpleEventPlugin = { eventTypes: eventTypes,

// fire. The workaround for this bug involves attaching an empty click // listener on the target node. if (registrationName === ON_CLICK_KEY) { <del> var id = inst._rootNodeID; </del> <ins> var key = getDictionaryKey(inst); </ins> var node = ReactDOMComponentTree.getNodeFromInstance(inst); <del> if (!onClickListeners[id]) { onClickListeners[id] = EventListener.listen( </del> <ins> if (!onClickListeners[key]) { onClickListeners[key] = EventListener.listen( </ins> node, 'click', emptyFunction

willDeleteListener: function(inst, registrationName) { if (registrationName === ON_CLICK_KEY) { <del> var id = inst._rootNodeID; onClickListeners[id].remove(); delete onClickListeners[id]; </del> <ins> var key = getDictionaryKey(inst); onClickListeners[key].remove(); delete onClickListeners[key]; </ins> } },

return executeDispatchesAndRelease(e, false); }; <ins> var getDictionaryKey = function(inst) { return '.' + inst._rootNodeID; }; </ins> /** * This is a unified interface for event plugins to be installed and configured. *

}, /** <del> * Stores `listener` at `listenerBank[registrationName][id]`. Is idempotent. </del> <ins> * Stores `listener` at `listenerBank[registrationName][key]`. Is idempotent. </ins> * * @param {object} inst The instance, which is the source of events. * @param {string} registrationName Name of listener (e.g. `onClick`).

registrationName, typeof listener ); <ins> var key = getDictionaryKey(inst); </ins> var bankForRegistrationName = listenerBank[registrationName] || (listenerBank[registrationName] = {}); <del> bankForRegistrationName[inst._rootNodeID] = listener; </del> <ins> bankForRegistrationName[key] = listener; </ins> var PluginModule = EventPluginRegistry.registrationNameModules[registrationName];

*/ getListener: function(inst, registrationName) { var bankForRegistrationName = listenerBank[registrationName]; <del> return bankForRegistrationName && bankForRegistrationName[inst._rootNodeID]; </del> <ins> var key = getDictionaryKey(inst); return bankForRegistrationName && bankForRegistrationName[key]; </ins> }, /**

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> } },

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

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


Question:
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..

return ( <div> <button onClick={this.handleAdd}>Aggiungi Elemento</button> <del> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </ins> {items} </ReactCSSTransitionGroup> </div>

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

return ( <div> <button onClick={this.handleAdd}>Add Item</button> <del> <ReactCSSTransitionGroup transitionName="example"> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </ins> {items} </ReactCSSTransitionGroup> </div>

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

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

return ( <div> <button onClick={this.handleAdd}>Add Item</button> <del> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionEnterTimeout={500} transitionLeaveTimeout={300}> </ins> {items} </ReactCSSTransitionGroup> </div>

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

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


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

line-height: 20px; } a { color: $linkColor; text-decoration: none;

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


Question:
Do you want to request a feature or report a bug? bug What is the current behavior? does not work, the code is not executed, there are two files loaded from the Facebook servers but they both return a 5xx error 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: ). Go to and then click the link at the bottom to go to and then click on the link to jsfiddle in the text What is the expected behavior? that there is some generated output in the result pane Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Chrome (latest stable, Mac OS), Safari (Mac OS)
That’s a pretty old blogpost. I’m not sure why the integration broke, but I recommend to look at more modern examples (e.g. is up to date).
Well, this blogpost is still linked at the bottom here: So this is how I came there. By reading the guide and I thought I would get an uptodate guide with uptodate links ;-)
Fixed now. The new link is It will appear in the blog post the next time we sync our docs. Thanks!
Great. Thanks too.

> lightweight description of what the DOM should look like. We call this process **reconciliation**. Check out <del> [this jsFiddle](http://jsfiddle.net/fv6RD/3/) to see an example of </del> <ins> [this jsFiddle](http://jsfiddle.net/2h6th4ju/) to see an example of </ins> reconciliation in action. Because this re-render is so fast (around 1ms for TodoMVC), the developer


Question:
"npm run lint" fails on Windows, at least Windows 7. Error: Screenshot: ! I found this but I couldn't fix it anyway. What might it be?
I encountered the same problem. If you look into the code in , you'll find the following code: which spawns a new process using the command "node node_modules.bin .". The command tries to interpret a batch file using node. However node can interpret js files only. That's why there's a SyntaxError. A change like this should work as expected:
Would you like to send a PR if you have a working fix?
Sure. I'll fix the same problem in gulp flow task too.
I rolled this into

return function(done) { spawn( <del> process.execPath, </del> <ins> path.join('node_modules', '.bin', 'eslint' + extension), </ins> [ <del> path.join('node_modules', '.bin', 'eslint' + extension), </del> '.', ], {

return function(done) { spawn( <del> process.execPath, </del> <ins> path.join('node_modules', '.bin', 'flow' + extension), </ins> [ <del> path.join('node_modules', '.bin', 'flow' + extension), </del> 'check', '.', ],


Question:
I am using a few react components made by various libraries like material ui and i get this message on doing i can see only one version of react installed. I am using gulp and browserify for my build process. Any idea how i can solve this?
I've found this is common when modules have React as a dependency rather than a peerDependency in the npm package. If you're using webpack, I've got around this by creating an alias, perhaps you can do something similar in Gulp.
Awesome that helped.. Just sharing some ref for others Thanks.
Also please file issues in such libraries and gently ask them to use for instead .
For those who do not want to install any other packages for resolving. Configure a require key in the browserify object and that will take care of the error

static .grunt _SpecRunner.html <ins> __benchmarks__ </ins> build/ .module-cache *.gem


Question:
We need to host a standalone React component (DraftJS editor) inside a HTML5 application which will run on other JS framework, or even plain JS or jQuery. The code of the application is beyond our control, we are just a vendor of a component which adds some content, part of which is this React-based editor. Anyway, the most important part is that we need to add the component with the following code to an existing DIV. EditorComponent is a regular React component with some onClick events attached to its content (primarily toolbar buttons for the editor). I learned that React event model and its bubbling executes independently after the event bubbles all the way up to the document, and that if ev.stopPropagation() is called on native event, React events won't execute at all. That is understandable for situations where document contains only the React app / component at its root and no other content, meaning you have control over all events on the page from React code. However, when React component is just a small fraction of the entire page, it may be severely influenced by the rest of the page. The problem is that any event handling code above the component which calls ev.stopPropagation() cuts of the events of that smaller fraction, even that the event originated from the React component scope. That influencing code could very well be just some jQuery plugin, so even author of the page may not be able to rewrite their code for some special event handling. Here is a fiddle to demonstrate that: I believe that the point where the event chain breaks, allowing React to execute its events, should be the root element of React component, rather than the whole document. This way, React root element could be considered an isolation edge of the React application / component. ! I tracked the React event registration down to function ReactDOMComponent.ensureListeningTo(...) where I found the following code: I tried to change to to register the React event chain to the root of the React container, and tried it for several basic events (onClick, onMouseDown/Up) and it seems working for us as expected. React events are not influenced by stopping propagation at the native events outside of React component root, so the two differently implemented parts of the application can coexist in peace. I am not sure why ownerDocument was chosen over node in the implementation and if changing it to _node could break something important. Please advise if the proposed solution seems viable (in that case consider a change to that), or for what reasons you wouldn't recommend it.
thanks for the well thought out and detailed issue! This is something that's been requested a number of times in the past, see is an open PR that implements essentially the same solution that you've proposed, you can read the comments there for some context on why this hasn't been done yet.
Thank you! I couldn't find them, probably because I was searching by problem keywords, not solution keywords :-) I willl observe them. If I understand it correctly, if we use only some basic events e.g. onClick in our small React components, and support latest enough versions of browsers, the temporary fix should be pretty safe. Or is there some set of DOM events that React listens to that are attached automatically regardless of whether we register them or not?
I’ll close as a duplicate of
We're changing this in React 17 to attach to roots.
If you want to try it, we released 17 RC yesterday with this change:

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

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


Question:
Do you want to request a feature or report a bug? Report a bug What is the current behavior? Referring to object's method from a another method within same object, , , breaks React build in Closure Compiler under advanced optimizations. 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: ). Build a React app using Closure Compiler in advanced mode. (Unfortunately I can not provide a source of the app where I got this bug.) What is the expected behavior? An app built with Closure Compiler in advanced mode should not throw exception Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React v15.4.2 Changing to solves this issue. There are other methods of object which are using properly via call. If this makes sense, I'll prepare a PR.
Seems reasonable. A PR would be great :)

if (mutationMethod) { mutationMethod(node, value); } else if (shouldIgnoreValue(propertyInfo, value)) { <del> this.deleteValueForProperty(node, name); </del> <ins> DOMPropertyOperations.deleteValueForProperty(node, name); </ins> return; } else if (propertyInfo.mustUseProperty) { // Contrary to `setAttribute`, object properties are properly


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

})(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-41298772-1', 'facebook.github.io'); ga('send', 'pageview'); <ins> !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="https://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs"); </ins> </script> </body> </html>

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


Question:
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.

var React; var ReactDOM; var ReactDOMServer; <del> var ReactDOMFeatureFlags; </del> var ReactTestUtils; <ins> var ReactDOMFeatureFlags = require('ReactDOMFeatureFlags'); </ins> describe('ReactComponent', () => { function normalizeCodeLocInfo(str) { return str && str.replace(/(at .+?:d+)/g, '(at **)');

React = require('react'); ReactDOM = require('react-dom'); ReactDOMServer = require('react-dom/server'); <del> ReactDOMFeatureFlags = require('ReactDOMFeatureFlags'); </del> ReactTestUtils = require('react-dom/test-utils'); });

'    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); }); }); }  });

} } <ins> function warnOnFunctionType() { warning( false, '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.%s', getCurrentFiberStackAddendum() || '', ); } </ins> // This wrapper function exists because I expect to clone the code in each path // to be able to optimize each path individually by branching early. This needs // a compiler or we can do it manually. Helpers that don't need this branching

throwOnInvalidObjectType(returnFiber, newChild); } <ins> if (__DEV__) { const disableNewFiberFeatures = ReactFeatureFlags.disableNewFiberFeatures; if (!disableNewFiberFeatures && typeof newChild === 'function') { warnOnFunctionType(); } } </ins> return null; }

throwOnInvalidObjectType(returnFiber, newChild); } <ins> if (__DEV__) { if (!disableNewFiberFeatures && typeof newChild === 'function') { warnOnFunctionType(); } } </ins> if (!disableNewFiberFeatures && typeof newChild === 'undefined') { // If the new child is undefined, and the return fiber is a composite // component, throw an error. If Fiber return types are disabled,


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

} } <del> var IsMountedMixin = { </del> <ins> var IsMountedPreMixin = { </ins> componentDidMount: function () { this.__isMounted = true; <del> }, </del> <ins> } }; var IsMountedPostMixin = { </ins> componentWillUnmount: function () { this.__isMounted = false; }

injectedMixins.forEach(mixSpecIntoComponent.bind(null, Constructor)); <del> mixSpecIntoComponent(Constructor, IsMountedMixin); </del> <ins> mixSpecIntoComponent(Constructor, IsMountedPreMixin); </ins> mixSpecIntoComponent(Constructor, spec); <ins> mixSpecIntoComponent(Constructor, IsMountedPostMixin); </ins> // Initialize the defaultProps property after all mixins have been merged. if (Constructor.getDefaultProps) {

var instance; var Component = createReactClass({ displayName: 'MyComponent', <ins> mixins: [ { componentWillMount() { this.log('mixin.componentWillMount'); }, componentDidMount() { this.log('mixin.componentDidMount'); }, componentWillUpdate() { this.log('mixin.componentWillUpdate'); }, componentDidUpdate() { this.log('mixin.componentDidUpdate'); }, componentWillUnmount() { this.log('mixin.componentWillUnmount'); }, }, ], </ins> log(name) { ops.push(`${name}: ${this.isMounted()}`); },

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


Question:
for example, when the original value is '.98', we need format it to '0.98'. but it is not take effect
This is working for me -
your example is not same with mine. the key is .98 can't be formated to 0.98. Because as number they are equal.
Just housekeeping. Do we close out issues before a release with the fix has shipped or wait?
typically I close the issue once the has been merged into master
Awesome, thanks! This should land in the next minor release of React:

 const React = window.React; import Fixture from '../../Fixture'; class NumberInputDecimal extends React.Component { state = { value: '.98' }; changeValue = () => { this.setState({ value: '0.98', }); } render() { const {value} = this.state; return ( <Fixture>
{this.props.children}

 <input type="number" value={value} onChange={(e) => { this.setState({value: e.target.value}); }} /> <button onClick={this.changeValue}>change.98 to 0.98</button>
 </Fixture> ); } } export default NumberInputDecimal;

// Simulate `input.valueAsNumber`. IE9 does not support it var valueAsNumber = parseFloat(node.value, 10) || 0; <del> // eslint-disable-next-line if (value != valueAsNumber) { </del> <ins> if ( // eslint-disable-next-line value != valueAsNumber || // eslint-disable-next-line (value == valueAsNumber && node.value != value) ) { </ins> // Cast `value` to a string to ensure the value is set correctly. While // browsers typically do this as necessary, jsdom doesn't. node.value = '' + value;

}); }); <ins> it('does change the string ".98" to "0.98" with no change handler', () => { class Stub extends React.Component { state = { value: '.98', }; render() { return <input type="number" value={this.state.value} />; } } var stub = ReactTestUtils.renderIntoDocument(<Stub />); var node = ReactDOM.findDOMNode(stub); stub.setState({value: '0.98'}); expect(node.value).toEqual('0.98'); }); </ins> it('should display `defaultValue` of number 0', () => { var stub = <input type="text" defaultValue={0} />; stub = ReactTestUtils.renderIntoDocument(stub);


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


Question:
I think something like this both throws and prints success. This means that it is not safe to wrap this in a Promise like this for example: Because if this throws, then the error is silenced. The Promise was already resolved. I hit this in the ServerIntegration-test
Related:
has no render callbacks so I guess we're just not going to fix it in the old API.

* renders a div with a single child surrounded by whitespace with client render on top of bad server markup * renders >,<, and & as single child with client render on top of bad server markup * renders >,<, and & as multiple children with client render on top of bad server markup <del> * throws when rendering a string component with clean client render * throws when rendering a string component with client render on top of bad server markup * throws when rendering an undefined component with clean client render * throws when rendering an undefined component with client render on top of bad server markup * throws when rendering a number component with clean client render * throws when rendering a number component with client render on top of bad server markup </del> * renders an input with a value and an onChange with client render on top of bad server markup * renders an input with a value and readOnly with client render on top of bad server markup * renders an input with a value and no onChange/readOnly with client render on top of bad server markup

* renders >,<, and & as multiple children with clean client render * renders >,<, and & as multiple children with client render on top of good server markup * throws when rendering a string component with server string render <ins> * throws when rendering a string component with clean client render * throws when rendering a string component with client render on top of bad server markup </ins> * throws when rendering an undefined component with server string render <ins> * throws when rendering an undefined component with clean client render * throws when rendering an undefined component with client render on top of bad server markup </ins> * throws when rendering a number component with server string render <ins> * throws when rendering a number component with clean client render * throws when rendering a number component with client render on top of bad server markup </ins> * throws when rendering null with server string render * throws when rendering null with clean client render * throws when rendering null with client render on top of bad server markup

// promisified version of ReactDOM.render() function asyncReactDOMRender(reactElement, domElement) { <del> return new Promise(resolve => ReactDOM.render(reactElement, domElement, resolve), ); </del> <ins> return new Promise(resolve => { ReactDOM.render(reactElement, domElement); // We can't use the callback for resolution because that will not catch // errors. They're thrown. resolve(); }); </ins> } // performs fn asynchronously and expects count errors logged to console.error. // will fail the test if the count of errors logged is not equal to count.


Question:
This is a feature request. In React v15.6, HTMLDOMPropertyConfig, SVGDOMPropertyConfig, and ARIADOMPropertyConfig are available by them directly, e.g. . In v16, however, they are no longer available. I think they are not public parts of react-dom, but they are inevitable to implement , a library to build React DOM from an HTML text. See for how to use them.
I don't think we plan to expose them directly. Their format sometimes changes and we want to be able to make more under the hood changes to them in the future. While it is a bit annoying I encourage you to just copy and paste them (and update if you notice changes on our side).
I've created a package from .

#### React Core {{site.react_version}} (production) The compressed, production version of React core  ```html <script src="http://fb.me/react-{{site.react_version}}.min.js"></script> ```  #### React Core {{site.react_version}} (development) The uncompressed, development version of React core with inline documentation.  ```html <script src="http://fb.me/react-{{site.react_version}}.js"></script> ```  #### JSX Transform The JSX transformer used to support [XML syntax](/react/docs/syntax.html) in JavaScript.  ```html <script src="http://fb.me/JSXTransformer-{{site.react_version}}.js"></script> ```  ## Bower ```sh