
React 0.14 Release Candidate - spicyj
http://facebook.github.io/react/blog/2015/09/10/react-v0.14-rc1.html
======
dustingetz
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" />

~~~
jarcane
So in other words, Reagent? [https://reagent-
project.github.io/](https://reagent-project.github.io/)

~~~
kzhahou
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.

------
nickpresta
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!

~~~
seivan
This also helps with Typescript that required

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

------
tolmasky
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.

~~~
k__
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.

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

~~~
pluma
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.

------
daveidol
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?

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

~~~
daveidol
You guys are the best :)

------
wasd
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.

~~~
spicyj
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...](http://facebook.github.io/react/blog/2013/12/18/react-v0.5.2-v0.4.2.html))
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.

~~~
wasd
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?

------
pluma
> 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).

~~~
zpao
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.

------
iamjs
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.

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

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

[https://github.com/facebook/react/tree/v0.14.0-rc1/src/isomo...](https://github.com/facebook/react/tree/v0.14.0-rc1/src/isomorphic/modern/class/__tests__)

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

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

edit: Derp, they're there already

~~~
spicyj
They already are in devDependencies.

------
technion
>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?

~~~
spicyj
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).

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

Awesome.

~~~
pluma
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.

------
KenanSulayman
This versioning is pure crap.

~~~
spicyj
Can you help us understand why?

~~~
wyldfire
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.

~~~
scrollaway
14 > 13 > 9

"Math is pure crap"?

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

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

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

