Question:
This may be controversial, but after browsing StackOverflow I believe there's way too many people that load jQuery when they really don't need it. Let's not add to that. I don't think we should be loading jQuery in the tutorial just to do an AJAX request. Let's instead have a dummy object that just returns a static list. Which could simply be replaced to implement AJAX loading. Old post (before I thought of just using static data): Let's replace it with standard XMLHttpRequest code and say something like "Here's some simple code for doing an AJAX request, alternatively you could use your favourite framework like jQuery, MooTools, YUI, ... instead". Having jQuery loaded in the tutorial may make people think that jQuery is necessary to use React.
I was thinking about this more and using a static list would probably be better than AJAX (given the tutorial just AJAX loads a static file). Updated the description to reflect this.
I think that would be fine. I would still put the equivalent jQuery call because that will be the inevitable question.
After reading pretty much everything related to this issue, I think it would be a good idea to add (for now) a little note in the tutorial, just under the code snippet having the jQuery inclusion. I think it's the only place it really needs to be. What do you think ? (So we can finally close this issue)
Agreed. A beginner tutorial isn't the place to debate jquery vs no jquery. The point is familiarity.
For what it's worth, I removed the use of jQuery in the ReactJS.NET version of the tutorial:
^ The note about jQuery not being mandatory got merged. I think this is good for now for newcomers. The react users probably already realized they don't actually need jQuery. Closing for now! =)
It dose not look very good when you are introducing new people to React and the first ting in the tutorial is: "We need to do some Ajax calls, let's just add jQuery".

For the remainder of this tutorial, we'll be writing our JavaScript code in this script tag. <ins> > Note: > > We included jQuery here because we want to simplify the code of our future ajax calls, but it's **NOT** mandatory for React to work. </ins> ### Your first component React is all about modular, composable components. For our comment box example, we'll have the following component structure:


Question:
Here's an example: (no jsfiddle because that's broken in IE8)
I tried to fix this bug yesterday but had a bad time trying to find a fix for a similar cases. I looked at current well maintained libraries and didn't find a way to make scroll bubble or capture it on IE8. Seems like trying to fix it would be a waste of time and would make code much complex, for a browser that is slowly dying. My suggestion is to point that out on the documentation.
Seems like this isn't so easy. Let's do what says and document it.
do you think that we should do a everytime someone uses onScroll on any browser or would that be annoying? I would say it would be annoying but it would also be very frustrating to figure that it's a React limitation after some hours of debugging on IE8 (ugh!)
+1 on the warning -- would be super helpful.
reopening so we can add a warning
Warning was in
Now that events are listened on demand, maybe the warning should be moved to method, where support is already checked?
It also prints the warning if you render on the server, its annoying :/
That's odd, I wouldn't expect that code to run at all when using server rendering.
I see this warning when I'm doing with . Any chance to disable it?
I also see this error when using ssr
This is happening to me with JSDOM as well and in my case our team project standards aren't going to accommodate leaving these errors in the console when tests are run. How can I suppress or stub this out. It's not just obnoxious it is preventing me from getting my work merged in our project.
/ - I am now seeing this error after upgrading my version of Enzyme to . Did you find a way to suppress these warnings for JSDOM?
If you're having problems please file a new issue. Nobody actively reads old issues, and requests for help here will get lost.

