Question:
When attempting to use a react class with a lowercase ClassName, the transformer is not able to display line on which the error occurred. It turns out that the event variable passed to the to function does not contain an attribute called lineNumber. An error is thrown that states: Uncaught TypeError: Cannot read property 'replace' of undefined The actual error has only the properties and . Error: Lower case component names (myClass) are no longer supported in JSX: See at
What environment/browser are you in?
I am running Yosemite and in Chrome. Also using the jsxtransformer and react provided by the CDN. On Tuesday, November 25, 2014, Paul O’Shannessy wrote: Cooper Union EE' 14

*/ function createSourceCodeErrorMessage(code, e) { var sourceLines = code.split('n'); <ins> // e.lineNumber is non-standard so we can't depend on its availability. If // we're in a browser where it isn't supported, don't even bother trying to // format anything. We may also hit a case where the line number is reported // incorrectly and is outside the bounds of the actual code. Handle that too. if (!e.lineNumber || e.lineNumber > sourceLines.length) { return ''; } </ins> var erroneousLine = sourceLines[e.lineNumber - 1]; // Removes any leading indenting spaces and gets the number of

// The error will correctly point to `url` in Firefox. e.fileName = url; } <del> e.message += url + ':' + e.lineNumber + ':' + e.column; </del> <ins> e.message += url + ':' + e.lineNumber + ':' + e.columnNumber; </ins> } else { e.message += location.href; }


Question: Hi. In the examples included in the Getting started kit from the version of react defined in in the "basic-commonjs" example is set to 0.10.0. In order for the example to work as expected it should be 0.12.0 Also using Browserify and Reactify to compile fails because of a missing jsx header in I have not tested this in other examples

"description": "Basic example of using React with CommonJS", "main": "index.js", "devDependencies": { <del> "envify": "~1.2.1", "react": "~0.10.0", "reactify": "~0.13.1", "browserify": "~3.44.2" </del> <ins> "browserify": "^6.3.3", "envify": "^3.2.0", "react": "^0.12.0", "reactify": "^0.17.1" </ins> }, "scripts": { "build": "browserify --debug --transform reactify index.js > bundle.js"


Question:
I spent the last hour trying to fix an issue that was caused by me trying to render a when the actual variable was undefined. The root cause was me misinterpreting that would return the whole instead of just (which is my bad), but the error itself and the stack trace were extremely cryptic and it took me a while to even get a clue that the reason why it wasn't working was that I was just trying to render an undefined type. This is the actual exception: And here's the stack trace: ! You can see that, ultimately, execution comes crashing down when React tries to look at on my undefined type, which of course raises an exception. The reason why this was confusing to me is that the exception happened quite far away from the source cause and, as a secondary factor, this code worked completely fine before I started porting it to Browserify and made my mistake with . This lead me to a wild set of hypotheses as to why it wasn't working, such as assuming it might be due to a regression in React 0.12 (since it's been migrating from to and I thought might have been lagging behind), to thinking it could be a problem with itself. The reason why I raise this issue is that, since passing an type won't work anyway, it would make sense if React could check for and warn about it or maybe even raise an exception (since it would crash soon after anyway). My instance was a bit more extreme and if something like this happens to someone else they'll probably know where they screwed up in the first place, but some help from React would always be welcome!
Actually returns the whole react lib + the addons. The addons are just to the object you'd get if you did . I've been using browserify the whole time and this error just came up, after updating to 0.12.1. It was working fine before, so it seems kind of weird that it's throwing an error right now. If a dev could comment on this, that'd be great.
Yea, seems like it wouldn't be a bad idea to have a check in createElement. What was working fine before? createElement didn't really exist (it was in 0.11.x but would likely not have been used). And react/addons has always been the full React object with addons inserted.
Talked it through with on IRC, same cause just not via addons. An undefined component was being used.
Yeah, I became aware of that when I figured out what the issue is, I was just thinking it would have been way more helpful if React had told me straight away that I was passing an undefined component to .
+1, I also had this issue (albeit for a different reason)
Thanks! :+1:
If you are giving the whole JSX code under the script tag of the HTML page, then the order of declaration of the components could cause this issue. When the inbuilt compiler sees a component which you've later declared in the code, it'll throw an error. However in plain terms, this just means that the component is missing.
Getting this Uncaught TypeError: Cannot read property 'createElement' of undefined Any solutions
Please ask on StackOverflow; this is hard to answer without seeing your complete code.
here is my code ...
is incorrect, should be There is no named export named . It is confusing because React is a CommonJS module, and since you’re using ES6 imports, Babel tries to map the semantics but they don’t match exactly. actually grabs from itself so you might just and use instead if it’s less confusing.
Woah, thank you for a nice clarification.

} // Resolve default props <del> if (type.defaultProps) { </del> <ins> if (type && type.defaultProps) { </ins> var defaultProps = type.defaultProps; for (propName in defaultProps) { if (typeof props[propName] === 'undefined') {

