Functions are components! Yay! Here's the quote:

In idiomatic React code, most of the components you write will be stateless, simply composing other components. We’re introducing a new, simpler syntax for these components where you can take props as an argument and return the element you want to render:

    // Using an ES2015 (ES6) arrow function:
    var Aquarium = (props) => {
      return <Tank>{getFish(props.species)}</Tank>;
    };
    
    // Or with destructuring and an implicit return, simply:
    var Aquarium = ({species}) => (
      <Tank>{getFish(species)}</Tank>
    );
    
    // Then use: <Aquarium species="rainbowfish" />

That was possible with earlier versions of react, with slightly different syntax:

    {Aquarium({ species: "rainbowfish" })}

I've come across many projects which defined lots of small react classes, usually with a one or two line render body, which would be better served as simple functions.

Sort of, those functions aren't components, so they don't render async and don't have lifecycle methods or shouldComponentUpdate. (Also unclear if these new function components are actually components)

They are components in that they render later, but they don't support any lifecycle methods. We'll probably add some sort of "pure" flag via static properties on the function later.

Are the return-parentheses needed?

The JSX gets converted to a simple function call.

They're only needed if you don't start your JSX expression on the same line as the return.

(this is just in the chrome js console, not sure about other envs)

The automatic semicolon insertion doesn't seem as bad for arrow functions, this works as expected:

    () =>
          "this string is returned"

I'd personally keep using the parenthesis for aesthetic reasons though.

So in other words, Reagent? https://reagent-project.github.io/

There are always going to be similar ideas across different languages, frameworks, and platforms. Your comment implies... some sort of equivalence between React's announcement and Reagent? I'm not sure. Maybe you're saying "this has already been done before." If that was indeed your point, it would be more constructive to point out that here is an existing library with similar ideas that might prove useful to React developers.

Clojurescript is still incredibly daunting to programmers who have never known anything but C-like syntax... even though XML/JSX is practically s-expressions. So it's incredibly exciting that those types of patterns can be found in raw JS/JSX code.

Reagent is significantly more opinionated and eschews React state for a different state abstration. You're right though, Reagent does have functions-as-components, and you can attach lifecycle methods to functions-as-components.

I'm very excited about:

    React.Children.map now returns plain arrays too

Before this change, we would have to do the following when checking the types of children components (in propType validation):

    const childrenTypes = [];
    React.Children.forEach(props.children, child => {
      childrenTypes.push(child.type);
    });
    for (const type of childrenTypes) {
      if (type !== MyComponent) {
        return new Error(`Child '${type}' is not an instance MyComponent. Check render method of 'ParentComponent'.`);
      }
    }

It sort of made sense that map() on an opaque data structure would return the same type of data structure but in practice this was rarely useful.

Thanks, React team!

This also helps with Typescript that required

  var products:Array<Product> = []
    for (var x in this.props.products) {
      products.push(this.props.products[x])
    }

Stateless function components are definitely super exciting (we had been faking this with just Component(function() { return .. }). I'm interested how it handles shouldComponentUpdate though. We do some interesting things in there to deal with cursors, etc, so it would be nice to be able to get into the standard shouldComponentUpdate.

Yes. The function components are awesome.

I use Redux, where all the state tickles down through the props, so I can probably remove a huge chunk of boilerplate in my apps.

"I use Redux, where all the state tickles down through the props" Isn't that just flux, or even just good React practice?

It's good React practice, but it's not really Flux. A lot of Flux/Flux-inspired frameworks have components actively listen to global stores.

> so it would be nice to be able to get into the standard shouldComponentUpdate

Is there such thing? You at least need to choose between value and ref equality for various props?

Also not clear to me if these functions are turned into full React components with lifecycle methods and async rendering, or are just synchronously invoked in the same render stack frame as the closest up-stack actual React component.

I'm very excited about this release!

Question for other React devs out there: how long would you typically expect it to be before we can start migrating over?

Will older React components designed for 0.13 still work if they don't include the react-dom package?

Yes, they'll work with a warning until 0.15.

You guys are the best :)

I think most UI components (like material-react) will break because ref now returns the dom object and not a reference to the component, or something along those lines, correct me if I am wrong.

In this release, we do patch .getDOMNode() onto DOM nodes that are returned as refs so this should continue to work. File an issue if it doesn't. If your code has no warnings in 0.13, you should be able to upgrade immediately, with the exception of the two minor breaking changes mentioned at the end of the "Breaking changes" section.

So:

- a `ref` of your own component will be the component instance, complete with `getDOMNode`

- a `ref` of React.DOM will be the DOM node

Just seems weirdly confusing.

If I understand spicyj correctly, I think he's saying in v0.14 a ref of React.DOM will now be the raw DOM node; but it will also contain a getDOMNode method (which just returns itself) in order to continue working for people expecting the old behavior.

Refs to custom components will work exactly how they did in 0.13. And getDOMNode is deprecated in general (use React.findDOMNode instead).

That's right. In almost all cases you should just use a ref now and not call findDOMNode except as an upgrade path, because findDOMNode breaks encapsulation when used on other components.

Great work from the React team. I know the answer to my question is "when it's ready" but any thoughts as to when React might go 1.0.0? I've played around with it and like React a lot but I don't want to deploy until it's "version" stable. Happy to hear time (2016 summer) or version (after 0.20.0) estimates.

For a while, we were aiming for a "1.0" release. Lately, we've been more of the opinion that React will probably continue to evolve over time. We'll probably skip over the dot sometime (e.g., 0.14 -> 15.0) to help reflect that we do recognize these current versions as more or less stable.