* `Object.create` – Provided by `es5-sham.js` from [kriskowal's es5-shim](https://github.com/kriskowal/es5-shim). * `console.*` – Only needed when using the unminified build. If you need to polyfill this, try [paulmillr's console-polyfill](https://github.com/paulmillr/console-polyfill). <ins> ### Cross-browser Issues Although React is pretty good at abstracting browser differences, some browsers are limited or present quirky behaviors that we couldn't find a workaround. #### onScroll event on IE8 On IE8 the `onScroll` event doesn't bubbles and IE8 doesn't have an API to define handlers to the capturing phase of an event, meaning there is no way for React to listen to these events. Currently a handler to this event is ignored on IE8. See the [onScroll doesn't work in IE8](https://github.com/facebook/react/issues/631) GitHub issue for more information. </ins>


Question:
Please see: and do the following: 'Toggle' to make the list-item fade into view. -click/Spam-click the 'Toggle' button again to make the item fade-out of view. 'Toggle' again to try to make the component come back into view. You'll see that the item doesn't come back! If you check the HTML, you can see that the list-item is still there, with the class name "example-leave example-leave-active". I suspect that React should reverse the animation elegantly in the case of the same component being re- in the render function during a leave transition.
Thanks, I was going to point you to but I see that you're the author of it!
Hehe, I thought perhaps it'd be best if I made a proper Issue (with JSFiddle example!) rather than just rudely posting Pull Requests! :)

componentWillReceiveProps: function(nextProps) { if (!nextProps.children && this.props.children) { this.savedChildren = this.props.children; <ins> } else if (nextProps.children && !this.props.children) { // We're being told to re-add the child.  Let's stop leaving! if (this.isMounted()) { var node = this.getDOMNode(); var className = this.props.name; CSSCore.removeClass(node, className + '-leave'); CSSCore.removeClass(node, className + '-leave-active'); if (this.props.enter) { CSSCore.addClass(node, className + '-enter'); CSSCore.addClass(node, className + '-enter-active'); } } </ins> } },


Question:
When unmounting components like this: a memory leak happens because ReactMount.getID(node) puts DOM nodes back to nodeCache if they are not there.. just right after they were purged from cache. Here is what's happing when unmounting that example component: label component gets purged from nodeCache when ReactDOMInput component is going to unmount it calls this method: which contains this.getDOMNode() which iterates through the children of the Form element calling getID() on each of them.. which puts these elements back into the cache. So first they were purged and here they are all put back in cache causing a memory leak :( I'm playing with React just 3rd day so not sure of a way to correctly fix this issue
(I took the liberty to edit your comment to add syntax highlighting)
I can't reproduce this. With this diff applied, I loaded http://127.0.0.1:8000/examples/ballmer-peak/ in the console and checked -- it was empty. Am I misunderstanding?
Yes. You've missed one more user defined component in there.. Here you go:
Thanks, fixed in .
Thank you for fast fix :)
Thanks for the find/fix!

this._defaultProps = null; <del> ReactComponent.Mixin.unmountComponent.call(this); </del> this._renderedComponent.unmountComponent(); this._renderedComponent = null; <ins> ReactComponent.Mixin.unmountComponent.call(this); </ins> if (this.refs) { this.refs = null; }

* @internal */ unmountComponent: function() { <ins> this.unmountChildren(); </ins> ReactEventEmitter.deleteAllListeners(this._rootNodeID); ReactComponent.Mixin.unmountComponent.call(this); <del> this.unmountChildren(); </del> } };

var MorphingComponent; var ChildUpdates; var React; <ins> var ReactComponent; </ins> var ReactCurrentOwner; var ReactPropTypes; var ReactTestUtils;

reactComponentExpect = require('reactComponentExpect'); React = require('React'); <ins> ReactComponent = require('ReactComponent'); </ins> ReactCurrentOwner = require('ReactCurrentOwner'); ReactDoNotBindDeprecated = require('ReactDoNotBindDeprecated'); ReactPropTypes = require('ReactPropTypes');

}); }); <ins> it('should call componentWillUnmount before unmounting', function() { var container = document.createElement('div'); var innerUnmounted = false; spyOn(ReactMount, 'purgeID').andCallThrough(); var Component = React.createClass({ render: function() { return <div> <Inner /> </div>; } }); var Inner = React.createClass({ componentWillUnmount: function() { // It's important that ReactMount.purgeID be called after any component // lifecycle methods, because a componentWillMount implementation is // likely call this.getDOMNode(), which will repopulate the node cache // after it's been cleared, causing a memory leak. expect(ReactMount.purgeID.callCount).toBe(0); innerUnmounted = true; }, render: function() { return <div />; } }); React.renderComponent(<Component />, container); React.unmountComponentAtNode(container); expect(innerUnmounted).toBe(true); // <Component />, <Inner />, and both <div /> elements each call // unmountIDFromEnvironment which calls purgeID, for a total of 4. expect(ReactMount.purgeID.callCount).toBe(4); }); </ins> it('should detect valid CompositeComponent classes', function() { var Component = React.createClass({ render: function() {


Question: I don't know where the right place to link to them is. Maybe "Getting started", "Tutorial" and "Tooling integration"?

that support `*.tmLanguage`. * Linting provides accurate line numbers after compiling without sourcemaps. * Elements use standard scoping so linters can find usage of out-of-scope components. <ins> ### Debugging [React Developer Tools](https://github.com/facebook/react-devtools) is a [Chrome extension](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en) that allows you to inspect the React component hierarchy in the Chrome Developer Tools. </ins>


Question:
I couldn't find a reference to the fact that jsx transform attaches to the component spec, this would be nice to document somewhere (more importantly, that not using jsx means debugging messages will be littered with ). I found this while using .
That would be very nice indeed. If you want to take a stab at it, the docs are in the repo in the markdown format. Would love to have you on the contributor list :)

var app = <MyComponent someProperty={true} />; ``` <ins> JSX will infer the component's name from the variable assignment and specify the class's [displayName](/react/docs/component-specs.html#displayName) accordingly. </ins> See [Multiple Components](/react/docs/multiple-components.html) to learn more about using composite components. > Note:

<!-- TODO: Document mixins here directly. --> <ins> ### displayName ```javascript string displayName ``` The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](react/docs/jsx-in-depth.html#react-composite-components). </ins> ## Lifecycle Methods Various methods are executed at specific points in a component's lifecycle.


Question:
I ran a few benchmarks on the server (modifying to not use jsdom). The results were surprising, as the browserified was about 30% faster than the npm version, even with . The performance ranking (test run time) was < < < . I suspect is not a regular js object but perhaps a getter and thus carries a penalty when you test for everywhere. Also the minified version might still perform best of all, as at least some time ago V8 used function source length (including comments) as a heuristic for function complexity / compilation time and thus affecting chances for optimization in some cases, but the effect might be negligible.
is indeed not a regular object, but defined from the native side, so that may be the culprit for server rendering regression: and So this introduced a getter in quite time-sensitive places (around invariants etc) in your otherwise clean codebase. Can you reproduce the issue? /cc
Lately I have been simply using a wrapped module Works great. You could consider switching npm package to some such scheme if there are no downsides.
My first attempt was to just add to the top of every file, but unfortunately uglify isn't smart enough to do dead code removal then. I wonder if we should have essentially make two copies of the code -- one for dev, one for prod, so transforms into so we only pay the getter cost once (per module) at require time. Is doing this easy with recast? It's not obvious to me if interacts well with cloning the AST.
I would love to see this get some attention. 30% improvement out of the box would be awesome. Is there a lot of work to do here?
I think eventually we will want people to do a build step for server rendering, i.e. webpack's mode. Especially if people start expressing static asset dependencies as statements.
I'm using webpack and was enough to solve it for me. Is there no such thing in browserify?
For browserify there's transform which automatically activates for package. You just need to set before bundling: Thus browserify also can be used for bundling for server rendering.
Call me all crazy, just had a left field idea. Could the transformer that builds the npm module create 2 complete copies of react? one for dev and one for production? In the the normal version of react could you there look at the and swap which module is returned? This way on server you only get the performance hit once;
That's not too crazy. It's a bit annoying from a build process though. I'd love to know what's happening at a larger scale in the node community. It seems like we shouldn't be the first people to encounter this in a larger scale. A couple other ideas… What if we set in our main module and leave in our code everywhere else. There's some obvious bad behavior there (setting globals). So we could do variants. Only set it when it's not already set. Change to something more unique at build time () and then set that. If we switch to webpack for building the browser bundles, then the solution is super easy, and I'm sure there's a way to do this in browserify too. Another idea: Have a modules which memoizes . This is sounding like something node should do itself, but the code linked to uses ObjectTemplate (which if I'm understand a bit of V8 right doesn't do any caching because values can change). There would still be a lookup cost, but it would just be a property access, not a getter and not a call out to get current environment variables (). This one is trickier because it would mean more code and we won't do this internally. I'd prefer a different solution, even if it's more hacky. If all you're using is React and nothing from , then you could do something like mentioned above. We started shipping the browerified bundles in the npm package, so and will end up giving you the bundles which don't access .
I don't think we're going to do anything specifically for server rendering other than bundling the builds in like mentioned, but we might change the npm package eventually to be prebuilt using closure or similar.
just curious why and not ?
It was just an example. If that was the actual code I'd do the direct assignment like you suggested.
ah, ok - thanks :)
any movement on this?
No movement, though you can already require the builds from react/dist as mentioned above.
since you mentioned Webpack, do you use Webpack for server side code?
If you're already using babel on your server-side code (say, via or ), you can add the to get around this problem.
I wonder why react just can't export from for production env when react package ships with .
Because then results in a different copy of code, which will have issues. As long as that is remotely supported (and it's currently how and our addons packages work), we can't do that. we might do something like that in the future though.
true that it's not recommended to run babel on libraries? I've seen a few warnings about this. Have you tried the babel transform-inline-environment-variables plugin in production? Did it work?
Technically, you have to (which is slow) to get this to work. How do you feel about compiling not into in non-dist builds, but rather require() some module that caches the env? This is just a guess, but I believe will optimize well (function call vs. getter (which doesn't optimize in v8) + call to ). I found the babel plugin in I'll give it a try & profile.
thanks! However, I've seen a warning that is . I've only used on files in my app. I'm curious if people use it on node modules commonly in production.
The catch here is that people use envify to do dead-code elimination to remove non- blocks so changing our pattern here will force downstream changes.
Understood. I suppose it becomes a question of priorities unless we can think of something more creative. Unfortunately with the introduction of react-dom, it's not possible to use react minified builds on the server anymore unless you use a packager or the without duplicating , due to the new halfway-shimmed packages that directly.
should work, no?
Ah you're correct, since the deprecation notice will get taken out due to the production check.
Oh wait, you're right that react-dom does require react directly…
Hah got confused myself. You'd have to just require and pretend it was ReactDOM, knowing that the deprecation warnings would be removed. Doesn't seem portable to 0.15.
Initial bench results show a wider performance gap (last two runs) than the OP. In bench 4, I replace with , eliminating the getter.
I wonder if performance can just be improved in node core (by caching).
I've asked about that, but they're not interested because programs may be relying on catching ENV changes as it is possible to change the ENV of a running process. I've been able to manage a great improvement in server-side rendering (about 100%) by hosting to the top of the file as a , so it is only evaluated once. The best part is, when uglifyJS sees a const, it replaces the member in a condition, leaving which is then removed entirely. So we maintain the same code size, no backcompat hacks, and better perf. Only issue is that we may need to then post-process replace the for a in case of use with Browserify with old browsers.
Can I ask why this was closed? This is by far the number one bottleneck for us on the server-side. Having to change all code to , for example, is a leaky abstraction and very un-Node-like.
Technically you can fix the problem in your own code by doing , converting it from a live object that calls down a plain JS object. You'll get the same performance benefits, with the only downside that any code that was relying on live edits to the env (does anyone really do that?) will fail.
cool, good to know – neat idea! Still, massively leaky abstraction right? Like, suddenly React pollutes your entire app
Yeah. I've been working on , but it requires a change in UglifyJS to allow marking statements with an annotation (e.g. ) so it knows that it won't change and safe to eliminate dead code.
killer little hack btw – immediately increased our server throughput by 50% I'd still love for this issue to be reopened, or tracked elsewhere (will improve things for all React code?) should work on speeding it up as well (I believe they've made ), but having littered throughout hot code is just not ideal practice IMO – if not being able to hoist that up, cache it, memoize it, whatever, is prevented by build tools, then let's fix the build tools.
They're . is meant to be live.
oh for sure it is – I completely agree with that – I don't think it should be cached by Node either, just the current implementation has (or had) room for improvement.
As I mention in that ticket, this is the main problem: A annotation in UglifyJS will fix this.
That seems like a decent solution to me. I'm personally not a fan of the use of a global everywhere in the React code – again, it feels really build-tool specific. I'd prefer it be imported from a config file or declared in each module or something similar. Principle of least surprise and all that.
I would be happy to do that, but it is important that we have a way to eliminate dev-only code in prod builds and that users of React from npm have a way to do the same. Obviously we can use whatever tools we want for our stack easily but for npm currently we suggest envify/webpack.DefinePlugin. Not inherently opposed to changing that but we'd need a good proposal and reason.
yeah, I hear ya – there's a lot of code now in React that depends on that behaviour. Not sure I fully understand your comment "for npm currently we suggest envify/webpack.DefinePlugin" – what do you mean "for npm"? React code is compiled before it's published to npm, right? My general feeling is that it would be great if there were no FB/React-specific idioms in the code – so that it's treated as though, if v8 (or other engines) had all the ES2015/2016 features needed, then you could run the code on without even needing a compiler. Currently that's not really the case. (I'm sure you could do some sort of trick or something before requiring any React modules, but still, that would be a polluting hack) If there were a way such that was required, or declared, per module – and code elimination still worked as it does now for the builds – would you be amenable to a PR along those lines?
I mean: if you use webpack or browserify in conjunction with react from npm, you should be able to eliminate React dev-only code from your prod builds. envify lets us do that easily in browserify as it copies the NODEENV from when you make your build, and webpack.DefinePlugin lets you configure your build to replace with a constant which then can get constant-folded and minified out. This use case is important. Yes, if it works for the case of React devs using browserify/webpack too, not just our premade builds.
as an aside, just looking through the code now, and aside from the global , I haven't seen anything that's not supported out of the box in right now – is there a reason, aside from , that the non- code is even compiled and transformed into a different structure before publishing to npm?
Well, it does set up the team to move to ES6 for , which will be important in the near future. I've submitted a PR to UglifyJS2 as you can see above. If it's accepted this will solve the problem.
We'd still need everyone using React to upgrade to that version of UglifyJS so I can't promise that we'll take it…
Just everyone using React in combination with webpack or browserify and not using the build. Alternatively they could use the DefinePlugin to set to false to get the dead code elimination.
just to clarify, do you mean "everyone using React who also currently uses UglifyJS with it"?
Just so I'm clear, there are a few users here that I can think of. Those, on the browser: everywhere already, or as a global browserify/webpack + envify/DefinePlugin browserify/webpack + envify/DefinePlugin + UglifyJS browserify/webpack + plugin to transform to or So 1 and 4 are taken care of by the compilation in . What's the main reason for even supporting 2 and 3? Is it because of things like ?
2 and 3 are the most natural for many people. If you are using browserify then envify gets used automatically because of our config in Almost everyone minifies their code in prod. It is true that we could recommend instead for many cases, but it does fall apart in the case of requiring submodules. We don't support this for external users because we consider the modules private but the addons packages use this pattern. Various third-party projects (unsupported by us) also make use of this.
I think the only reason 2 and 3 are "most natural" is just because is used everywhere so you have to use something just to get it to even work out of the box. It would be equally easy to setup the config in to use or or whatever. I use 4 whenever I can and it's no more complicated than 2 or 3 for normal usage – I guess it's just a pity that users are encouraged to "reach in" to for various addons. Thanks for the clarification. So it's those doing 3 who are expecting their current UglifyJS setup to eliminate any code using that you're concerned about?
To clarify: we recommend users require or similar, which (currently) reaches into react but that's an implementation detail. Yes.
Ah cool, good to know.
We have been bitten by this one too. Would be great if some note about this behavior was present on , it's a large performance impact, and is hard to find this issue unless you have already done all the investigation work.
I would like to add that this issue also affects applications. Now the work arounds seem to be: Include the minified version of React globally via tag, it would only work in Electron and it isn't the node way, where one should be able to track every used object just seeing the . It also makes it difficult to switch between dev/prod. Use the to replace with a regular object. Not good, as we are forced to overwrite node api just because we want to use React. If using babel: ... by default babel doesn't transpile nodemodules, this can be configured but doesn't look like a work around. Note that replace every to isn't a solution because automatically requires from root, not from . Why is this issue closed? It seems to me that React should be able to initialize its configuration using , then rely on its own objects, and optionally offer a function to change the value later. Is there any reason why this wouldn't work?
Technically this could be fixed now as UglifyJS supports annotations, and it may be easier still as the team moves the build to Rollup in . In combination with Rollup, it would be simple to export a var from a constants file and have it effectively tagged by Uglify for dead code elimination in production mode.
Adding my two cents here, I was able to work around this by adding the following to the top of my I had previously wrapped React using local modules as was suggested above, but this caused a lot of issues with . This seems to get the job done without too much overhead or complexity.
For future reference, the above snippet is broken per:
Referencing which will fix this now that UglifyJS can properly eliminate dev code (even if it references a that never changes) with its new option, which is a default. See for more context.

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


Question:
Replace with and no parse error happens. What’s going on?
I had the same issue with this: We actually have an internal task tracking this at Facebook but I don't think it's been looked in to yet. Here's a comment explaining why it happens:
Fixed in esprima-fb () when for esprima-fb, jstransform and react are sorted out.
I'm actually going to leave this open for now so we remember to do the version update.
Now fixed in


Question:
The link to "JSX in depth" in the "displayName" section on the "Component Specs and Lifecycle" page points to This url is not correct, the correct url is:
Thanks! Fixed in . You can close this.

string displayName ``` <del> The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](react/docs/jsx-in-depth.html#react-composite-components). </del> <ins> The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](/react/docs/jsx-in-depth.html#react-composite-components). </ins> ## Lifecycle Methods


Question:
We're currently not cleaning up strings from _mountImage after a component gets mounted. That memory could be freed. But the act of freeing the memory could be more expensive than it's worth. Needs proper benchmarks and a workaround.
I noticed this a little while ago. I'm not sure why we need to store it on the child instance in the first place -- PR incoming.

transaction, this._mountDepth + 1 ); <del> child._mountImage = mountImage; </del> child._mountIndex = index; mountImages.push(mountImage); index++;

* Creates a child component. * * @param {ReactComponent} child Component to create. <ins> * @param {string} mountImage Markup to insert. </ins> * @protected */ <del> createChild: function(child) { enqueueMarkup(this._rootNodeID, child._mountImage, child._mountIndex); </del> <ins> createChild: function(child, mountImage) { enqueueMarkup(this._rootNodeID, mountImage, child._mountIndex); </ins> }, /**

transaction, this._mountDepth + 1 ); <del> child._mountImage = mountImage; </del> child._mountIndex = index; <del> this.createChild(child); </del> <ins> this.createChild(child, mountImage); </ins> this._renderedChildren = this._renderedChildren || {}; this._renderedChildren[name] = child; },

// TODO: When is this not true? if (ReactComponent.isValidComponent(child)) { this.removeChild(child); <del> child._mountImage = null; </del> child._mountIndex = null; child.unmountComponent(); delete this._renderedChildren[name];


Question:
Should those comment sections exist? I'd rather people come to IRC. Their questions are often neglected at the bottom of a doc page.
:+1: for shutting down comments
+1
:+1:


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

var divStyle = { color: 'white', backgroundImage: 'url(' + imgUrl + ')',  WebkitTransition: 'all' // note the capital 'W' here   WebkitTransition: 'all', // note the capital 'W' here msTransition: 'all' // 'ms' is the only lowercase vendor prefix  }; React.renderComponent(
Hello World!
, mountNode); ```  Style keys are camelCased in order to be consistent with accessing the properties on DOM nodes from JS (e.g. `node.style.backgroundImage`). Vendor prefixes should begin with a capital letter. This is why `WebkitTransition` has an uppercase "W".   Style keys are camelCased in order to be consistent with accessing the properties on DOM nodes from JS (e.g. `node.style.backgroundImage`). Vendor prefixes [other than `ms`](http://www.andismith.com/blog/2012/02/modernizr-prefixed/) should begin with a capital letter. This is why `WebkitTransition` has an uppercase "W".

var CSSProperty = require('CSSProperty'); <ins> var camelizeStyleName = require('camelizeStyleName'); </ins> var dangerousStyleValue = require('dangerousStyleValue'); var hyphenateStyleName = require('hyphenateStyleName'); var memoizeStringOnly = require('memoizeStringOnly'); <ins> var warning = require('warning'); </ins> var processStyleName = memoizeStringOnly(function(styleName) { return hyphenateStyleName(styleName); }); <ins> if (__DEV__) { var warnedStyleNames = {}; var warnHyphenatedStyleName = function(name) { if (warnedStyleNames.hasOwnProperty(name) && warnedStyleNames[name]) { return; } warnedStyleNames[name] = true; warning( false, 'Unsupported style property ' + name + '. Did you mean ' + camelizeStyleName(name) + '?' ); }; } </ins> /** * Operations for dealing with CSS properties. */

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

if (!styles.hasOwnProperty(styleName)) { continue; } <ins> if (__DEV__) { if (styleName.indexOf('-') > -1) { warnHyphenatedStyleName(styleName); } } </ins> var styleValue = dangerousStyleValue(styleName, styles[styleName]); if (styleValue) { style[styleName] = styleValue;

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

<ins> /** * Copyright 2014 Facebook, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. * * @providesModule camelizeStyleName * @typechecks */ "use strict"; var camelize = require('camelize'); var msPattern = /^-ms-/; /** * Camelcases a hyphenated CSS property name, for example: * *   > camelizeStyleName('background-color') *   < "backgroundColor" *   > camelizeStyleName('-moz-transition') *   < "MozTransition" *   > camelizeStyleName('-ms-transition') *   < "msTransition" * * As Andi Smith suggests * (http://www.andismith.com/blog/2012/02/modernizr-prefixed/), an `-ms` prefix * is converted to lowercase `ms`. * * @param {string} string * @return {string} */ function camelizeStyleName(string) { return camelize(string.replace(msPattern, 'ms-')); } module.exports = camelizeStyleName; </ins>

/** * Hyphenates a camelcased CSS property name, for example: * <del> *   > hyphenate('backgroundColor') </del> <ins> *   > hyphenateStyleName('backgroundColor') </ins> *   < "background-color" <del> *   > hyphenate('MozTransition') </del> <ins> *   > hyphenateStyleName('MozTransition') </ins> *   < "-moz-transition" <del> *   > hyphenate('msTransition') </del> <ins> *   > hyphenateStyleName('msTransition') </ins> *   < "-ms-transition" * * As Modernizr suggests (http://modernizr.com/docs/#prefixed), an `ms` prefix


Question:
This is a tricky issue, so I'll do my best to explain: I've been using the to build my React app using AMD. I've been using a of React (with ), which is based off of master. Until recently, everything was working fine. But since , I've been unable to create optimized builds using the plugin. At first, I assumed it was an issue with the plugin, but it seems that the offending line is the changed function: Until this change, wasn't forced on, and things worked just fine. With this change, it's no longer possible to build in an AMD environment, as errors out with: My best guess is that the isn't being correctly loaded (although it is included ), but I don't know enough about Browserify to debug this. Hoping someone else can take a look and find out what's going on. (in the meantime, I suppose I'll update my branch to undo the change that set )
is this still happening for you?
just updated to v0.9.0, and yep: Unfortunately still having to maintain my own branch :(
I have the same issue.
thanks for tracking this issue down. I was trying to update React in and was puzzled by this. I will disable it manually in the modified provides.

*/ function transformReact(source, options) { // TODO: just use react-tools <ins> options = options || {}; </ins> var visitorList; <del> if (options && options.harmony) { </del> <ins> if (options.harmony) { </ins> visitorList = visitors.getAllVisitors(); } else { visitorList = visitors.transformVisitors.react; } return transform(visitorList, source, { <del> sourceMap: supportsAccessors </del> <ins> sourceMap: supportsAccessors && options.sourceMap </ins> }); }

} scripts.forEach(function(script, i) { <del> var options; </del> <ins> var options = { sourceMap: true }; </ins> if (/;harmony=true(;|$)/.test(script.type)) { <del> options = { harmony: true }; </del> <ins> options.harmony = true </ins> } // script.async is always true for non-javascript script tags


Question:
On re-render, we innerText. This causes inconsistencies in rendering whitespace. See demo: We should make sure this doesn't happen.
We switched to use but it broke some contentEditable stuff internal to FB. knows more.
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer
looks like this was brought up in
Right, we should also do the right thing in IE8.
jQuery empties then adds a text node. Relevant commits: ()
okay interesting. I'll do this for ie8
I have a patch almost ready.
I'm curious if is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML.
hmm interesting. We definitely want to preserve whitespace though. (because of and and )

var ReactMount = require('ReactMount'); var ReactPerf = require('ReactPerf'); <del> var getTextContentAccessor = require('getTextContentAccessor'); </del> var invariant = require('invariant'); /**

style: '`style` must be set using `updateStylesByID()`.' }; <del> /** * The DOM property to use when setting text content. * * @type {string} * @private */ var textContentAccessor = getTextContentAccessor(); </del> var useWhitespaceWorkaround; /**

'updateTextContentByID', function(id, content) { var node = ReactMount.getNode(id); <del> node[textContentAccessor] = content; </del> <ins> DOMChildrenOperations.updateTextContent(node, content); </ins> } ),

} /** <ins> * Sets the text content of `node` to `text`. * * @param {DOMElement} node Node to change * @param {string} text New text content */ var updateTextContent; if (textContentAccessor === 'textContent') { updateTextContent = function(node, text) { node.textContent = text; }; } else { updateTextContent = function(node, text) { // In order to preserve newlines correctly, we can't use .innerText to set // the contents (see #1080), so we empty the element then append a text node while (node.firstChild) { node.removeChild(node.firstChild); } if (text) { var doc = node.ownerDocument || document; node.appendChild(doc.createTextNode(text)); } }; } /** </ins> * Operations for updating with DOM children. */ var DOMChildrenOperations = { dangerouslyReplaceNodeWithMarkup: Danger.dangerouslyReplaceNodeWithMarkup, <ins> updateTextContent: updateTextContent, </ins> /** * Updates a component's children by processing a series of updates. The * update configurations are each expected to have a `parentNode` property.

); break; case ReactMultiChildUpdateTypes.TEXT_CONTENT: <del> update.parentNode[textContentAccessor] = update.textContent; </del> <ins> updateTextContent( update.parentNode, update.textContent ); </ins> break; case ReactMultiChildUpdateTypes.REMOVE_NODE: // Already removed by the for-loop above.


Question:
React 0.8 React 0.9 I think this is because of switched to in 1.0.0. I submitted a to envify which uses instead of recast. This brings us back to 1.5s and delivers the same advantages as recast version (preserves code formatting): I think this is blocker for 0.9.0.
What command are you running, and in what directory? I'm having trouble reproducing the slow-down with just .

"node": ">=0.10.0" }, "peerDependencies": { <del> "envify": "~1.0.1" </del> <ins> "envify": "~1.2.0" </ins> }, "browserify": { "transform": ["envify"]


Question:
This throws . Maybe this can be simplified some more but this was the simplest repro I could make. Thanks for sending a repro case over.
Wow, it really was a bug. Narrowed it down a little, but it's still rediculously "complex". Big props to for repro! Anyway, just glancing at the code and from experience, I can safely assume that the issue is that receives multiple updates to the same node from . Which intuitively didn't make any sense at all to me, since always calls when it's done and is basically just recursive. However, when taking another peek at the code, I'm pretty sure that the issue is that (in this case) makes the invalid assumption that all updates belongs to the same root. When that is not the case, an to a component which itself updates another root will only once everything is done. The updates to the other root will NOT after each on that root because will always greater than 0. In practice this means that whenever updates another root, all DOM updates on that root will be batched one after the other (as opposed to batching component updates) which is a violation of assumptions in . It's also very inefficient. Intuitively it seems that what should happen is that all component updates within a call should be (but that is not for sure), exactly how this should be solved in practice I'm not 100% sure right now. But I'm 95% sure that this is what's happening, and the repro does have all the ingredients.
Speaking a bit to in chat, I feel like the issue is that and when called from within become asynchronous as opposed to synchronous as they usually are. Which leads to this issue, but also possibly a lot of other subtle issues.
Apparently is not at all to blame...
Narrowed it down even further, apparently it breaks immediately on the first , the error just didn't show up until later unless prodded. I still don't feel any more enlightened on the issue though...
Your latest two jsbins (4 & 6) throw different error for me (from in X ): And, if one removes Z from A , the same X throws , because then A render won't have any refs on that render so will be undefined... React docs warn that "Never access refs inside of any component's render method - or while any component's render method is even running anywhere in the call stack.", don't know if it's relevant here.
Yeah different error, but I'm sure the cause is the same. The issue is the span not actually ever being rendered, just that in the old repro it doesn't actually turn into an error until later.
Ok, so perhaps here's a reduced test case, see console: is being called twice in a row, and the first time the span is not there in DOM even though it has been rendered already. One culprit for this behavior may be that you are effectively calling setState on sibling component where setState would not be allowed on component itself (triggered via componentWillUpdate).
Huh? It does end up being rendered in your test case, and there's no error?
no I didn't want to throw the error so that you can see that the componentDidUpdate will be called double. The point is that first the span is not there and if one would try to access it (as in your ref.getDOMNode()) it would throw. See console for flow.
is defined so it's an error regardless, and more than that, React expects the node to be there, but it isn't and throws an error. Even after it still isn't physically there in the DOM. So something is wrong. Unless I'm missing something.
Yes, there is definitely a problem there as you said, sorry for not being clear. I just wanted to reduce it so that there are no refs or forceUpdates which may bring other problems. One could throw the error in componentDidUpdate for clarity, as the innerHTML is definitely empty where it should not be. But it is interesting that it will be called right away again, and then the span will be there.

* Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ <del> batchedUpdates: function(callback, param) { callback(param); </del> <ins> batchedUpdates: function(callback, a, b) { callback(a, b); </ins> } };

* Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ <del> batchedUpdates: function(callback, param) { </del> <ins> batchedUpdates: function(callback, a, b) { </ins> var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates; ReactDefaultBatchingStrategy.isBatchingUpdates = true; // The code is written this way to avoid extra allocations if (alreadyBatchingUpdates) { <del> callback(param); </del> <ins> callback(a, b); </ins> } else { <del> transaction.perform(callback, null, param); </del> <ins> transaction.perform(callback, null, a, b); </ins> } } };

"use strict"; <ins> var CallbackQueue = require('CallbackQueue'); var PooledClass = require('PooledClass'); </ins> var ReactCurrentOwner = require('ReactCurrentOwner'); var ReactPerf = require('ReactPerf'); <ins> var Transaction = require('Transaction'); </ins> var invariant = require('invariant'); <ins> var mixInto = require('mixInto'); </ins> var warning = require('warning'); var dirtyComponents = [];

); } <del> function batchedUpdates(callback, param) { </del> <ins> var NESTED_UPDATES = { initialize: function() { this.dirtyComponentsLength = dirtyComponents.length; }, close: function() { if (this.dirtyComponentsLength !== dirtyComponents.length) { // Additional updates were enqueued by componentDidUpdate handlers or // similar; before our own UPDATE_QUEUEING wrapper closes, we want to run // these new updates so that if A's componentDidUpdate calls setState on // B, B will update before the callback A's updater provided when calling // setState. dirtyComponents.splice(0, this.dirtyComponentsLength); flushBatchedUpdates(); } else { dirtyComponents.length = 0; } } }; var UPDATE_QUEUEING = { initialize: function() { this.callbackQueue.reset(); }, close: function() { this.callbackQueue.notifyAll(); } }; var TRANSACTION_WRAPPERS = [NESTED_UPDATES, UPDATE_QUEUEING]; function ReactUpdatesFlushTransaction() { this.reinitializeTransaction(); this.dirtyComponentsLength = null; this.callbackQueue = CallbackQueue.getPooled(null); this.reconcileTransaction = ReactUpdates.ReactReconcileTransaction.getPooled(); } mixInto(ReactUpdatesFlushTransaction, Transaction.Mixin); mixInto(ReactUpdatesFlushTransaction, { getTransactionWrappers: function() { return TRANSACTION_WRAPPERS; }, destructor: function() { this.dirtyComponentsLength = null; CallbackQueue.release(this.callbackQueue); this.callbackQueue = null; ReactUpdates.ReactReconcileTransaction.release(this.reconcileTransaction); this.reconcileTransaction = null; }, perform: function(method, scope, a) { // Essentially calls `this.reconcileTransaction.perform(method, scope, a)` // with this transaction's wrappers around it. return Transaction.Mixin.perform.call( this, this.reconcileTransaction.perform, this.reconcileTransaction, method, scope, a ); } }); PooledClass.addPoolingTo(ReactUpdatesFlushTransaction); function batchedUpdates(callback, a, b) { </ins> ensureInjected(); <del> batchingStrategy.batchedUpdates(callback, param); </del> <ins> batchingStrategy.batchedUpdates(callback, a, b); </ins> } /**

} function runBatchedUpdates(transaction) { <ins> var len = transaction.dirtyComponentsLength; invariant( len === dirtyComponents.length, 'Expected flush transaction's stored dirty-components length (%s) to ' + 'match dirty-components array length (%s).', len, dirtyComponents.length ); </ins> // Since reconciling a component higher in the owner hierarchy usually (not // always -- see shouldComponentUpdate()) will reconcile children, reconcile // them before their children by sorting the array. dirtyComponents.sort(mountDepthComparator); <del> for (var i = 0; i < dirtyComponents.length; i++) { </del> <ins> for (var i = 0; i < len; i++) { </ins> // If a component is unmounted before pending changes apply, ignore them // TODO: Queue unmounts in the same list to avoid this happening at all var component = dirtyComponents[i];

// stash the callbacks first var callbacks = component._pendingCallbacks; component._pendingCallbacks = null; <del> component.performUpdateIfNecessary(transaction); </del> <ins> component.performUpdateIfNecessary(transaction.reconcileTransaction); </ins> if (callbacks) { for (var j = 0; j < callbacks.length; j++) { <del> transaction.getReactMountReady().enqueue( </del> <ins> transaction.callbackQueue.enqueue( </ins> callbacks[j], component );

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

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

expect(aUpdated).toBe(true); });  it('should flush updates in the correct order', function() { var updates = []; var Outer = React.createClass({ getInitialState: function() { return {x: 0}; }, render: function() { updates.push('Outer-render-' + this.state.x); return
<Inner x={this.state.x} ref="inner" />
; }, componentDidUpdate: function() { var x = this.state.x; updates.push('Outer-didUpdate-' + x); updates.push('Inner-setState-' + x); this.refs.inner.setState({x: x}, function() { updates.push('Inner-callback-' + x); }); } }); var Inner = React.createClass({ getInitialState: function() { return {x: 0}; }, render: function() { updates.push('Inner-render-' + this.props.x + '-' + this.state.x); return
; }, componentDidUpdate: function() { updates.push('Inner-didUpdate-' + this.props.x + '-' + this.state.x); } }); var instance = ReactTestUtils.renderIntoDocument(<Outer />); updates.push('Outer-setState-1'); instance.setState({x: 1}, function() { updates.push('Outer-callback-1'); updates.push('Outer-setState-2'); instance.setState({x: 2}, function() { updates.push('Outer-callback-2'); }); }); expect(updates).toEqual([ 'Outer-render-0', 'Inner-render-0-0', 'Outer-setState-1', 'Outer-render-1', 'Inner-render-1-0', 'Inner-didUpdate-1-0', 'Outer-didUpdate-1', 'Inner-setState-1', 'Inner-render-1-1', 'Inner-didUpdate-1-1', 'Inner-callback-1', 'Outer-callback-1', 'Outer-setState-2', 'Outer-render-2', 'Inner-render-2-1', 'Inner-didUpdate-2-1', 'Outer-didUpdate-2', 'Inner-setState-2', 'Inner-render-2-2', 'Inner-didUpdate-2-2', 'Inner-callback-2', 'Outer-callback-2' ]); }); it('should queue nested updates', function() { // See https://github.com/facebook/react/issues/1147 var X = React.createClass({ getInitialState: function() { return {s: 0}; }, render: function() { if (this.state.s === 0) { return
 0
; } else { return
1
; } }, go: function() { this.setState({s: 1}); this.setState({s: 0}); this.setState({s: 1}); } }); var Y = React.createClass({ render: function() { return
 <Z />
; } }); var Z = React.createClass({ render: function() { return
; }, componentWillUpdate: function() { x.go(); } }); var x; var y; x = ReactTestUtils.renderIntoDocument(<X />); y = ReactTestUtils.renderIntoDocument(<Y />); expect(x.getDOMNode().textContent).toBe('0'); y.forceUpdate(); expect(x.getDOMNode().textContent).toBe('1'); }); it('should queue updates from during mount', function() { // See https://github.com/facebook/react/issues/1353 var a; var A = React.createClass({ getInitialState: function() { return {x: 0}; }, componentWillMount: function() { a = this; }, render: function() { return
A{this.state.x}
; } }); var B = React.createClass({ componentWillMount: function() { a.setState({x: 1}); }, render: function() { return
; } }); ReactUpdates.batchedUpdates(function() { ReactTestUtils.renderIntoDocument(

 ); }); expect(a.state.x).toBe(1); expect(a.getDOMNode().textContent).toBe('A1'); }); it('calls componentWillReceiveProps setState callback properly', function() { var callbackCount = 0; var A = React.createClass({ getInitialState: function() { return {x: this.props.x}; }, componentWillReceiveProps: function(nextProps) { var newX = nextProps.x; this.setState({x: newX}, function() { // State should have updated by the time this callback gets called expect(this.state.x).toBe(newX); callbackCount++; }); }, render: function() { return
{this.state.x}
; } }); var container = document.createElement('div'); React.renderComponent(, container); React.renderComponent(, container); expect(callbackCount).toBe(1); });  });


Question:
Is transformed to: Note the trailing - this results in a syntax error. The problem seems to be with comma insertion in and related functions (e.g, ). See IRC discussion below for my findings. Relevant parts of an IRC discussion:
The root of the issue is that is a special-case in JSX, but it apparently does not take into account . Should be an easy fix. We should also look into adding I feel, just to be able to easily comment out code. EDIT: I was wrong, the special-case is handled correctly, I'll have a PR up shortly.

var childrenToRender = object.children.filter(function(child) { return !(child.type === Syntax.Literal && typeof child.value === 'string' <del> && child.value.match(/^[ t]*[rn][ trn]*$/)); </del> <ins> && child.value.match(/^[ t]*[rn][ trn]*$/) || child.type === Syntax.XJSExpressionContainer && child.expression.type === Syntax.XJSEmptyExpression); </ins> }); if (childrenToRender.length > 0) { utils.append(', ', state);


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

* Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ <del> batchedUpdates: function(callback, param) { callback(param); </del> <ins> batchedUpdates: function(callback, a, b) { callback(a, b); </ins> } };

* Call the provided function in a context within which calls to `setState` * and friends are batched such that components aren't updated unnecessarily. */ <del> batchedUpdates: function(callback, param) { </del> <ins> batchedUpdates: function(callback, a, b) { </ins> var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates; ReactDefaultBatchingStrategy.isBatchingUpdates = true; // The code is written this way to avoid extra allocations if (alreadyBatchingUpdates) { <del> callback(param); </del> <ins> callback(a, b); </ins> } else { <del> transaction.perform(callback, null, param); </del> <ins> transaction.perform(callback, null, a, b); </ins> } } };

"use strict"; <ins> var CallbackQueue = require('CallbackQueue'); var PooledClass = require('PooledClass'); </ins> var ReactCurrentOwner = require('ReactCurrentOwner'); var ReactPerf = require('ReactPerf'); <ins> var Transaction = require('Transaction'); </ins> var invariant = require('invariant'); <ins> var mixInto = require('mixInto'); </ins> var warning = require('warning'); var dirtyComponents = [];

); } <del> function batchedUpdates(callback, param) { </del> <ins> var NESTED_UPDATES = { initialize: function() { this.dirtyComponentsLength = dirtyComponents.length; }, close: function() { if (this.dirtyComponentsLength !== dirtyComponents.length) { // Additional updates were enqueued by componentDidUpdate handlers or // similar; before our own UPDATE_QUEUEING wrapper closes, we want to run // these new updates so that if A's componentDidUpdate calls setState on // B, B will update before the callback A's updater provided when calling // setState. dirtyComponents.splice(0, this.dirtyComponentsLength); flushBatchedUpdates(); } else { dirtyComponents.length = 0; } } }; var UPDATE_QUEUEING = { initialize: function() { this.callbackQueue.reset(); }, close: function() { this.callbackQueue.notifyAll(); } }; var TRANSACTION_WRAPPERS = [NESTED_UPDATES, UPDATE_QUEUEING]; function ReactUpdatesFlushTransaction() { this.reinitializeTransaction(); this.dirtyComponentsLength = null; this.callbackQueue = CallbackQueue.getPooled(null); this.reconcileTransaction = ReactUpdates.ReactReconcileTransaction.getPooled(); } mixInto(ReactUpdatesFlushTransaction, Transaction.Mixin); mixInto(ReactUpdatesFlushTransaction, { getTransactionWrappers: function() { return TRANSACTION_WRAPPERS; }, destructor: function() { this.dirtyComponentsLength = null; CallbackQueue.release(this.callbackQueue); this.callbackQueue = null; ReactUpdates.ReactReconcileTransaction.release(this.reconcileTransaction); this.reconcileTransaction = null; }, perform: function(method, scope, a) { // Essentially calls `this.reconcileTransaction.perform(method, scope, a)` // with this transaction's wrappers around it. return Transaction.Mixin.perform.call( this, this.reconcileTransaction.perform, this.reconcileTransaction, method, scope, a ); } }); PooledClass.addPoolingTo(ReactUpdatesFlushTransaction); function batchedUpdates(callback, a, b) { </ins> ensureInjected(); <del> batchingStrategy.batchedUpdates(callback, param); </del> <ins> batchingStrategy.batchedUpdates(callback, a, b); </ins> } /**

} function runBatchedUpdates(transaction) { <ins> var len = transaction.dirtyComponentsLength; invariant( len === dirtyComponents.length, 'Expected flush transaction's stored dirty-components length (%s) to ' + 'match dirty-components array length (%s).', len, dirtyComponents.length ); </ins> // Since reconciling a component higher in the owner hierarchy usually (not // always -- see shouldComponentUpdate()) will reconcile children, reconcile // them before their children by sorting the array. dirtyComponents.sort(mountDepthComparator); <del> for (var i = 0; i < dirtyComponents.length; i++) { </del> <ins> for (var i = 0; i < len; i++) { </ins> // If a component is unmounted before pending changes apply, ignore them // TODO: Queue unmounts in the same list to avoid this happening at all var component = dirtyComponents[i];

// stash the callbacks first var callbacks = component._pendingCallbacks; component._pendingCallbacks = null; <del> component.performUpdateIfNecessary(transaction); </del> <ins> component.performUpdateIfNecessary(transaction.reconcileTransaction); </ins> if (callbacks) { for (var j = 0; j < callbacks.length; j++) { <del> transaction.getReactMountReady().enqueue( </del> <ins> transaction.callbackQueue.enqueue( </ins> callbacks[j], component );

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

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

expect(aUpdated).toBe(true); });  it('should flush updates in the correct order', function() { var updates = []; var Outer = React.createClass({ getInitialState: function() { return {x: 0}; }, render: function() { updates.push('Outer-render-' + this.state.x); return
<Inner x={this.state.x} ref="inner" />
; }, componentDidUpdate: function() { var x = this.state.x; updates.push('Outer-didUpdate-' + x); updates.push('Inner-setState-' + x); this.refs.inner.setState({x: x}, function() { updates.push('Inner-callback-' + x); }); } }); var Inner = React.createClass({ getInitialState: function() { return {x: 0}; }, render: function() { updates.push('Inner-render-' + this.props.x + '-' + this.state.x); return
; }, componentDidUpdate: function() { updates.push('Inner-didUpdate-' + this.props.x + '-' + this.state.x); } }); var instance = ReactTestUtils.renderIntoDocument(<Outer />); updates.push('Outer-setState-1'); instance.setState({x: 1}, function() { updates.push('Outer-callback-1'); updates.push('Outer-setState-2'); instance.setState({x: 2}, function() { updates.push('Outer-callback-2'); }); }); expect(updates).toEqual([ 'Outer-render-0', 'Inner-render-0-0', 'Outer-setState-1', 'Outer-render-1', 'Inner-render-1-0', 'Inner-didUpdate-1-0', 'Outer-didUpdate-1', 'Inner-setState-1', 'Inner-render-1-1', 'Inner-didUpdate-1-1', 'Inner-callback-1', 'Outer-callback-1', 'Outer-setState-2', 'Outer-render-2', 'Inner-render-2-1', 'Inner-didUpdate-2-1', 'Outer-didUpdate-2', 'Inner-setState-2', 'Inner-render-2-2', 'Inner-didUpdate-2-2', 'Inner-callback-2', 'Outer-callback-2' ]); }); it('should queue nested updates', function() { // See https://github.com/facebook/react/issues/1147 var X = React.createClass({ getInitialState: function() { return {s: 0}; }, render: function() { if (this.state.s === 0) { return
 0
; } else { return
1
; } }, go: function() { this.setState({s: 1}); this.setState({s: 0}); this.setState({s: 1}); } }); var Y = React.createClass({ render: function() { return
 <Z />
; } }); var Z = React.createClass({ render: function() { return
; }, componentWillUpdate: function() { x.go(); } }); var x; var y; x = ReactTestUtils.renderIntoDocument(<X />); y = ReactTestUtils.renderIntoDocument(<Y />); expect(x.getDOMNode().textContent).toBe('0'); y.forceUpdate(); expect(x.getDOMNode().textContent).toBe('1'); }); it('should queue updates from during mount', function() { // See https://github.com/facebook/react/issues/1353 var a; var A = React.createClass({ getInitialState: function() { return {x: 0}; }, componentWillMount: function() { a = this; }, render: function() { return
A{this.state.x}
; } }); var B = React.createClass({ componentWillMount: function() { a.setState({x: 1}); }, render: function() { return
; } }); ReactUpdates.batchedUpdates(function() { ReactTestUtils.renderIntoDocument(

 ); }); expect(a.state.x).toBe(1); expect(a.getDOMNode().textContent).toBe('A1'); }); it('calls componentWillReceiveProps setState callback properly', function() { var callbackCount = 0; var A = React.createClass({ getInitialState: function() { return {x: this.props.x}; }, componentWillReceiveProps: function(nextProps) { var newX = nextProps.x; this.setState({x: newX}, function() { // State should have updated by the time this callback gets called expect(this.state.x).toBe(newX); callbackCount++; }); }, render: function() { return
{this.state.x}
; } }); var container = document.createElement('div'); React.renderComponent(, container); React.renderComponent(, container); expect(callbackCount).toBe(1); });  });