var getIteratorFn = require('getIteratorFn'); var monitorCodeUse = require('monitorCodeUse'); <ins> var warning = require('warning'); </ins> /** * Warn if there's no key explicitly set on dynamic arrays of children or

var ReactElementValidator = { createElement: function(type, props, children) { <ins> // We warn in this case but don't throw. We expect the element creation to // succeed and there will likely be errors in render. warning( type != null, 'React.createElement: type should not be null or undefined. It should ' + 'be a string (for DOM elements) or a ReactClass (for composite ' + 'components).' ); </ins> var element = ReactElement.createElement.apply(this, arguments); // The result can be nullish if a mock or a custom function is used.

validateChildKeys(arguments[i], type); } <del> var name = type.displayName; if (type.propTypes) { checkPropTypes( name, type.propTypes, element.props, ReactPropTypeLocations.prop ); } if (type.contextTypes) { checkPropTypes( name, type.contextTypes, element._context, ReactPropTypeLocations.context ); </del> <ins> if (type) { var name = type.displayName; if (type.propTypes) { checkPropTypes( name, type.propTypes, element.props, ReactPropTypeLocations.prop ); } if (type.contextTypes) { checkPropTypes( name, type.contextTypes, element._context, ReactPropTypeLocations.context ); } </ins> } return element; },

); }); <ins> it('gives a helpful error when passing null or undefined', function() { spyOn(console, 'warn'); React.createElement(undefined); React.createElement(null); expect(console.warn.calls.length).toBe(2); expect(console.warn.calls[0].args[0]).toBe( 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' ); expect(console.warn.calls[1].args[0]).toBe( 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' ); React.createElement('div'); expect(console.warn.calls.length).toBe(2); expect(() => React.createElement(undefined)).not.toThrow() }); </ins> it('should check default prop values', function() { spyOn(console, 'warn');


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

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

* @return {string} */ function getComponentKey(component, index) { <del> if (component && component.key != null) { </del> <ins> // Do some typechecking here since we call this blindly. We want to ensure // that we don't block potential future ES APIs. if (component && typeof component === 'object' && component.key != null) { </ins> // Explicit key return wrapUserProvidedKey(component.key); }


Question:
I came across this, when using . When loading a route initially where the route handler is actually inside a and then removing it from the transition group leads to an . The weird thing is that it only happens on initial load of a nested route, not when the same view is being pulled up via the menu. I'm not sure if this is an issue related or if it belongs to . But the thing is that the component either returns a react element, or it returns . It seems like an edge case maybe, because it only happens in this specific initial render setup. It could be fixed, by adding a guard to the method of :
This was probably fixed by .
I don't think this is solved. It's easy to reproduce with React 0.12.2: just have the child return from . It's rather frustrating because some other developer may change the animated component to return when data is not ready, and not realize that this breaks the case when that component is inside the transition group.
Yup ran into this as well. If you pass a component to ReactCSSTransitionGroup that renders null you get this exception. Using React 0.12.1
Can you please reopen?
i've get the same exception, too. Hope this will be fixed soon.
is there anything stopping you people from implementing the suggested fix? :)
I'm encountering a similar issue.
I guess a PR would be welcome?
yeah, there is is!
I'm still seeing this issue. And can verify that it only happens when I return null. React with addons v0.13.3
Yes, the fix is in 0.14.
Ahh.. well that would explain things. How can I get my hands on 0.14?
Sorry – not released yet, but hopefully in the next few weeks. 0.14-beta is on npm (see the React blog).

transition: function(animationType, finishCallback) { var node = React.findDOMNode(this); <ins> if (!node) { if (finishCallback) { finishCallback(); } return; } </ins> var className = this.props.name + '-' + animationType; var activeClassName = className + '-active'; var noEventTimeout = null;


Question:
If the contents of the element is constructed in special way, it breaks React on component update with "Unable to find element" error. Here's an example of method body: Here's working jsfiddle (with React 0.12.0): Adding to option props fixes the issue.
React separates the 's children with s. In HTML only text is allowed there and the browser handles it gracefully by removing the s. On the next render React tries to change those s, but can't find them. A workaround is to give a string to the :
Thanks for explaining this. In such case probably the best solution would be to extend error explanation with information about "option" elements (behind "table" etc).
Yea, we should probably do some checks in our ReactDOMOption wrapper and not allow anything but text as children.
Just hit this
This can be fixed by using ReactChildren.forEach in ReactDOMOption to flatten the children before passing it to the raw HTML component. Strings and numbers get concatted together; other elements should be skipped and log a warning for invalid children.

'use strict'; var ReactBrowserComponentMixin = require('ReactBrowserComponentMixin'); <ins> var ReactChildren = require('ReactChildren'); </ins> var ReactClass = require('ReactClass'); var ReactDOMSelect = require('ReactDOMSelect'); var ReactElement = require('ReactElement');

props = assign({}, props, {selected: this.state.selected}); } <del> return option(props, this.props.children); </del> <ins> var content = ''; // Flatten children and warn if they aren't strings or numbers; // invalid types are ignored. ReactChildren.forEach(this.props.children, function(child) { if (child == null) { return; } if (typeof child === 'string' || typeof child === 'number') { content += child; } else { warning( false, 'Only strings and numbers are supported as <option> children.' ); } }); return option(props, content); </ins> } });

<ins> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; /*jshint evil:true */ describe('ReactDOMOption', function() { var React; var ReactTestUtils; beforeEach(function() { React = require('React'); ReactTestUtils = require('ReactTestUtils'); }); it('should flatten children to a string', function() { var stub = <option>{1} {'foo'}</option>; stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(node.innerHTML).toBe('1 foo'); }); it('should ignore invalid children types', function() { var stub = <option>{1} <div /> {2}</option>; stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(node.innerHTML).toBe('1  2'); }); it('should warn when passing invalid children', function() { var stub = <option>{1} <div /></option>; spyOn(console, 'error'); stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(console.error.calls.length).toBe(1); expect(console.error.calls[0].args[0]).toContain( 'Only strings and numbers are supported as <option> children.' ); }); it('should ignore null/undefined/false children without warning', function() { var stub = <option>{1} {false}{true}{null}{undefined} {2}</option>; spyOn(console, 'error'); stub = ReactTestUtils.renderIntoDocument(stub); var node = React.findDOMNode(stub); expect(console.error.calls.length).toBe(0); expect(node.innerHTML).toBe('1  2'); }); }); </ins>


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

matrix: fast_finish: true allow_failures: <del> - env: TEST_TYPE=lint </del> - env: TEST_TYPE=test:coverage - env: TEST_TYPE=perf:full - env: TEST_TYPE=test:webdriver:saucelabs:modern

'use strict'; <del> var exec = require('child_process').exec; </del> var jsxTask = require('./grunt/tasks/jsx'); var browserifyTask = require('./grunt/tasks/browserify'); var populistTask = require('./grunt/tasks/populist');

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


Question:
tl;dr: If you have a component that returns and it rerenders, the noscript tag is unmounted and a new one is created because shouldUpdateReactComponent gets and and returns false. This came out of some internal components that were breaking after the most recent update. I haven't gone to see if this is more widely broken - it might have been before any of the recent updates, just that the empty component is triggering it reliably. I've been some reports of having similar weird problems that we couldn't track down. It's use of is very similar to what's happening in . The trigger here is that we're triggering an update during the mount phase. When we do this works correctly because it's before which is triggering to rerender. is the broken one because its hasn't been called yet. So we actually call its first. Then we still call its . There's also the whole question of why we're trying to unmount anything at all here. It seems like we shouldn't be doing that. cc Drop this into examples/basic-jsx-harmony and debug with pausing on caught exceptions. I some breakpoints in ReactEmptyComponent to make it super obvious.
Why it's unmounting: When comparing the old to the new in , is actually whereas is , so returns false.
Why it's throwing: the three componentDidMount calls get queued in the order they were rendered (Child 0's null, Child 1, Child 2's null), but because batching doesn't happen on an initial render (something I've been meaning to make happen…), the forceUpdate happens synchronously and causes the unmount/remount of both child components, after which the old enqueued Child 2 null did-mount callback runs and throws, because that component isn't mounted any more.
(Two issues; we should fix both.)
The first one is a new regression, right?
Not sure, but I think so. I a test recently to ensure that text components don't get remounted on update; we should add one for empty components too.
Initial render isn't asynchronous but to change it, I think we'd need to change the API to pass the instance to a callback instead of synchronously returning it. We should be able to queue up new updates during initial render though. So that they're guaranteed to happen after the queue as processed.
Right -- that's what we do already for new mounts of child components within a larger update.
The second issue should be fixed now because we batch on initial render. Not sure about the first; it's probably still a problem.
I just ran into this (I think) and made a JSFiddle for it
Maybe you can fix this.
Suggestion to use instead of so that it doesn't mess up s and s.

var ReactEmptyComponentType = function() {}; ReactEmptyComponentType.prototype.componentDidMount = function() { var internalInstance = ReactInstanceMap.get(this); <ins> // TODO: Make sure we run these methods in the correct order, we shouldn't // need this check. We're going to assume if we're here it means we ran // componentWillUnmount already so there is no internal instance (it gets // removed as part of the unmounting process). if (!internalInstance) { return; } </ins> registerNullComponentID(internalInstance._rootNodeID); }; ReactEmptyComponentType.prototype.componentWillUnmount = function() { var internalInstance = ReactInstanceMap.get(this); <ins> // TODO: Get rid of this check. See TODO in componentDidMount. if (!internalInstance) { return; } </ins> deregisterNullComponentID(internalInstance._rootNodeID); }; ReactEmptyComponentType.prototype.render = function() {

'Invariant Violation: React.render(): Invalid component element.' ); });  it('does not break when updating during mount', function() { var Child = React.createClass({ componentDidMount() { this.props.onMount && this.props.onMount(); }, render() { if (!this.props.visible) { return null; } return
hello world
; } }); var Parent = React.createClass({ update() { this.forceUpdate(); }, render() { return (
 <Child key="1" visible={false} /> <Child key="0" visible={true} onMount={this.update} /> <Child key="2" visible={false} />
 ); } }); expect(function() { ReactTestUtils.renderIntoDocument(<Parent/>) }).not.toThrow(); });  });


