Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v0.12

facebook.github.io

Post reply on HN
Print view View original

51–60 of 79 posts

Re: React v0.12

#51

Post by spicyj »

simplify wrote: post #50

I'm disappointed that JSX is now so coupled to React. I was looking forward to JSX being used by many different JavaScript frameworks[1], but this change reveals the devs are not interested in moving that direction. [1] Example: https://github.com/mrsweaters/mithril-rails

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.

Re: React v0.12

#52

Post by sebmarkbage »

spicyj wrote: post #51
simplify wrote: post #50

I'm disappointed that JSX is now so coupled to React. I was looking forward to JSX being used by many different JavaScript frameworks[1], but this change reveals the devs are not interested in moving that direction. [1] Example: https://github.com/mrsweaters/mithril-rails

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.

Yea, note that mithril is on that list. The syntax was where people unified. There wasn't agreement on semantics and this is moving closer to that.

It's possible that this will eventually unify again. E.g. around a replacement for an object literal. E.g. a standard record type.

Re: React v0.12

#53

Post by sebmarkbage »

jaredgrippe wrote: post #48

One of my favorite patterns in React is using functions to wrap a React component. It goes something like this: App.Button = React.createClass({ render: function(){ var className = 'btn '+this.props.className {this.props.children} } }); App.BigButton = function(props){ props = props || {}; props.className = 'btn-large '+props.className return App.Button.apply(null, arguments) }; How would you do something like this?

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

Re: React v0.12

#54

Post by xiaoma »

Ouch. I've been building dynamic components using transferPropsTo(), which is now deprecated. It's very flexible and working well, so I'm a bit bummed to see it go.

  render: function() {
    // after building up some object, propsObj that is determined by state

    return this.transferPropsTo(
      Component(propsObj)
    );
  }

Re: React v0.12

#55

Post by simplify »

spicyj wrote: post #51
simplify wrote: post #50

I'm disappointed that JSX is now so coupled to React. I was looking forward to JSX being used by many different JavaScript frameworks[1], but this change reveals the devs are not interested in moving that direction. [1] Example: https://github.com/mrsweaters/mithril-rails

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.

A specification is great, and I'm happy to see that. However, even though it's true that transpilers can compile JSX with arbitrary semantics, it still requires writing your own transpiler.

JSX is a great syntax, and these changes mean nothing if you're a transpiler writer. What I was hoping for was the JSX transpiler that React uses would become flexible enough for any library to use, without the need to modify/rewrite the transpiler itself.

Yes it's possible for someone else to write something like this, but writing a compiler is no small feat =/

Re: React v0.12

#57

Post by lobster_johnson »

xiaoma wrote: post #54

Ouch. I've been building dynamic components using transferPropsTo(), which is now deprecated. It's very flexible and working well, so I'm a bit bummed to see it go. render: function() { // after building up some object, propsObj that is determined by state return this.transferPropsTo( Component(propsObj) ); }

No problem, just do this instead:

  render: function() {
    // Assign propsObj here

    return ;
  }

Re: React v0.12

#58

Post by lobster_johnson »

josebalius wrote: post #4

So are ES6 classes for components coming in 0.13?

You can use ES6 classes today:

    class Button {
      render() {
        return {this.props.label};
      }
    }

    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.

Re: React v0.12

#59

Post by LordHumungous »

jbhatab wrote: post #5

I don't know if I'm reading the changes wrong, but I'm not liking how I have to do an extra step if I don't use jsx. I want to use coffescript and not have to do extra stuff. I definitely feel this forced vibe around making everyone use jsx, but have yet to hear any compelling reasons why it's better.

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

Re: React v0.12

#60

Post by jbhatab »

sebmarkbage wrote: post #24
jbhatab wrote: post #22

Earlier quoted context omitted.

Thanks for the response. Could you give me a quick example of calling a component with object literals instead of functions? I'm not understanding how that will play out in the final code. Also, isn't it just adding React.createFactory, not replacing React.createClass?

In CoffeeScript it might look something like this: element = type: 'div' props: className: 'container', children: [ type: 'span', props: className: 'foo' type: CustomClass, props: className: 'bar' ] (This doesn't fully work in 0.12 because we also have some extra properties on there but that's the direction we're going.) 0.12 is just adding React.createFactory. 0.13 will optionally replace React.createClass. We do th…

Thanks for the answers.

I will say that I do really like the syntax of coffeescript as is though,

  div className: 'container',
    span className: 'foo'
    CustomClass classname: 'bar'
It reminds me a lot of slim and reads nicely.
Post reply on HN