React v0.12

Where did you see the increased difficulty if you weren't using JSX?

You don't need to do a separate step to use JSX. JSX is a still a superset of JS and you can still opt to not use it with no additional steps.

Hi, this was a tough call for us to make. We wanted to everything we could to avoid extra bloat for everyone. In the end, most people tend to use some kind of extra helper, even if it's not JSX. E.g. a custom library or another third party language.

One reason for this change is to make it possible to use object literals or record syntax where that is more appropriate than function calls. We don't currently recommend it because there's no validation in that case, so you probably want static analysis to catch errors. I would encourage you to play with the idea of using object literals instead of function calls though.

One compelling reason for this change is that in 0.13 you will be able to build components using plain CoffeeScript classes instead of relying on React.createClass. So, in the end, you will be getting some of that bloat/overhead back.

We're definitely not making React depend on JSX. We will continue to support non-JSX and fully support compile-to-JS languages. Unfortunately, that sometimes means a trade-off. In this case trading React.createClass for React.createFactory. Some would've preferred it be the opposite tradeoff but React.createFactory gives us more benefits than the opposite.

Big-R (the react framework I've been working on) eases this transition a bit. You can see[1] that components aren't accessed directly (unless of course you want to)

It still doesn't solve the stuff JSX has for splats though ...

[1]: https://gist.github.com/mikew/e737273e42ed704c6c54#file-zz-r...

Why not just use jsx though? It's almost always easier.

We do actually want JSX to be flexible and usable for not just React, which is why we're trying to write a formal specification of the syntax with multiple parser implementations:

http://facebook.github.io/jsx/

We intentionally don't specify semantics to give different transpilers the flexibility to compile the JSX into whatever's appropriate for the library you're using.

Use react-hyperscript [0] instead.

I'm not sure if it's yet been updated to support createFactory, but even if it doesn't you could create a simple higher order function the partially applies the static unchanging DOM parts, returning a function that takes the same data type as the function returned by createFactory.

IMHO, with createFactory, there is no longer a good justification for JSX. JSX basically solves a problem that JSX created. The reason people like JSX is that it takes the unchanging DOM structure (basically the virtual DOM equivalent of HTML templating) and puts it in HTML like templates do. This gives it a sufficiently different syntax, that it's easy to visually discern the changing parts from the unchanging parts, especially with syntax highlighting support. However, with createFactory, you have a way to wrap up all the unchanging structure, such that you don't have to constantly have to mentally parse the unchanging structure from the virtual DOM that render() is actually going to update. This means you still have to deal with React.DOM, but if you use react-hyperscript, the syntax is sufficiently simplified that it's comparable to HTML.

The complexity of JSX simply isn't worth it. It breaks too many tools.

[0] https://github.com/mlmorg/react-hyperscript

That sounds like a problem of pushing too much processing to the client side.

I think a real-world example might help to describe what you mean. Perhaps you could normalise the data in a way (on the server-side) that would remove the need for this setup?

Rest assured, see sebmarkbage's and my reply here:

https://news.ycombinator.com/item?id=8523732

https://news.ycombinator.com/item?id=8524465

Hey can you explain how they improved consistency because I just don't understand how the new changes help. I may just not understand what they did at a fundamental level.

No problem, just do this instead:

  render: function() {
    // Assign propsObj here

    return <Component {...propsObj}/>;
  }

See this post for a description of our terminology:

http://facebook.github.io/react/blog/2014/10/14/introducing-...

If I write

  var C = React.createClass(...);

  var e = <C />;
  var c = React.render(e, document.body);

then C is a class, e is an element (previously "descriptor"), and c is the actual mounted component. Components are generally accessible only through "this", refs, and the return value of React.render.

The suggested way of doing this is define a new component like so:

  var BigButton = React.createClass({
    render: function() {
      return (
        <Button
          {...this.props}
          className={'btn-large ' + this.props.className} />
      );
    }
  });

(Before React 0.12 introduced the JSX spread syntax, this was handled by transferPropsTo.)

This is actually an anti-pattern that we're explicitly trying to get rid of. The fewer components you have, the fewer optimization hooks you have. This also have subtle changes in semantics, and disables local optimizations in the consuming files.

The idea of a lightweight declaration of a component (e.g. a just function) is definitely still on the table and might be resurrected in a different form.

https://github.com/reactjs/react-future/blob/master/01%20-%2...

Maybe. We're still working on the details about what that will look like. Chances are we'll have some basic support if you're doing a limited set of things. Stay tuned.

You can use ES6 classes today:

    class Button {
      render() {
        return <button>{this.props.label}</button>;
      }
    }

    Button = React.createClass(Button.prototype);

Of course, it would have been nice to be able to skip that last line, and extend/mix in some React base class instead.

After looking into this I've come to the conclusion that rewriting the JavaScript to handle events through React's system is the best way to include Foundation's JS components. (This is something I'm planning to do with Foundation-for-Apps since I won't be using Angular).

That said, the styles are still usable without modification and you could tell React to not handle pieces of the DOM in some cases for the existing JS.

It doesn't update the underlying object for you by default.

If you use an uncontrolled component (by giving it a defaultValue/defaultChecked prop) you have to pick up the new value using an event or directly via the DOM. If you do it this way, you can't update the displayed value by changing the props passed to it.

If you use a controlled component (by giving it a value/checked prop), its displayed value won't update unless you pick up the new value from an event and set it in whichever JS object you have holding its state for the next render. There's a helper for doing that, or it's easy enough to roll your own event handler which takes care of all your fields.

http://facebook.github.io/react/docs/forms.html

Spread is like python's *args.

Instead of this:

  var mapArgs = function() {
    var args = Array.prototype.slice.call(arguments, 0, arguments.length - 1);
    var mapper = Array.prototype.slice.call(arguments, arguments.length - 1);
    return args.map(mapper);
  };

You can do this:

  var mapArgs = function(...args, mapper) {
    return args.map(mapper);
  };

And you can also use it to apply. Instead of:

  var max = Math.max.apply(null, [1, 2, 3, 4]);

You can do:

  var max = Math.max(...[1, 2, 3, 4]);

heydenberk explained it well, but just to add some clarity on why you'd want to use prototype.apply for array as an argument -

http://stackoverflow.com/questions/2856059/passing-an-array-...

http://stackoverflow.com/questions/1316371/converting-a-java...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I'm still learning more about JS and so I'm no expert, but it seems to be similar in concept to use the ... in other languages. I think Groovy has something similar and Java has the varargs. They have obvious differences, but conceptually I think of it as passing in a variable number of args.

Do you mean the fb.me link, or did you see one of the fbcdn.net links redirect? If you mean the fb.me link, that's Facebook's URL shortening service, so those will always redirect (as far as I know).

Mostly what @BinaryBullet said. fb.me is a urlshortener and then it hits real CDNed files. I (as maintainer of React) suggest not actually using fb.me urls in production. Use cdnjs or jsdelivr. Or host it yourself. We've been meaning to put together a proper CDN hosting setup for JS libraries but just haven't gotten around to it.

Their earlier blog post gives reasons for each of the API changes they made:

https://facebook.github.io/react/blog/2014/10/14/introducing...

We made these changes to try to make React better for everyone, but if you would like to continue using React 0.11, please do.