Question:
is unclear on when it is called with regards to the function. The docs state that it's "Invoked immediately after updating occurs" but it is unclear what is meant with updating in this case: it can refer to either the component as a whole updating (meaning post-render), or it can refer to setState() having been processed (which might mean pre-render). It would be good to explicitly state when this function fires in its documentation (even if somewhere else on the site this is described in text or graphic form already).
I think this part makes it clear it happens after DOM is updated (post-render): However, overall I agree more descriptive (visual?) lifecycle explanation would be welcome.
That's not clear enough, though. React does a good job making sure you normally don't work on the DOM, so in this case I really need explicit text that says "Use this as an opportunity to operate on the DOM after has finished" - without that, it still entirely possible that it's offering a way to mess with the DOM before updates from subsequent render calls are worked in.
This wouldn't be entirely correct though. doesn't do anything per se, it just builds the virtual DOM tree.
componentDidUpdate (and componentDidMount) is always called after the DOM has been updated – we can update the docs. Want to send a pull request?
I'll have to read through your CLA carefully before I can file any PRs. In the mean time, any clarification you deem addresses this issue is fine by me.
The fact that it lets you operate on the updated DOM implies that it's post-render.
sure, but I'd love to know you get that from the actual words used in the text, rather than from the text you read paired with your knowledge of React. In this case, three people went "it's after the DOM updates", so: sweet! Let's change the text from to and now it's no longer implied, now it's explicit, and new users don't scratch their head going "what do they mean with updated? The tutorials mostly talk about updating in the sense of the state and props changing, but the text also talks about working on the DOM... this isn't clear enough".
looks like PR material to me :) :+1:
indeed, and I'm not filing one until I've read that CLA. I have issues with CLAs, which is why I'm filing this as an issue instead, and hopefully other people working on the code find opening the docs file on github, hitting "edit", and dropping that in, not too much work.
I saw that this had been closed but it appears that the documentation remains unchanged. PR seems to have been merged but I'm not sure what ever became of that since it was over 3 years ago. Perhaps the language was reverted to its original form? I think the most important takeaway from original post is that documentation should always be as explicit as possible. The fact that two people from the React team responded by saying things along the lines of "The fact that it lets you operate on the updated DOM implies that it's post-render" highlights the problem. Nothing in documentation—especially for such a widely used library—should ever be implied because it lends to assuming that the reader has the same knowledge and understanding of the code as the people who wrote it.
To chime in: is componentDidUpdate called regardless of whether there are DOM changes? In the case when render runs And there is no change between the DOM and virtual DOM, does componentDidUpdate still fire? Sorry if this should be obvious.
I'd like to know this as well. In my case, I change state, render is called, my component and it's child component both invoke their own render, but the parent's componentDidUpdate() is never fired. So, does this only file if the real DOM actually changed, or does it fire post-render, whether or not the real dom changed? FYI: my real dom did change, but the method was never called! Inquiring minds want to know!!
As pointed out, the clarification in the docs seems to have been reverted and this issue should be re-opened
If there is an issue with documentation, please file it in the documentation repository: Then we or somebody else can address it. We're not reading closed issues (it's hard enough to keep up with open ones!) so your feedback is unfortunately going into the void. Thank you!