The other opportunity is to just call some version 1.0 and then wait some amount of time (a year? two? five?) before making any breaking changes, which sounds less appealing to us. You can always continue to use an older version (and we'll backport serious fixes like we did in http://facebook.github.io/react/blog/2013/12/18/react-v0.5.2...) but we plan to continue developing React and hope that people will continue upgrading to new versions.

If you're concerned about whether it's production-ready (as opposed to future API changes), the answer is definitely yes.

Thanks for responding. I'm happily using React in my personal life but we don't use it at work (for no reason than we don't need SPA). One last question, is there an official policy as to how long will you support a release?

Facebook and Instagram are dogfooding it in production for their namesake projects. I'd say it's about as "ready" as node.js was before io.js bumped its major.

I've been using 0.13 in production for half a year with no problems.

> React uses console.error instead of console.warn for warnings so that browsers show a full stack trace in the console. (Our warnings appear when you use patterns that will break in future releases and for code that is likely to behave unexpectedly, so we do consider our warnings to be “must-fix” errors.)

Out of all the release notes this is probably the one that I'm the most excited about. Hopefully this sheds some light on the more confusing warnings (e.g. warnings about missing keys with no real way to determine where they are missing).

Another way, which we actually supported in 0.13, was to turn on "pause on caught exceptions" in your debugger. We throw and catch a warning so that you could catch warnings live. We continue to do that now, just with the added benefit of having the stack trace showing up without needing to pause.

I really appreciate the focus on adding more helpful warnings to help inform you when you're unknowingly about to shoot yourself in the foot.

What does react use typescript and coffescript for? they are listed as a dep in package.json

We just test that their class systems work properly with React:

https://github.com/facebook/react/tree/v0.14.0-rc1/src/isomo...

We don't use either one outside of the tests.

I think that means you can move them to the `devDependencies`.

edit: Derp, they're there already

They already are in devDependencies.

Is it the same case for babel? re: ReactES6Class-test.js

Yes, though we use Babel to compile all of our JS source code and tests.

Will you end up testing a Babelified es6 class and a "native" es6 class, or will you keep testing just the Babelified version for now?

Probably the latter, though we might add a native one too after we run our tests using a version of Node that supports classes.

FWIW, https://github.com/facebook/react/blob/master/package.json is not actually the package.json we ship to npm. This is just for building. https://github.com/facebook/react/blob/master/packages/react... is the package.json we ship to npm.

>React now supports two compiler optimizations that can be enabled in Babel 5.8.23 and newer. Both of these transforms should be enabled only in production (

Am I missing something about how you tell Babel to enable/disable these?

Enable them like you would enable or disable any other babel transformer, using the "optional" param in .babelrc (or --optional on the command line, etc).

Looks like we're almost to the point where we can say "universal" instead of "isomorphic".

Awesome.

I prefer "unimorphic" or "isoversal" at this point.

"Universal" has its own share of problems. I'm not sure switching from one wrong and confusing term to another is worth the effort.

I think the "0" in 0.14 indicates things are always gonna break. Semantic versions don't work when every new release has breaking changes.

I'm assuming that's what you're complaining about? I don't know what the React developers are thinking, of course, but I know that whenever I've released something with a 0.x version, it means "this is not stable yet, expect breaking changes". And, if that's a problem for people, they should wait until a 1.x release.

Can you help us understand why?

I speculate that it's because it's not treated like a Real number, where values increase like [0.1, 0.2, 0.25, 0.27, 0.29, 0.30].

React 0.14 supercedes 0.13 but it is not superceded by 0.9.

It's not a decimal number. It's a version number. If you add the implicit .0 back to the end of 0.14, it is easier to see. 0.14.0 is obviously not a decimal number.

14 > 13 > 9

Yeah, FWIW it's not a new problem and I'm not confused by this in general but I don't prefer it.

But I think we can all take a step back and see the ambiguity right?

Is it really that unreasonable to say that the ambiguity is long gone when version numbers now commonly contain several points and often letters and dashes and what not?

Why developers can't understand that not all uses of numeric digits are meant to behave like numbers?

Time, as in 00:12 is not a number either, it wraps around in 11:59 (or 23:59 in 24 hour mode)

14 > 13 > 9

"Math is pure crap"?

Well, fwiw, 0.9 > 0.14 > 0.13. Guess it depends on how you look at it.

The "." in versions is not a decimal point. There's certainly no such number as 0.9.1.

I know. Which is why I said that it depends on how you look at it.

I guess this causes less brainhurt when your native language uses a different decimal separator.

If you sort lexographically or treat those as decimals, it becomes 14, 13, and 90.

This is a flawed interpretation, but perhaps what wyldfire was trying to demonstrate.

As other posters indicate it's not that simple IMO. Then again, we are off on a bit of a tangent -- just my guess, not KenanSulayman's actual reasoning.

I find this mechanism of versioning mildly irritating (but I wouldn't call it 'crap'). I recognize that it's popular and I just suss the convention from the history.

It's standard semver wtf?

It does: https://github.com/facebook/react/blob/master/package.json#L...

Kinda. The semantics of 0.x versions pretty much boil down to "shift everything one to the left", i.e. 0.14 is a breaking change from 0.13, 0.13.1 may introduce non-breaking changes (other than bugfixes) from 0.13.0.

Considering both Facebook and Instagram (as well as a ton of other companies like Netflix) already use it in production for flagship projects, it really should be beyond 0.x land at this point (same argument that applied to node.js, basically).

I guess they just don't want to appear more unstable than AngularJS (which doesn't use semver semantics and thus introduces breaking changes in "minor" releases and thus can get away with calling the upcoming rewrite "2.0").