React 0.14 Release Candidate

http://facebook.github.io/react/blog/2015/09/10/react-v0.14-rc1.html

by spicyj • 11 years ago

128 65 11 years ago

facebook.github.io

Scarbutt2• 11 years ago

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

spicyj11• 11 years ago

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.

draw_down• 11 years ago

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

edit: Derp, they're there already

Scarbutt2• 11 years ago

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

zpao3• 11 years ago

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.

KenanSulayman• 11 years ago

This versioning is pure crap.

spicyj11• 11 years ago

Can you help us understand why?

wyldfire3• 11 years ago

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.

SwellJoe• 11 years ago

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.

serverholic• 11 years ago

It's standard semver wtf?

mderazon• 11 years ago

Why don't react use semver?

bronson• 11 years ago

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

nickpresta• 11 years ago

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!

seivan2• 11 years ago

This also helps with Typescript that required

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

dustingetz4• 11 years ago

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• 11 years ago

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

kzhahou• 11 years ago

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.

btown• 11 years ago

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.

dustingetz4• 11 years ago

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.

k__2• 11 years ago

Are the return-parentheses needed?

The JSX gets converted to a simple function call.

zpao3• 11 years ago

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

wereHamster• 11 years ago

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.

dustingetz4• 11 years ago

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)

daveidol3• 11 years ago

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?

spicyj11• 11 years ago

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

daveidol3• 11 years ago

You guys are the best :)

seivan2• 11 years ago

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.

spicyj11• 11 years ago

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.

iamjs• 11 years ago

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.

tolmasky• 11 years ago

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__2• 11 years ago

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• 11 years ago

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

dustingetz4• 11 years ago

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.

wasd2• 11 years ago

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.

pluma6• 11 years ago

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.

spicyj11• 11 years ago

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.

wasd2• 11 years ago

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?

phaedryx• 11 years ago

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

Awesome.

pluma6• 11 years ago

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.

pluma6• 11 years ago

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

zpao3• 11 years ago

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.

technion• 11 years ago

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?

spicyj11• 11 years ago

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

React 0.14 Release Candidate

Related Stories