componentDidUpdate(object prevProps, object prevState) ``` <del> Invoked immediately after updating occurs. This method is not called for the initial render. </del> <ins> Invoked immediately after the component's updates are flushed to the DOM. This method is not called for the initial render. </ins> Use this as an opportunity to operate on the DOM when the component has been updated.


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

'--harmony', 'Turns on JS transformations such as ES6 Classes etc.' ).option( <ins> '--target [version]', 'Specify your target version of ECMAScript. Valid values are "es3" and ' + '"es5". The default is "es5". "es3" will avoid uses of defineProperty and ' + 'will quote reserved words. WARNING: "es5" is not properly supported, even ' + 'with the use of es5shim, es5sham. If you need to support IE8, use "es3".', 'es5' ).option( </ins> '--strip-types', 'Strips out type annotations.' ).option(

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

options.sourceType = 'nonStrict6Module'; } <ins> // Instead of doing any fancy validation, only look for 'es3'. If we have // that, then use it. Otherwise use 'es5'. options.es3 = opts.target === 'es3'; options.es5 = !options.es3; </ins> return options; }

if (options.harmony) { visitorSets.push('harmony'); } <ins> if (options.es3) { visitorSets.push('es3'); } </ins> if (options.stripTypes) { // Stripping types needs to happen before the other transforms // unfortunately, due to bad interactions. For example,

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

'es6-rest-params': es6RestParameters.visitorList, 'es6-templates': es6Templates.visitorList, 'es7-spread-property': es7SpreadProperty.visitorList, <del> 'react': react.visitorList.concat(reactDisplayName.visitorList) </del> <ins> 'react': react.visitorList.concat(reactDisplayName.visitorList), 'reserved-words': reservedWords.visitorList </ins> }; var transformSets = {

'es6-destructuring', 'es7-spread-property' ], <ins> 'es3': [ 'reserved-words' ], </ins> 'react': [ 'react' ]

* Specifies the order in which each transform should run. */ var transformRunOrder = [ <ins> 'reserved-words', </ins> 'es6-arrow-functions', 'es6-object-concise-method', 'es6-object-short-notation',


Question:
On the first render it works, but then the update silently fails. Expected would be the semicolon being removed, or an error/warning in the development build. Tested on Chrome latest, Firefox latest, with 0.12.1 and master. Minimal: ran into (on IRC).
My first instinct is to put a warning in DEV so we don't incur any costs in prod. This would be similar to our other style key warning ("you used background-color but probably meant backgroundColor" or whatever it is we say).
sounds reasonable, I don't think there's any valid reason to have a semicolon there.
It's only a warning, but it's worth considering that is valid CSS IIRC.
so that wouldn't warn :)
Oh right :), but I've seen plenty of invalid , but perhaps that's an exercise for some other time. Anyway, you might want to ignore white-space after the as well.
I'm working on this issue. I've a warning, but thinking that it may be a good idea to trim any semicolons as well. The warning will serve to let developers know it's invalid syntax, but try and fix the problem while we're at it.

// 'msTransform' is correct, but the other prefixes should be capitalized var badVendoredStyleNamePattern = /^(?:webkit|moz|o)[A-Z]/; <ins> // style values shouldn't contain a semicolon var badStyleValueWithSemicolonPattern = /;s*$/; </ins> var warnedStyleNames = {}; <ins> var warnedStyleValues = {}; </ins> var warnHyphenatedStyleName = function(name) { if (warnedStyleNames.hasOwnProperty(name) && warnedStyleNames[name]) {

name.charAt(0).toUpperCase() + name.slice(1) + '?' ); }; <ins> var warnStyleValueWithSemicolon = function(name, value) { if (warnedStyleValues.hasOwnProperty(value) && warnedStyleValues[value]) { return; } warnedStyleValues[value] = true; warning( false, 'Style property values shouldn't contain a semicolon. ' + 'Try "%s: %s" instead.', name, value.replace(badStyleValueWithSemicolonPattern, '') ); }; /** * @param {string} name * @param {*} value */ var warnValidStyle = function(name, value) { if (name.indexOf('-') > -1) { warnHyphenatedStyleName(name); } else if (badVendoredStyleNamePattern.test(name)) { warnBadVendoredStyleName(name); } else if (badStyleValueWithSemicolonPattern.test(value)) { warnStyleValueWithSemicolon(name, value); } }; </ins> } /**

if (!styles.hasOwnProperty(styleName)) { continue; } <ins> var styleValue = styles[styleName]; </ins> if (__DEV__) { <del> if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } else if (badVendoredStyleNamePattern.test(styleName)) { warnBadVendoredStyleName(styleName); } </del> <ins> warnValidStyle(styleName, styleValue); </ins> } <del> var styleValue = styles[styleName]; </del> if (styleValue != null) { serialized += processStyleName(styleName) + ':'; serialized += dangerousStyleValue(styleName, styleValue) + ';';

continue; } if (__DEV__) { <del> if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } else if (badVendoredStyleNamePattern.test(styleName)) { warnBadVendoredStyleName(styleName); } </del> <ins> warnValidStyle(styleName, styles[styleName]); </ins> } var styleValue = dangerousStyleValue(styleName, styles[styleName]); if (styleName === 'float') {

expect(console.warn.argsForCall[1][0]).toContain('WebkitTransform'); }); <ins> it('should warn about style having a trailing semicolon', function() { spyOn(console, 'warn'); CSSPropertyOperations.createMarkupForStyles({ fontFamily: 'Helvetica, arial', backgroundImage: 'url(foo;bar)', backgroundColor: 'blue;', color: 'red;   ' }); expect(console.warn.callCount).toBe(2); expect(console.warn.argsForCall[0][0]).toContain('Try "backgroundColor: blue" instead'); expect(console.warn.argsForCall[1][0]).toContain('Try "color: red" instead'); }); </ins> });


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

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

warnedStyleNames[name] = true; warning( false, <del> 'Unsupported vendor-prefixed style property ' + name + '. Did you mean ' + name.charAt(0).toUpperCase() + name.slice(1) + '?' </del> <ins> 'Unsupported vendor-prefixed style property %s. Did you mean %s?', name, name.charAt(0).toUpperCase() + name.slice(1) </ins> ); };

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

set: function(value) { warning( false, <del> 'Don't set the ' + key + ' property of the React element. Instead, ' + 'specify the correct value when initially creating the element.' </del> <ins> 'Don't set the %s property of the React element. Instead, ' + 'specify the correct value when initially creating the element.', key </ins> ); this._store[key] = value; }

warning( false, <del> 'Don't set .props.' + propName + ' of the React component' + elementInfo + '. Instead, specify the correct value when ' + 'initially creating the element.' + ownerInfo </del> <ins> 'Don't set .props.%s of the React component%s. ' + 'Instead, specify the correct value when ' + 'initially creating the element.%s', propName, elementInfo, ownerInfo </ins> ); }

var newFn = function() { warning( warned, <del> `${namespace}.${oldName} will be deprecated in a future version. ` + `Use ${namespace}.${newName} instead.` </del> <ins> '%s.%s will be deprecated in a future version. ' + 'Use %s.%s instead.', namespace, oldName, namespace, newName </ins> ); warned = true; return fn.apply(ctx, arguments);


Question:
There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with

<del> --- pygments: true </del> <ins> --- markdown: redcarpet </ins> name: React <ins> redcarpet: extensions: - fenced_code_blocks </ins> react_version: 0.3.0 <del> exclude: </del> <ins> pygments: true exclude: </ins> - Gemfile - Gemfile.lock - README.md - Rakefile <del> redcarpet: extensions: - fenced_code_blocks markdown: redcarpet </del> baseurl: /react

Component Lifecycle

Event Handling

Advanced Components

Mixins

API

description: How to build advanced composite components. layout: docs prev: event-handling.html <del> next: api.html </del> <ins> next: mixins.html </ins> --- Composite components extend a `ReactCompositeComponent` base class that provides

id: docs-api title: React API layout: docs <del> prev: advanced-components.html </del> <ins> prev: mixins.html </ins> --- ## React

<ins> --- id: docs-mixins title: Mixins layout: docs prev: advanced-components.html next: api.html --- Mixins allow code to be shared between multiple React components. They are pretty similar to mixins in Python or traits in PHP. Let's look at a simple example: ```javascript var MyMixin = { getMessage: function() { return 'hello world'; } }; var MyComponent = React.createClass({ mixins: [MyMixin], render: function() { return <div>{this.getMessage()}</div>; } }); ``` A class can use multiple mixins, but no two mixins can define the same method. Two mixins can, however, implement the same [lifecycle method](component-lifecycle.html). In this case, each implementation will be invoked one after another. The only exception is the `shouldComponentUpdate` lifecycle method. This method may only be implemented once (either by a mixin or by the component). ```javascript var Mixin1 = { componentDidMount: function() { console.log('Mixin1.componentDidMount()'); } }; var Mixin2 = { componentDidMount: function() { console.log('Mixin2.componentDidMount()'); } }; var MyComponent = React.createClass({ mixins: [Mixin1, Mixin2], render: function() { return <div>hello world</div>; } }); ``` When `MyComponent` is mounted into the page, the following text will print to the console: ``` Mixin1.componentDidMount() Mixin2.componentDidMount() ``` ## When should you use mixins? In general, add a mixin whenever you want a component to share some utility methods, public interface, or lifecycle behavior. Often it's appropriate to use them as you would use a superclass in another OOP language. </ins>


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

); } }); <ins> App = React.createFactory(App); </ins> /** jQuery Mobile button component. */ var JQueryMobileButton = React.createClass({

); } }); <ins> JQueryMobileButton = React.createFactory(JQueryMobileButton); </ins> /** jQuery Mobile page content component. */ var JQueryMobileContent = React.createClass({

); } }); <ins> JQueryMobileContent = React.createFactory(JQueryMobileContent); </ins> /** jQuery Mobile footer component. */ var JQueryMobileFooter = React.createClass({

); } }); <ins> JQueryMobileFooter = React.createFactory(JQueryMobileFooter); </ins> /** jQuery Mobile header component. */ var JQueryMobileHeader = React.createClass({

); } }); <ins> JQueryMobileHeader = React.createFactory(JQueryMobileHeader); </ins> /** jQuery Mobile page component. */ var JQueryMobilePage = React.createClass({

); } }); <ins> JQueryMobilePage = React.createFactory(JQueryMobilePage); </ins> /** Application page one component. */ var PageOneContent = React.createClass({

); } }); <ins> PageOneContent = React.createFactory(PageOneContent); </ins> /** Application page two component. */ var PageTwoContent = React.createClass({

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

); } }); <ins> PagePopUpContent = React.createFactory(PagePopUpContent); </ins> // Render application. React.render(App(null), document.getElementById('content'));


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

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


Question:
This has no dependencies so I think we should either publish it as a standalone module or direct people to something else from the community. I'm inclined to do the latter since it means we can wash our hands of it. Our internal usage of is tied to our transforms so we've said no to features that would be useful to others outside FB. I'm concerned we'd do that again. Any suggestions for existing projects that we can point to?
Can't we just link to a bunch of "useful scripts" in the docs and leave it at that? People are free to use/modify them, it's implied they're not being maintained and are there just for getting people started. I feel like a lot of people don't understand the current state of , but expect them to be full-blown frameworks and updated with every feature conceivable. Publishing on NPM kind of continues that trend and I suspect no-one on Team React really cares about the addons enough. So I would say, make them available in the docs (as code/files) and let the community sort out publishing/improving/direction.
...Can I "steal" the code and post it somewhere else under my name? I do need it for another CSS repo of mine, and it's really not React-specific.
After talking with Jed at the conference, I think I'll just point people at
Pete hunt already has react-classset module on npm I believe as well
According to the react-classset has been deprecated in favor of the above mentioned library.
It is. They're pretty much the same except for some negligible differences so I deprecated the former (the latter has an active maintainer).

var ReactServerRendering; var ReactTestUtils; <del> var cx; </del> var reactComponentExpect; var mocks; describe('ReactCompositeComponent', function() { beforeEach(function() { <del> cx = require('cx'); </del> mocks = require('mocks'); reactComponentExpect = require('reactComponentExpect');

return this.refs.anch; }, render: function() {  var className = cx({'anchorClass': this.props.anchorClassOn});   var className = this.props.anchorClassOn ? 'anchorClass' : '';  return this.props.renderAnchor ?  : ;

* @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ <ins> 'use strict'; var warning = require('warning'); var warned = false; </ins> function cx(classNames) { <ins> if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } </ins> if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className];


Question:
Hey guys, I know there are a lot of issues here so I'll try to make this quick and clear. The issue is that when you generate a sourcemap using the node module by calling , it will always output in the property of the sourcemap that is generated, there is no way to specify the actual source file. I thought that perhaps the option would allow you to change this, but unfortunately it does not -- no matter what you set to, the property always returns as an array with in it only. A small snippet of code to quickly verify this:
Thanks guys for the quick fix! :beers:

if (options && options.sourceMap) { result.sourceMap = output.sourceMap.toJSON(); } <ins> if (options && options.sourceFilename) { result.sourceMap.sources = [options.sourceFilename]; } </ins> return result; } };

} var visitorList = visitors.getVisitorsBySet(visitorSets); <ins> if (options.sourceFilename) { options.filename = options.sourceFilename; } </ins> return transform(visitorList, input, options); }


Question: is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !

renderCode={true} transformer={transformer.bind(null, this.state.harmony)} showCompiledJSTab={false} <ins> showLineNumbers={true} </ins> /> <label className="compiler-option"> <input

); var CodeMirrorEditor = React.createClass({ <ins> propTypes: { lineNumbers: React.PropTypes.bool, onChange: React.PropTypes.func }, getDefaultProps: function() { return { lineNumbers: false }; }, </ins> componentDidMount: function() { if (IS_MOBILE) return; this.editor = CodeMirror.fromTextArea(this.refs.editor.getDOMNode(), { mode: 'javascript', <del> lineNumbers: false, </del> <ins> lineNumbers: this.props.lineNumbers, </ins> lineWrapping: true, smartIndent: false,  // javascript mode does bad things with jsx indents matchBrackets: true,

transformer: React.PropTypes.func, renderCode: React.PropTypes.bool, showCompiledJSTab: React.PropTypes.bool, <ins> showLineNumbers: React.PropTypes.bool, </ins> editorTabTitle: React.PropTypes.string },

return JSXTransformer.transform(code).code; }, editorTabTitle: 'Live JSX Editor', <del> showCompiledJSTab: true </del> <ins> showCompiledJSTab: true, showLineNumbers: false </ins> }; },

onChange={this.handleCodeChange} codeText={compiledCode} readOnly={true} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXContent =

onChange={this.handleCodeChange} className="playgroundStage" codeText={this.state.code} <ins> lineNumbers={this.props.showLineNumbers} </ins> />; var JSXTabClassName =

@include code-typography; } <del> div.CodeMirror-linenumber:after { content: '.'; </del> <ins> div.CodeMirror-linenumber { text-align: right; </ins> } .CodeMirror, div.CodeMirror-gutters, div.highlight {


Question:
TestUtils.isDOMComponent(...) uses deprecated Element.getDOMNode(), resulting in console warnings when running tests. In my case, running 175 unit tests results in 700+ such warnings, drowning the output of the tests.
How are what tests are you running?
The tests are standard unit tests for custom React components. For example, I have a Toggle component that dispatches an event with type '' when clicked.
I'm also seeing the same issue testing under karma and mocha.
it looks like you this TODO? Can we get this fixed? Happy to help, but not sure what the right heuristic is.
This is unfortunate. I don't quite know what the right heuristic should be for 0.13, but we're changing it for 0.14 anyway since refs on DOM component will just be regular DOM nodes so I think we'll just power through. :/
Maybe we can do ?
I was thinking that we can reuse string types for ART and React Native too. We wouldn't want a React Native node to hit this.
maybe then?
It is not an own property. (And will be deprecated anyway so not a great heuristic.)
Lets just move fast on the ref === real DOM node stuff instead of spending time figuring this out.

isDOMComponent: function(inst) { // TODO: Fix this heuristic. It's just here because composites can currently // pretend to be DOM components. <del> return !!(inst && inst.getDOMNode && inst.tagName); </del> <ins> return !!(inst && inst.tagName && inst.getDOMNode); </ins> }, isDOMComponentElement: function(inst) {

// Should be document order, not mount order (which would be purple, orange) expect(log).toEqual(['orangepurple', 'orange', 'purple']); }); <ins> it('does not warn for getDOMNode on ES6 classes', function() { var Foo = React.createClass({ render: function() { return <div />; } }); class Bar extends React.Component { render() { return <div />; } } spyOn(console, 'warn'); var foo = ReactTestUtils.renderIntoDocument(<Foo />); expect(ReactTestUtils.isDOMComponent(foo)).toBe(false); var bar = ReactTestUtils.renderIntoDocument(<Bar />); expect(ReactTestUtils.isDOMComponent(bar)).toBe(false); var div = ReactTestUtils.renderIntoDocument(<div />); expect(ReactTestUtils.isDOMComponent(div)).toBe(true); expect(console.warn.calls.length).toBe(0); }); </ins> });


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

var isInputEventSupported = false; if (ExecutionEnvironment.canUseDOM) { // IE9 claims to support the input event but fails to trigger it when <del> // deleting text, so we ignore its input events </del> <ins> // deleting text, so we ignore its input events. // IE10+ fire input events to often, such when a placeholder // changes or when an input with a placeholder is focused. </ins> isInputEventSupported = isEventSupported('input') && ( <del> !('documentMode' in document) || document.documentMode > 9 </del> <ins> !('documentMode' in document) || document.documentMode > 11 </ins> ); } /** <del> * (For old IE.) Replacement getter/setter for the `value` property that gets </del> <ins> * (For IE <=11) Replacement getter/setter for the `value` property that gets </ins> * set on the active element. */ var newValueProp = {

}; /** <del> * (For old IE.) Starts tracking propertychange events on the passed-in element </del> <ins> * (For IE <=11) Starts tracking propertychange events on the passed-in element </ins> * and override the value property so that we can distinguish user events from * value changes in JS. */

); Object.defineProperty(activeElement, 'value', newValueProp); <del> activeElement.attachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.attachEvent) { activeElement.attachEvent('onpropertychange', handlePropertyChange); } else { activeElement.addEventListener('propertychange', handlePropertyChange, false); } </ins> } /** <del> * (For old IE.) Removes the event listeners from the currently-tracked element, </del> <ins> * (For IE <=11) Removes the event listeners from the currently-tracked element, </ins> * if any exists. */ function stopWatchingForValueChange() {

// delete restores the original property definition delete activeElement.value; <del> activeElement.detachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.detachEvent) { activeElement.detachEvent('onpropertychange', handlePropertyChange); } else { activeElement.removeEventListener('propertychange', handlePropertyChange, false); } </ins> activeElement = null; activeElementID = null;

} /** <del> * (For old IE.) Handles a propertychange event, sending a `change` event if </del> <ins> * (For IE <=11) Handles a propertychange event, sending a `change` event if </ins> * the value of the active element has changed. */ function handlePropertyChange(nativeEvent) {

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

// In IE8, we can capture almost all .value changes by adding a // propertychange handler and looking for events with propertyName // equal to 'value' <del> // In IE9, propertychange fires for most input events but is buggy and </del> <ins> // In IE9-11, propertychange fires for most input events but is buggy and </ins> // doesn't fire when text is deleted, but conveniently, selectionchange // appears to fire in all of the remaining cases so we catch those and // forward the event if the value has changed


Question:
I'm still learning React, so it's possible I'm misunderstanding something. I'm trying to use React with , and hit a stumbling block, by upgrading to React 0.13. There is on the repository, that explains how to use immutable as a react state, and it provides the following example (I transpiled it to ES3): This works great in 0.12, but in 0.13, you will receive the following error when clicking on the div: Putting a breakpoint on the error, and inspecting with a debugger reveals that all the methods on have disappeared. Is this the expected behavior in 0.13?
should be a plain object, you're not allowed to put classes in there.
So the wiki page I linked to is incorrect? It would make working with (and probably other immutable implementions) a pita, since you would have to pack/unpack the object every time you store/retrieve it.
Seems so... cc
I encountered the same thing in 0.12, storing an immutable-js object on the state directly clobbers it,but simply putting it under an attribute works fine. E.g. .
I am experiencing this after upgrading to 0.13 as well. It didn't seem to be a problem in react 0.12. It seems to almost make sense that state could be an immutable object since equality comparison is cheap. I could nest my state object under state ( yuck) but it seems like it would create a lot of boilerplate code that I didn't need in 0.12
I think you can +1 in
Yeah this bit me bad... I used an as all my state and not a plain object, which worked absolutely great in 0.12 and broke in 0.13. This forces me to add a bunch of useless vanilla objects with a single child prop to hold my immutable map.
Since I was working with a simple map structure, toObject saved me... e.g. Not sure how well this work with more complex object structures however.
Has there been any movement on this? My project has been on hold since I don't know if I should: a.) stay on React 0.12 where I could use Immutable maps for state. b.) Move all my immutable maps to child of a single-item map. or c.) leave things as they are and this will be supported in the future.
AFAIK this is not going to change. Personally I still don't understand why people want to put third-party objects as state, I don't see what benefit there is. What's wrong with just using ?
For me there were two main advantages. ) My stores already deal in immutable hashes, With react 0.12 I didn't have to bother converting them ) Deep comparison for updates is simple with immutable objects. With react 0.12 when you setState with an immutable object, if any of it's contents had changed, it would re-render. If it was the same, it would not. Comparing immutable objects is cheap. Deep comparing hashes is not. There is more upfront cost with the immutable objects, but they are way easier to reason about wether or not they have changed. If there is definitely no plan to support this then I suppose the best plan of action is to to_js everything and manually deep compare?
There is movement on which would get rid of replaceState and add better immutable-js support (and perhaps other libraries) in the core. However, it was not our intention to break the old behavior of replaceState in 0.13 so this seems like a bug to me. Do we maybe want to patch release this if there is an easy fix?
1) I can't speak for this, but using a store's data for the singular state object seems rather limiting, you're now unable to include any other stores or introduce any other locally relevant state for the component right? 2) Is straight-forward with objects as well, immutability is not a concept that is unique to immutable-js. Depending on the underlying behaviors you can use just or a simple reusable shallow equality test with plain objects too. But does actually intend to allow replacing the "state object" vs just simply understanding how to iterate over generic maps/sets?
) Yes, I do have some components that use data from multiple stores, and those end up as different elements under a hash. When I have a component that only uses the data from one store, it is sort of silly to have it nested as a single element in a hash. ) "you can use just === or a simple reusable shallow equality test with plain objects too" is my point exactly, usually my objects are just one level deep and this is fine. I sometimes they are not though and with Immutable-js objects I can use === with deeply nested objects. If I use immutable-js for everything, I don't have to worry about it.
not sure that it will be the cleanest thing. This is a result of your changes . Right now we just have a but we don't know what each thing in the queue is (did it come from a or ). We could wrap each item in the queue so we know what it came from, so instead of we have . That would allow us to stack and calls (which I don't think we actually handle correctly now). But the simplest case where you're only using , we can probably just change this line:
We could take something in 0.13.4 (not 0.13.3, shipping that today). But it needs to bake first. Both changes I mentioned would change behavior so there's some risk. The first is more complete, the latter trades 1 bug for a slightly less bad bug (setState(), replaceState() in the same update queue will result in the object passed to setState being used as the replacement since we only have a single pendingReplace flag)
Actually, this came from . There is a simple fix: Because the queue is emptied for every replaceState, since nothing earlier in the queue could've affected the result:
Ah, truth. is fixing and it's small and let's just take it in 0.13.3 so we don't have to do another patch release so soon after.
So, the issue was fixed in , but what about components using ? I'm seeing this when I use
setState merges. Using a non-plain object with it isn't supported. You can put whatever object you want on an inner state key (, , etc.).

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

expect(console.error.argsForCall.length).toBe(0); }); <ins> it('should replace state', function() { var Moo = React.createClass({ getInitialState: function() { return {x: 1}; }, render: function() { return <div />; } }); var moo = ReactTestUtils.renderIntoDocument(<Moo />); moo.replaceState({y: 2}); expect('x' in moo.state).toBe(false); expect(moo.state.y).toBe(2); }); it('should support objects with prototypes as state', function() { var NotActuallyImmutable = function(str) { this.str = str; }; NotActuallyImmutable.prototype.amIImmutable = function() { return true; }; var Moo = React.createClass({ getInitialState: function() { return new NotActuallyImmutable('first'); }, render: function() { return <div />; } }); var moo = ReactTestUtils.renderIntoDocument(<Moo />); expect(moo.state.str).toBe('first'); expect(moo.state.amIImmutable()).toBe(true); var secondState = new NotActuallyImmutable('second'); moo.replaceState(secondState); expect(moo.state.str).toBe('second'); expect(moo.state.amIImmutable()).toBe(true); expect(moo.state).toBe(secondState); moo.setState({str: 'third'}); expect(moo.state.str).toBe('third'); // Here we lose the prototype. expect(moo.state.amIImmutable).toBe(undefined); // When more than one state update is enqueued, we have the same behavior var fifthState = new NotActuallyImmutable('fifth'); ReactUpdates.batchedUpdates(function() { moo.setState({str: 'fourth'}); moo.replaceState(fifthState); }); expect(moo.state).toBe(fifthState); // When more than one state update is enqueued, we have the same behavior var sixthState = new NotActuallyImmutable('sixth'); ReactUpdates.batchedUpdates(function() { moo.replaceState(sixthState); moo.setState({str: 'seventh'}); }); expect(moo.state.str).toBe('seventh'); expect(moo.state.amIImmutable).toBe(undefined); }); </ins> });


Question:
I’ve tried to update from react 0.12.2 to 0.13.0 which caused several unit tests of my project to fail. I use react to render html on the server side, this includes the basic html structure like , and elements. All unit tests dealing with such elements are failing with react 0.13.0 but they worked fine with 0.12.2. Here is a minimal example : Running this with react 0.12.2, correctly logs the text content of the title:Running this with react 0.13.0 throws a TypeError
I think this is just a bug, not an intentional breaking change. Thanks for reporting.

var elementFactory = ReactElement.createFactory(tag); var FullPageComponent = ReactClass.createClass({ <ins> tagName: tag.toUpperCase(), </ins> displayName: 'ReactFullPageComponent' + tag, componentWillUnmount: function() {

expect(console.warn.calls.length).toBe(0); }); <ins> it('should support injected wrapper components as DOM components', function() { var injectedDOMComponents = [ 'button', 'form', 'iframe', 'img', 'input', 'option', 'select', 'textarea', 'html', 'head', 'body' ]; injectedDOMComponents.forEach(function(type) { var component = ReactTestUtils.renderIntoDocument( React.createElement(type) ); expect(component.tagName).toBe(type.toUpperCase()); expect(ReactTestUtils.isDOMComponent(component)).toBe(true); }); }); </ins> });


Question:
In following JSX fragment I should guarantee that will never be or : Otherwise throws an error although construction is correct: Should instead of check for ?
Someone else mentioned this being surprising to me too.
I've been experiencing the same issues recently
As far as I understand it, the idea is that is basically the equivalent of a HTML-type. You're not meant to use it as , but as so that you cannot accidentally pass unsafe data. So should be or , in this model it does not make sense to have .
That doesn't mean that people won't write it as – doing so is even pretty reasonable if you're careful about naming your vars/props and do .
The simplest workaround is to coerce into an empty string with . +1 for having React do this internally.
Got surprised by this today, upgrading from to . Was it a "bug" in (i.e. it shouldn't have accepted ), or is it a bug in ? Anyway, will use as suggested by just wanted to point out that it seemed to "work" in .

'Can only set one of `children` or `props.dangerouslySetInnerHTML`.' ); invariant( <del> props.dangerouslySetInnerHTML.__html != null, </del> <ins> typeof props.dangerouslySetInnerHTML === 'object' && '__html' in props.dangerouslySetInnerHTML, </ins> '`props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`. ' + 'Please visit https://fb.me/react-invariant-dangerously-set-inner-html ' + 'for more information.'

); }); <ins> it('should allow {__html: null}', function() { expect(function() { mountComponent({dangerouslySetInnerHTML: {__html: null} }); }).not.toThrow(); }); </ins> it("should warn about contentEditable and children", function() { spyOn(console, 'error'); mountComponent({contentEditable: true, children: ''});


Question:
'For communication between two components that don't have a parent-child relationship, you can set up your own global event system.' So far I've really enjoyed React. It's conducive to modularize your components. However, as you modularize your components, it gets harder to communicate. A global event system doesn't scale and essentially couples components that shouldn't be coupled. A simple example, a faceted navigation sidebar containing two subviews. Some filters and a search bar, and a list of things: SibebarView | -- Filters -- Search Input -- Filter Button | -- List View In essence, an event stream from your search input should update the list. By the advice above, it seems like you'd say create a singleton EventEmitter which the search input : As you can see, this is a very specific event which the SidebarView has to know about. Also let's say you have a global search input. Over time it seems like you have to be increasingly specific about event names. I have a feeling Flux is supposed alleviate this problem somehow, but if so is there any way we can give some more detail here and/or point people in the right direction? Seems like a common use case.
Flux is indeed one way of solving this problem. I created a PR to mention it.
thanks! for others' reference:
one step further might be nice to throw in a quick if-you-understand-a-little-about-flux example.

Notice the use of `bind(this, arg1, arg2, ...)`: we're simply passing more arguments to `handleClick`. This is not a new React concept; it's just JavaScript. <del> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. </del> <ins> For communication between two components that don't have a parent-child relationship, you can set up your own global event system. Subscribe to events in `componentDidMount()`, unsubscribe in `componentWillUnmount()`, and call `setState()` when you receive an event. [Flux](https://facebook.github.io/flux/) pattern is one of the possible ways to arrange this. </ins>


Question:
The following code: produces deep into React.
Yea, we can do better than that. On the plus side, looks like this error will actually log as in the near future (does for me in my browsers: Firefox Nightly, Chrome beta). We should be able to catch this in . Strings are ok. Functions are ok (I think, or will be). Objects with certain characteristics are ok (has a render function?)
No objects, just functions that return objects with a render function. I thought we had a warning for this already though.
We just look for .
Sorry for all the references above. Let me know how looks.
I'm still getting this error (I just installed the latest react version). Any ideas why it happens? Everything else bundles rather alright with browserify but the main client script doesn't run and flags with this error.
It's a long shot, but I just had the same error, and it turned out to be a component that I was including with further up the component hierarchy than it was actually being used. Once I removed the extra it ran just fine again. If it helps to narrow down the component, the hierarchy was Ancestor ChildList Child ChildList Child... (recursive). The Ancestor component was unnecessarily including the Child component. But again this is pure speculation since the error message was in no way indicative of the solution I found, so the problem in your case may be completely different :) Cheers
Yep, you are right, it was totally my own error. The error reporting should be better though. It seems like frontend scripts are better at this than bundling everything using browserify.
Thanks you saved me a lot of time ;) I had simply forgotten to add the on a react component. I agree that this error is pretty confusing, even with the message (which is what I got).
I just had the same issue that cosmith had. The TypeError really isn't very helpful. The real error is only tangentially related to types...
Did you see a warning in the console logged before the exception was thrown? There should be one.
good question. It was probably there, but I don't recall now. Why would that be a warning and not an exception itself?
For this case specifically, it's because we want to be able to inline calls to React.createElement () without changing runtime behavior which we can do only if createElement never throws.
Can it be made to only throw when not in ? Granted, even I don't like that idea very much... I'm not sure there's a better solution than just emitting a warning before everything explodes. At the end of the day the dev is just going to Google the error because it's completely opaque. Then they'll find this thread or something similar and move on with their lives.
Not sure if this will help someone in the future, but another way to get this same error ( ) is by referencing a component that hasn't been to module exports. So this will throw the error mentioned: This will fix it:
Hopefully we can make the toUpperCase error a little less cryptic. Just posted .
very nice :+1:
I was trying to do and was getting this error. Later found that, Element has inline css entry at its root <div. After Removing the entry it has been fixed.
I'm struggling with this error too. Any pointers? Here is my main app: And here is my I'm using the latest version of rect, reactify and browserify to compile
In your file check the exports line , there is a typo I guess, It should be
Thank you! You saved me much frustration :)
Thank you, that was the source of my bug too.
I had the same error trying to include a component inside the same component Error :
In 0.14, you'll get something like this message:
hey kinda late on this, but would it be possible to get the name of the invalid component? Let's say I try to use but is wrong. Would it be possible to say that it's that is failing the test? Would help finding and fixing the errors
This isn't possible without changing the transform, no. You can look at the stack trace to see where the error was.
the error is so confused, and difficult to trace the error
:+1:
Thank you do much! What a terrible error message!

* @param {ReactElement} element */ function validatePropTypes(element) { <del> if (element.type == null) { </del> <ins> if (!(typeof element.type === 'string' || typeof element.type === 'function')) { </ins> // This has already warned. Don't throw. return; }

createElement: function(type, props, children) { // We warn in this case but don't throw. We expect the element creation to // succeed and there will likely be errors in render. <del> warning( type != null, 'React.createElement: type should not be null or undefined. It should ' + 'be a string (for DOM elements) or a ReactClass (for composite ' + 'components).%s', </del> <ins> warning(typeof type === 'string' || typeof type === 'function', 'React.createElement: type should not be null, undefined, boolean, or ' + 'number. It should be a string (for DOM elements) or a ReactClass ' + '(for composite components).%s', </ins> getDeclarationErrorAddendum() );

); }); <del> it('gives a helpful error when passing null or undefined', function() { </del> <ins> it('gives a helpful error when passing null, undefined, boolean, or number', () => { </ins> spyOn(console, 'error'); React.createElement(undefined); React.createElement(null); <del> expect(console.error.calls.length).toBe(2); </del> <ins> React.createElement(true); React.createElement(123); expect(console.error.calls.length).toBe(4); </ins> expect(console.error.calls[0].args[0]).toBe( <del> 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' </del> <ins> 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' </ins> ); expect(console.error.calls[1].args[0]).toBe( <del> 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components).' </del> <ins> 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' ); expect(console.error.calls[2].args[0]).toBe( 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' ); expect(console.error.calls[3].args[0]).toBe( 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components).' </ins> ); React.createElement('div'); <del> expect(console.error.calls.length).toBe(2); </del> <ins> expect(console.error.calls.length).toBe(4); </ins> }); <del> it('includes the owner name when passing null or undefined', function() { </del> <ins> it('includes the owner name when passing null, undefined, boolean, or number', () => { </ins> spyOn(console, 'error'); var ParentComp = React.createClass({ render: function() {

}).toThrow(); expect(console.error.calls.length).toBe(2); expect(console.error.calls[0].args[0]).toBe( <del> 'Warning: React.createElement: type should not be null or undefined. ' + 'It should be a string (for DOM elements) or a ReactClass (for ' + 'composite components). Check the render method of `ParentComp`.' </del> <ins> 'Warning: React.createElement: type should not be null, undefined, ' + 'boolean, or number. It should be a string (for DOM elements) or a ' + 'ReactClass (for composite components). Check the render method of ' + '`ParentComp`.' </ins> ); expect(console.error.calls[1].args[0]).toBe( 'Warning: Only functions or strings can be mounted as React components.'

); }); <del> it('gives a helpful error when passing null or undefined', function() { </del> <ins> it('gives a helpful error when passing null, undefined, or boolean', () => { </ins> var Undefined = undefined; var Null = null; <ins> var True = true; var Num = 123; </ins> var Div = 'div'; spyOn(console, 'error'); <Undefined />; <Null />; <del> expect(console.error.calls.length).toBe(2); </del> <ins> <True />; <Num />; expect(console.error.calls.length).toBe(4); </ins> expect(console.error.calls[0].args[0]).toContain( <del> 'type should not be null or undefined. It should be a string (for ' + 'DOM elements) or a ReactClass (for composite components).' </del> <ins> 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' </ins> ); expect(console.error.calls[1].args[0]).toContain( <del> 'type should not be null or undefined. It should be a string (for ' + 'DOM elements) or a ReactClass (for composite components).' </del> <ins> 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' ); expect(console.error.calls[2].args[0]).toContain( 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' ); expect(console.error.calls[3].args[0]).toContain( 'type should not be null, undefined, boolean, or number. It should be ' + 'a string (for DOM elements) or a ReactClass (for composite components).' </ins> ); <Div />; <del> expect(console.error.calls.length).toBe(2); </del> <ins> expect(console.error.calls.length).toBe(4); </ins> }); it('should check default prop values', function() {


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

var isInputEventSupported = false; if (ExecutionEnvironment.canUseDOM) { // IE9 claims to support the input event but fails to trigger it when <del> // deleting text, so we ignore its input events </del> <ins> // deleting text, so we ignore its input events. // IE10+ fire input events to often, such when a placeholder // changes or when an input with a placeholder is focused. </ins> isInputEventSupported = isEventSupported('input') && ( <del> !('documentMode' in document) || document.documentMode > 9 </del> <ins> !('documentMode' in document) || document.documentMode > 11 </ins> ); } /** <del> * (For old IE.) Replacement getter/setter for the `value` property that gets </del> <ins> * (For IE <=11) Replacement getter/setter for the `value` property that gets </ins> * set on the active element. */ var newValueProp = {

}; /** <del> * (For old IE.) Starts tracking propertychange events on the passed-in element </del> <ins> * (For IE <=11) Starts tracking propertychange events on the passed-in element </ins> * and override the value property so that we can distinguish user events from * value changes in JS. */

); Object.defineProperty(activeElement, 'value', newValueProp); <del> activeElement.attachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.attachEvent) { activeElement.attachEvent('onpropertychange', handlePropertyChange); } else { activeElement.addEventListener('propertychange', handlePropertyChange, false); } </ins> } /** <del> * (For old IE.) Removes the event listeners from the currently-tracked element, </del> <ins> * (For IE <=11) Removes the event listeners from the currently-tracked element, </ins> * if any exists. */ function stopWatchingForValueChange() {

// delete restores the original property definition delete activeElement.value; <del> activeElement.detachEvent('onpropertychange', handlePropertyChange); </del> <ins> if (activeElement.detachEvent) { activeElement.detachEvent('onpropertychange', handlePropertyChange); } else { activeElement.removeEventListener('propertychange', handlePropertyChange, false); } </ins> activeElement = null; activeElementID = null;

} /** <del> * (For old IE.) Handles a propertychange event, sending a `change` event if </del> <ins> * (For IE <=11) Handles a propertychange event, sending a `change` event if </ins> * the value of the active element has changed. */ function handlePropertyChange(nativeEvent) {

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

// In IE8, we can capture almost all .value changes by adding a // propertychange handler and looking for events with propertyName // equal to 'value' <del> // In IE9, propertychange fires for most input events but is buggy and </del> <ins> // In IE9-11, propertychange fires for most input events but is buggy and </ins> // doesn't fire when text is deleted, but conveniently, selectionchange // appears to fire in all of the remaining cases so we catch those and // forward the event if the value has changed


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

title: Animation - id: two-way-binding-helpers title: Two-Way Binding Helpers <del> - id: class-name-manipulation title: Class Name Manipulation </del> - id: test-utils title: Test Utilities - id: clone-with-props

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

title: Two-Way Binding Helpers permalink: two-way-binding-helpers.html prev: animation.html <del> next: class-name-manipulation.html </del> <ins> next: test-utils.html </ins> --- `ReactLink` is an easy way to express two-way binding with React.

id: test-utils title: Test Utilities permalink: test-utils.html <del> prev: class-name-manipulation.html </del> <ins> prev: two-way-binding-helpers.html </ins> next: clone-with-props.html ---

var ReactTransitionGroup = require('ReactTransitionGroup'); var ReactUpdates = require('ReactUpdates'); <del> var cx = require('cx'); </del> var cloneWithProps = require('cloneWithProps'); var shallowCompare = require('shallowCompare'); var update = require('update');

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

<del> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule cx */ /** * This function is used to mark string literals representing CSS class names * so that they can be transformed statically. This allows for modularization * and minification of CSS class names. * * In static_upstream, this function is actually implemented, but it should * eventually be replaced with something more descriptive, and the transform * that is used in the main stack should be ported for use elsewhere. * * @param string|object className to modularize, or an object of key/values. *                      In the object case, the values are conditions that *                      determine if the className keys should be included. * @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ 'use strict'; var warning = require('warning'); var warned = false; function cx(classNames) { if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className]; }).join(' '); } else { return Array.prototype.join.call(arguments, ' '); } } module.exports = cx; </del>


Question:
I didn't realise this was in the addons bundle, would be good to get it to the docs. Would be good to also include an example of using or something similar.
rAF batching isn't supported and won't go in the docs, but batchedUpdates should.
is rAF batching discouraged, or just not suitable for shipping with core? Would it be reasonable to link to an up-to-date npm project on the batchedUpdates page?
We don't use it at Facebook and it's not clear that it solves real problems, so we don't want to maintain it or have to fix bugs related to it. should give enough control over batching.
There are also known issues with rAF batching (mostly around controlled components).
Should we deprecate and eventually remove the RAF batching?
It's never been supported in any fashion.
(i.e., it's already deprecated?)
shouldn't this file be deleted in that case?
That's not exposed as a public API in any of our builds, but sure, we can delete it – PR incoming.
Killed in
We should document ReactDOM.unstable_batchedUpdates.
Since when did we start documenting features? Haven't we always left them intentionally undocumented? We also have unstablerenderSubtree and unstable_handleError and others, but I thought the decision was to not document them until they become stable. We document them as part of the release process. It was a different situation when it was an addon, the issue made sense at that time.
Sure.

<del> /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @providesModule ReactRAFBatchingStrategy * @typechecks static-only */ /* global requestAnimationFrame:true */ 'use strict'; var ExecutionEnvironment = require('ExecutionEnvironment'); var ReactUpdates = require('ReactUpdates'); var requestAnimationFrame = require('requestAnimationFrame'); function tick() { ReactUpdates.flushBatchedUpdates(); requestAnimationFrame(tick); } var ReactRAFBatchingStrategy = { isBatchingUpdates: true, /** * Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ batchedUpdates: function(callback, a, b, c, d) { callback(a, b, c, d); } }; if (ExecutionEnvironment.canUseDOM) { requestAnimationFrame(tick); } module.exports = ReactRAFBatchingStrategy; </del>


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

this.getName() || 'a component' ); warning( <ins> !inst.getDefaultProps || inst.getDefaultProps.isReactClassApproved, 'getDefaultProps was defined on %s, a plain JavaScript class. ' + 'This is only supported for classes created using React.createClass. ' + 'Use a static property to define defaultProps instead.', this.getName() || 'a component' ); warning( </ins> !inst.propTypes, 'propTypes was defined as an instance property on %s. Use a static ' + 'property to define propTypes instead.',

but does not invoke them.', -> spyOn console, 'error' getInitialStateWasCalled = false <ins> getDefaultPropsWasCalled = false </ins> class Foo extends React.Component constructor: -> @contextTypes = {}

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

it('warns when classic properties are defined on the instance, ' + 'but does not invoke them.', function() { spyOn(console, 'error'); <ins> var getDefaultPropsWasCalled = false; </ins> var getInitialStateWasCalled = false; class Foo extends React.Component { constructor() {

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

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

var warn = jest.genMockFn(); console.error = warn; getInitialStateWasCalled = false; <ins> getDefaultPropsWasCalled = false; </ins> test(React.createElement(ClassicProperties), 'SPAN', 'foo'); expect(getInitialStateWasCalled).toBe(false); <del> expect(warn.mock.calls.length).toBe(3); </del> <ins> expect(getDefaultPropsWasCalled).toBe(false); expect(warn.mock.calls.length).toBe(4); </ins> expect(warn.mock.calls[0][0]).toContain( 'getInitialState was defined on ClassicProperties, ' + 'a plain JavaScript class.' ); expect(warn.mock.calls[1][0]).toContain( <del> 'propTypes was defined as an instance property on ClassicProperties.' </del> <ins> 'getDefaultProps was defined on ClassicProperties, ' + 'a plain JavaScript class.' </ins> ); expect(warn.mock.calls[2][0]).toContain( <ins> 'propTypes was defined as an instance property on ClassicProperties.' ); expect(warn.mock.calls[3][0]).toContain( </ins> 'contextTypes was defined as an instance property on ClassicProperties.' ); });


Question:
There seems to have been an API change between React 0.12 and 0.13 that's not covered in the documentation. When using with the option, the source map is now returned as a plain JavaScript object. Previously it would return an instance of and you'd need to call to get the actual source map. Is this an intentional change that just got overlooked when writing the documentation?
That's just an oversight. We aligned JSXTransformer to use the same code as react-tools (as opposed to duplicating efforts with slight variation). This originally changed in react-tools last year - , and then I made JSXTransformer just use react-tools in . I didn't notice that we're doing a bit more post-processing in react-tools. We can add a bit to the changelog for this.

* `es3` restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg `this.static` will become `this['static']` for IE8 compatibility). * The transform for the call spread operator has also been enabled. <ins> ### JSXTransformer #### Breaking Changes * The return value of `transform` now contains `sourceMap` as a JS object already, not an instance of `SourceMapGenerator`. </ins> ### JSX #### Breaking Changes


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

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

); ReactShallowRenderer.prototype.render = function(element, context) { <ins> if (!context) { context = emptyObject; } </ins> var transaction = ReactUpdates.ReactReconcileTransaction.getPooled(); this._render(element, transaction, context); ReactUpdates.ReactReconcileTransaction.release(transaction);

}); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> shallowRenderer.unmount(); expect(componentWillUnmount).toBeCalled();

}); var shallowRenderer = ReactTestUtils.createRenderer(); <del> shallowRenderer.render(<SomeComponent />, {}); </del> <ins> shallowRenderer.render(<SomeComponent />); </ins> var result = shallowRenderer.getRenderOutput(); expect(result.type).toBe('div'); expect(result.props.children).toEqual([

<span className="child2" /> ]); <del> shallowRenderer.render(<SomeComponent aNew="prop" />, {}); </del> <ins> shallowRenderer.render(<SomeComponent aNew="prop" />); </ins> var updatedResult = shallowRenderer.getRenderOutput(); expect(updatedResult.type).toBe('a');

expect(updatedResultCausedByClick.props.className).toBe('was-clicked'); });  it('can shallowly render components with contextTypes', function() { var SimpleComponent = React.createClass({ contextTypes: { name: React.PropTypes.string, }, render: function() { return
; }, }); var shallowRenderer = ReactTestUtils.createRenderer(); shallowRenderer.render(<SimpleComponent />); var result = shallowRenderer.getRenderOutput(); expect(result).toEqual(
); });  it('Test scryRenderedDOMComponentsWithClass with TextComponent', function() { var renderedComponent = ReactTestUtils.renderIntoDocument(
Hello Jim
); var scryResults = ReactTestUtils.scryRenderedDOMComponentsWithClass(