Question:
ReactCSSTransitionGroup doesn't work properly on (at least) Android 4.2. I've narrowed it down to the code in which is finding and properties on the test element's object and so only registering and handlers, despite the fact that Android fires events. So the end of the transition isn't properly detected. I will do some more investigation and see if there's a safer way to do this detection on Android (I seem to recall seeing something similar before).
See this patch for the Dojo toolkit: - basically on some Android versions is not . Could this be fixed by changing the order the properties are checked, so that is checked for before ?
This is still an issue on Android 4.3 (or at least on Samsung Galaxy S3 with Android 4.3). However changing the webkitTransition and transition order as suggested by it fixes the issue.
Is TransitionEvent defined or undefined on that browser? When the unprefixed version exists it's better to use that in general because it's more forwards-compatible.

var ExecutionEnvironment = require('ExecutionEnvironment'); <ins> /** * EVENT_NAME_MAP is used to determine which event fired when a * transition/animation ends, based on the style property used to * define that event. */ </ins> var EVENT_NAME_MAP = { transitionend: { 'transition': 'transitionend',

function detectEvents() { var testEl = document.createElement('div'); var style = testEl.style; <ins> // On some platforms, in particular some releases of Android 4.x, // the un-prefixed "animation" and "transition" properties are defined on the // style object but the events that fire will still be prefixed, so we need // to check if the un-prefixed events are useable, and if not remove them // from the map if (!('AnimationEvent' in window)) { delete EVENT_NAME_MAP.animationend.animation; } if (!('TransitionEvent' in window)) { delete EVENT_NAME_MAP.transitionend.transition; } </ins> for (var baseEventName in EVENT_NAME_MAP) { var baseEvents = EVENT_NAME_MAP[baseEventName]; for (var styleName in baseEvents) {


Question:
I am getting this error when I run jsx. Is this happening to anybody else? Am I doing something wrong?
version, how are you running it, any details to help repro? cc - this is in commoner.
Thanks for the quick reply. It happened on 0.8, 0.9 and 0.10.0-rc1. I just ran it like this. Also, if I run it on a file, like this. It works. But not when I run it against a whole directory.
Thanks a lot for the report. Looks like has updated commoner and I'm sure he'll update our dependency here as soon as he pushes that to npm.
Hey guys, thanks for the quick response, and thanks for all the good work :+1:
mysql I aslo encounter this problem today
Just in case you still have an old version of the dependency installed, you can do

"url": "https://github.com/facebook/react" }, "dependencies": { <del> "commoner": "~0.9.1", </del> <ins> "commoner": "^0.9.2", </ins> "esprima-fb": "~3001.1.0-dev-harmony-fb", "jstransform": "~3.0.0" },


Question:
H:githubreactgrunt Running "delete-build-modules" task Running "jsx:normal" (jsx) task Warning: This socket is closed. Use --force to continue. Aborted due to warnings. on windows. any hint?
The issue arises in the jsx task at line 42: File: [no files] Warning: This socket is closed. Use --force to continue. Error: This socket is closed. at () at doWrite () at writeOrBuffer () at () at () at (c:reactgrunttasks) at Object.<anonymous(c:reactnodemodulesgruntlibgrunt) at (c:reactnodemodulesgruntlibgrunt) at Object.<anonymous(c:reactnodemodulesgruntlibutil) at Task.runTaskFn (c:reactnode_modulesgruntlibutil) var child = spawn({ cmd: "bin/jsx-internal", args: args }, function(error, result, code) { if (error) { (error); done(false); } else { done(); } }); (JSON.stringify(config.getConfig())); So, looks like the spawn child's input stream is not available. Running node bin/jsx-internal" works however, get a message saying "Warning: still waiting for STDIN after 1000ms"
- can you take a look?
I was able to work around this by changing the following in grunttasks to Obviously this change is Windows-only but does provide a possible workaround.
What about changing it to
Yes, I can verify that worked on my machine. Sorry, I used some leftover code for executing batch files which requires going through cmd.
Cool, I can put up a PR for that (unless you have the time,
Sure, I can do that. Thanks for the help!

'use strict'; <ins> var path = require("path"); </ins> var grunt = require("grunt"); var expand = grunt.file.expand; var spawn = grunt.util.spawn;

args.push("--config" /* from stdin */); var child = spawn({ <del> cmd: "bin/jsx-internal", args: args </del> <ins> cmd: "node", args: [path.join("bin", "jsx-internal")].concat(args) </ins> }, function(error, result, code) { if (error) { grunt.log.error(error);


Question:
While testing I wanted to simulate and events, but for some reason they are not firing the handlers in the component. Here's a fiddle to show you: You'll see that with the Simulate functions, only the click is actually triggered, while the other ones not. With the real events everything works perfectly. I tried to debug a little bit what's going on, but didn't get much information, especially since it's the first time I'm diving into the events mechanism internals in React. If you want more info, then I can try and dig a bit deeper, but I think the fiddle is clear enough.
Yeah, unfortunately mouseEnter/mouseLeave don't get simulated properly at the moment due to their unique bubbling situation. The biggest blocker here is picking a good API, I think. Maybe just ?
Why should the user care about where the mouse moves from/to? Perhaps this can be handled internally? Is the problem due to bubbling here? I may need to dive into the code a little more to get a better understanding and stop saying nonsense :P
Yes, it's due to bubbling. If you have the DOM structure and your mouse moves from C to D, then C and B receive mouseleave events, D receives a mouseenter event, and A receives nothing. All other events bubble up to the root. Perhaps it's good enough to just make simulated mouseEnter and mouseLeave events not bubble at all.
That would work at least where I was trying to test. While testing I generally don't need anything too complex, just making sure the right behavior triggers when the event happens. Hopefully that's the way others do as well
(As a workaround for now, you can use SimulateNative.mouseOver and SimulateNative.mouseOut (making sure to specify relatedTarget appropriately on each) and together they will cause React to fire onMouseEnter and onMouseLeave events.)
Do we have a good solution for such case now? I'm trying my solution but feeling so tricky. And I got still quite strange results:
can you give an example. I can't find any documentation on SimulateNative or how to set relatedTarget appropriately?
You want to do something like this: The simulates the mouse moving one element another. The element can be anything really, it’s not important.
Do we have a good solution for such case now? or It can not be solved?
I am manually applying this patch until it is pulled into the core:
Any update on this?
I was able to get my tests to pass using SimulateNative. Here's my codez: Test results:
I tried that using both and instead of but it still did not trigger my event.
If it helps - the difference which worked for me was calling with a and not a . Pass & fail states listed along with full test case below: This seems to also work:
No update so far? Maybe some workarounds?
This was fixed in in April as you can see a few messages up; it'll be in the 0.14 release. If you search "workaround" on this page you'll see that I also posted a workaround over a year ago.
Sorry, really missed it. Thanks for it!

var ON_CLICK_KEY = keyOf({onClick: null}); var ON_TOUCH_TAP_KEY = keyOf({onTouchTap: null}); var ON_CHANGE_KEY = keyOf({onChange: null}); <ins> var ON_MOUSE_ENTER_KEY = keyOf({onMouseEnter: null}); </ins> /**

expect(handleParentClick.mock.calls.length).toBe(0); }); <ins> it('should have mouse enter simulated by test utils', function() { ReactBrowserEventEmitter.putListener( getID(CHILD), ON_MOUSE_ENTER_KEY, recordID.bind(null, getID(CHILD)) ); ReactTestUtils.Simulate.mouseEnter(CHILD); expect(idCallOrder.length).toBe(1); expect(idCallOrder[0]).toBe(getID(CHILD)); }); </ins> it('should infer onTouchTap from a touchStart/End', function() { ReactBrowserEventEmitter.putListener( getID(CHILD),

node = domComponentOrNode; } <ins> var dispatchConfig = ReactBrowserEventEmitter.eventNameDispatchConfigs[eventType]; </ins> var fakeNativeEvent = new Event(); fakeNativeEvent.target = node; // We don't use SyntheticEvent.getPooled in order to not have to worry about // properly destroying any properties assigned from `eventData` upon release var event = new SyntheticEvent( <del> ReactBrowserEventEmitter.eventNameDispatchConfigs[eventType], </del> <ins> dispatchConfig, </ins> ReactMount.getID(node), fakeNativeEvent ); assign(event, eventData); <del> EventPropagators.accumulateTwoPhaseDispatches(event); </del> <ins> if (dispatchConfig.phasedRegistrationNames) { EventPropagators.accumulateTwoPhaseDispatches(event); } else { EventPropagators.accumulateDirectDispatches(event); } </ins> ReactUpdates.batchedUpdates(function() { EventPluginHub.enqueueEvents(event);


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

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

} if (styleValue != null) { serialized += processStyleName(styleName) + ':'; <del> serialized += dangerousStyleValue(styleName, styleValue) + ';'; </del> <ins> serialized += dangerousStyleValue(styleName, styleValue, component) + ';'; </ins> } } return serialized || null;

} propValue = this._previousStyleCopy = assign({}, props.style); } <del> propValue = CSSPropertyOperations.createMarkupForStyles(propValue); </del> <ins> propValue = CSSPropertyOperations.createMarkupForStyles(propValue, this); </ins> } var markup = null; if (this._tag != null && isCustomComponent(this._tag, props)) {

expect(console.error.argsForCall.length).toBe(2); });  it('should warn about styles with numeric string values for non-unitless properties', function() { spyOn(console, 'error'); var div = document.createElement('div'); var One = React.createClass({ render: function() { return this.props.inline ?  :
; }, }); var Two = React.createClass({ render: function() { return
; }, }); ReactDOM.render(<One inline={false} />, div); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toBe( 'Warning: a `div` tag (owner: `One`) was passed a numeric string value ' + 'for CSS property `fontSize` (value: `1`) which will be treated ' + 'as a unitless number in a future version of React.' ); // Don't warn again for the same component ReactDOM.render(<One inline={true} />, div); expect(console.error.calls.length).toBe(1); // Do warn for different components ReactDOM.render(<Two />, div); expect(console.error.calls.length).toBe(2); expect(console.error.argsForCall[1][0]).toBe( 'Warning: a `div` tag (owner: `Two`) was passed a numeric string value ' + 'for CSS property `fontSize` (value: `1`) which will be treated ' + 'as a unitless number in a future version of React.' ); // Really don't warn again for the same component ReactDOM.render(<One inline={true} />, div); expect(console.error.calls.length).toBe(2); });  it('should warn semi-nicely about NaN in style', function() { spyOn(console, 'error');

'use strict'; var CSSProperty = require('CSSProperty'); <ins> var warning = require('warning'); </ins> var isUnitlessNumber = CSSProperty.isUnitlessNumber; <ins> var styleWarnings = {}; </ins> /** * Convert a value into the proper css writable value. The style name `name`

* * @param {string} name CSS property name such as `topMargin`. * @param {*} value CSS property value such as `10px`. <ins> * @param {ReactDOMComponent} component </ins> * @return {string} Normalized style value with dimensions applied. */ <del> function dangerousStyleValue(name, value) { </del> <ins> function dangerousStyleValue(name, value, component) { </ins> // Note that we've removed escapeTextForBrowser() calls here since the // whole string will be escaped when the attribute is injected into // the markup. If you provide unsafe user data here they can inject

} if (typeof value === 'string') { <ins> if (__DEV__) { if (component) { var owner = component._currentElement._owner; var ownerName = owner ? owner.getName() : null; if (ownerName && !styleWarnings[ownerName]) { styleWarnings[ownerName] = {}; } var warned = false; if (ownerName) { var warnings = styleWarnings[ownerName]; warned = warnings[name]; if (!warned) { warnings[name] = true; } } if (!warned) { warning( false, 'a `%s` tag (owner: `%s`) was passed a numeric string value ' + 'for CSS property `%s` (value: `%s`) which will be treated ' + 'as a unitless number in a future version of React.', component._currentElement.type, ownerName || 'unknown', name, value ); } } } </ins> value = value.trim(); } return value + 'px';


Question:
Sometimes it's helpful for to have a playground for grokking React's features, and I like to use the live editor on the docs site to sketch out ideas and see how my code is called by the library. It'd be a huge help if the site's React source was served unminified so it's more apparent what's going on under the covers.
I think this would be helpful:
I think I'd be okay with this. Want to send a PR?

<![endif]--> <script type="text/javascript" src="/react/js/codemirror.js"></script> <script type="text/javascript" src="/react/js/javascript.js"></script> <del> <script type="text/javascript" src="/react/js/react.min.js"></script> </del> <ins> <script type="text/javascript" src="/react/js/react.js"></script> </ins> <script type="text/javascript" src="/react/js/JSXTransformer.js"></script> <script type="text/javascript" src="/react/js/live_editor.js"></script> <script type="text/javascript" src="/react/js/showdown.js"></script>

react_docs: { files: [ { <del> src: ['react.min.js', 'JSXTransformer.js'], </del> <ins> src: ['react.js', 'JSXTransformer.js'], </ins> dest: 'docs/js/', cwd: 'build/', expand: true


Question:
Here's an example at jsbin: Clicking for the first time works (mounts a SVG +), but when clicking the same button again (which should unmount the rect+title), react throws an exception. I have no clue how to get around this. Help is very much appreciated. Thanks in advance!
Ah, this is because React doesn't let you unmount the HTML element. I don't believe there's a workaround right now, sorry. cc
Fixed by .

html: createFullPageComponent(ReactDOM.html), head: createFullPageComponent(ReactDOM.head), <del> title: createFullPageComponent(ReactDOM.title), </del> body: createFullPageComponent(ReactDOM.body) });


Question:
Logging and reveals: Which doesn't make sense (to me at least).
Can you log the too and something to distinguish the two renderComponent calls?
Updated, that makes more sense,

var DOMProperty = require('DOMProperty'); var DOMPropertyOperations = require('DOMPropertyOperations'); var ReactBrowserEventEmitter = require('ReactBrowserEventEmitter'); <ins> var ReactComponentBrowserEnvironment = require('ReactComponentBrowserEnvironment'); </ins> var ReactMount = require('ReactMount'); var ReactMultiChild = require('ReactMultiChild'); var ReactPerf = require('ReactPerf');

unmountComponent: function() { this.unmountChildren(); ReactBrowserEventEmitter.deleteAllListeners(this._rootNodeID); <del> ReactMount.purgeID(this._rootNodeID); </del> <ins> ReactComponentBrowserEnvironment.unmountIDFromEnvironment(this._rootNodeID); </ins> this._rootNodeID = null; }

}, unmountComponent: function() { <del> // TODO: Is this necessary? </del> ReactComponentBrowserEnvironment.unmountIDFromEnvironment(this._rootNodeID); }

this._pendingCallbacks = null; this._pendingElement = null; <del> ReactComponentEnvironment.unmountIDFromEnvironment(this._rootNodeID); </del> // These fields do not really need to be reset since this object is no // longer accessible. this._context = null;

render: function() { return <div> <Inner /> <ins> Text </ins> </div>; } });

React.unmountComponentAtNode(container); expect(innerUnmounted).toBe(true); <del> // <Component />, <Inner />, and both <div /> elements and their wrappers // each call unmountIDFromEnvironment which calls purgeID, for a total of 6. </del> <ins> // The text and both <div /> elements and their wrappers each call // unmountIDFromEnvironment which calls purgeID, for a total of 3. </ins> // TODO: Test the effect of this. E.g. does the node cache get repopulated // after a getDOMNode call? <del> expect(ReactMount.purgeID.callCount).toBe(6); </del> <ins> expect(ReactMount.purgeID.callCount).toBe(3); </ins> }); it('should warn when shouldComponentUpdate() returns undefined', function() {


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

); ``` <del> A nice feature of mixins is that if a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. </del> <ins> A nice feature of mixins is that if a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. Methods defined on mixins run in the order mixins were listed, followed by a method call on the component. </ins>

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

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

var Constructor = ConvenienceConstructor.type; var proto = Constructor.prototype; <ins> // By handling mixins before any other properties, we ensure the same // chaining order is applied to methods with DEFINE_MANY policy, whether // mixins are listed before or after these methods in the spec. if (spec.hasOwnProperty(MIXINS_KEY)) { RESERVED_SPEC_KEYS.mixins(ConvenienceConstructor, spec.mixins); } </ins> for (var name in spec) { <del> var property = spec[name]; </del> if (!spec.hasOwnProperty(name)) { continue; } <ins> if (name === MIXINS_KEY) { // We have already handled mixins in a special case above continue; } var property = spec[name]; </ins> validateMethodOverride(proto, name); if (RESERVED_SPEC_KEYS.hasOwnProperty(name)) {

var TestComponent; var TestComponentWithPropTypes; <ins> var TestComponentWithReverseSpec; </ins> var mixinPropValidator; var componentPropValidator;

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

} }); <ins> TestComponentWithReverseSpec = React.createClass({ render: function() { return <div />; }, componentDidMount: function() { this.props.listener('Component didMount'); }, mixins: [MixinBWithReverseSpec, MixinC, MixinD] }); </ins> TestComponentWithPropTypes = React.createClass({ mixins: [MixinD], propTypes: {

]); }); <ins> it('should chain functions regardless of spec property order', function() { var listener = mocks.getMockFunction(); var instance = <TestComponentWithReverseSpec listener={listener} />; instance = ReactTestUtils.renderIntoDocument(instance); expect(listener.mock.calls).toEqual([ ['MixinA didMount'], ['MixinBWithReverseSpec didMount'], ['MixinC didMount'], ['Component didMount'] ]); }); </ins> it('should validate prop types via mixins', function() { expect(TestComponent.type.propTypes).toBeDefined(); expect(TestComponent.type.propTypes.value)


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

var dest = 'build/npm-react/'; var modSrc = 'build/modules/'; var lib = dest + 'lib/'; <ins> var dist = dest + 'dist/'; var distFiles = [ 'react.js', 'react.min.js', 'JSXTransformer.js', 'react-with-addons.js', 'react-with-addons.min.js' ]; </ins> function buildRelease() { // delete build/react-core for fresh start

} }); <ins> // Make built source available inside npm package grunt.file.mkdir(dist); distFiles.forEach(function(file) { grunt.file.copy('build/' + file, dist + file); }); </ins> // modify build/react-core/package.json to set version ## var pkg = grunt.file.readJSON(dest + 'package.json'); pkg.version = grunt.config.data.pkg.version;

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


Question:
From : cc
Fixed.
Reopening because new docs don't have that info, and it is confusing. We should re-add it.
I am looking to make my first contribution and would like to fix this issue.
I also opened a PR for this on last week, restoring the original note. I notes for discussion on a more thorough example on the PR, like the current example has, but have not done much beyond that. Do we think that such an example would be beneficial? I almost think not, since the difference is just treating as an array with , but I'm curious to hear everyone else's thoughts on that.
There hasn't been any further discussion in PR or on this issue in the last two months, so is that PR all we need to do for this? cc
Sorry. We’ve been busy with a rewrite for React 16, and haven’t been actively reviewing the PRs.
Fixed in
No sweat, I figured as much. React 16 was absolutely worth it, great work!

``` To make an uncontrolled component, `defaultValue` is used instead. <ins> > Note: > > You can pass an array into the `value` attribute, allowing you to select multiple options in a `select` tag: `<select multiple={true} value={['B', 'C']}>`. </ins>


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

// `textContent` (unnecessary since we update value). // The initial value can be a boolean or object so that's why it's // forced to be a string. <del> initialValue: '' + (value != null ? value : defaultValue), value: defaultValue </del> <ins> initialValue: '' + (value != null ? value : defaultValue) </ins> }; },

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

); props.defaultValue = null; <del> props.value = value != null ? value : this.state.value; </del> <ins> props.value = null; </ins> props.onChange = this._handleChange; // Always set children to the same thing. In IE9, the selection range will

expect(node.value).toBe('foobar'); }); <ins> it('should not render value as an attribute', function() { var stub = <textarea value="giraffe" onChange={emptyFunction} />; stub = renderTextarea(stub); var node = stub.getDOMNode(); expect(node.getAttribute('value')).toBe(null); }); </ins> it('should display `value` of number 0', function() { var stub = <textarea value={0} />; stub = renderTextarea(stub);


Question:
It was reported to me on IRC today and confirmed on master / FF nightly myself. Also
I should add that when there are no errors in the jsx file the page still renders correctly, but the behavior persists (cannot load source file). Errors are reported from lines that do not exist in html file which makes bugs hard to track down. Confirmed on Windows 7 and Firefox 29. I can add more details once I get back to work on Monday - just let me know what information you need. Thanks, -Eric
What exactly is the issue? If it's just source lines being "off/out of bounds" then it's possible that it's the old JSX issue where source lines reported by esprima are mysteriously offset. AFAIK it was never explicitly solved, but no one was able to reproduce it anymore, perhaps it struck again? Other than that, JSX is just sugar on-top of esprima (and source-map I assume), and I think even the above issue is/was, so I don't think JSX is necessarily the root cause here.
Hi thanks for responding. At the most general level, the problem I am trying to solve is this: I want to be able to use the JSXTransformer script and be able to see a useful version of my compiled JS script which (pre-compilation) had JSX in it. I want to do this so that when I make an error in my JSX-containing JS script I can get a useful error message and hopefully see where the problem is in my original script (or get some clue as to where the problem might be). As it stands now, when I have an error in my script, the console just complains about lines which do not exist in my HTML file (which is only a few lines). So it'll say there's an error in line 65 of even though is only 15 lines. Compounding the problem is that, even when there were no errors and the JSX compiled perfectly to JS and the JS file ran just fine, I still cannot see any sources other than the JSX compiler, the reactjs source and my jquery source. I can't see either a uncompiled or compiled version of my JSX-containing JS file. Instead, what I see is this: Hopefully that explains everything, but let me know if you're still confused. I can provide more info when/if you need it. Thanks
When I tested last week I couldn't get the source map to do anything at all in Firefox.
Figured it out. I can't decide if it's a Firefox issue or something we're doing wrong, but is the problem. It seems when we pass URLs (eg "") here, Firefox chokes. If we pass a filename (eg "") the sourcemap is usable. So short term, I'm just going to pull off the actual filename and use that. Inline scripts don't appear to have been a problem (supporting my URL theory). cc from the Firefox devtools team, might be worth looking into on your end as well (can't remember if I filed that bug).
Can we keep the full path but drop the domain-part perhaps?
Good idea, I changed to doing that :)
would love a minimal test case. Can you repro with just mozilla/source-map, or only while using devtools?

var runScripts; var loadScripts; var headEl; <ins> var dummyAnchor; </ins> var buffer = require('buffer'); var transform = require('jstransform').transform;

if (inlineScriptCount > 1) { source += ' (' + inlineScriptCount + ')'; } <ins> } else if (dummyAnchor) { // Firefox has problems when the sourcemap source is a proper URL with a // protocol and hostname, so use the pathname. We could use just the // filename, but hopefully using the full path will prevent potential // issues where the same filename exists in multiple directories. dummyAnchor.href = source; source = dummyAnchor.pathname.substr(1); </ins> } map.sources = [source]; map.sourcesContent = [code]; return ( transformed.code + <del> '//# sourceMappingURL=data:application/json;base64,' + </del> <ins> 'n//# sourceMappingURL=data:application/json;base64,' + </ins> buffer.Buffer(JSON.stringify(map)).toString('base64') ); } else {

if (typeof window !== "undefined" && window !== null) { headEl = document.getElementsByTagName('head')[0]; <ins> dummyAnchor = document.createElement('a'); </ins> if (window.addEventListener) { window.addEventListener('DOMContentLoaded', runScripts, false);