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

31–40 of 79 posts

Re: React v0.12

#31

Post by johne20 »

zpao wrote: post #15
johne20 wrote: post #2

off topic a bit, but why do the CDN urls 301 redirect?

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.

Ok, thanks. That is what I am actually doing now (host it yourself). It might be nice to mention that in the documentation/article that those links shouldn't not be used on production. Currently it is definitely not the messaging that comes across. eg. "Minified build for production: http://fb.me/react-0.12.0.min.js"

Re: React v0.12

#32

Post by ssorallen »

fiatjaf wrote: post #29

I really don't see the point of making so much breaking changes just to simplify the public API. The thing was working, it was good. It didn't need any changes. God would have rested. But well, the developers were there and, you know, they cannot see a repository without commits for much time, right?

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

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

Re: React v0.12

#33

Post by hardwaresofton »

jbhatab wrote: post #18
hardwaresofton wrote: post #7

As a person who is using react, this is a welcome change! I'm glad they're taking time to get rid of the kludgy code that wasn't quite consistent.

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.

IMHO it's more consistent because the things that react has been modifying have been Elements all along (DOM Elements).

React called them components, and it's always felt like a kludge to create some thing that WAS a DOM element (boiling down to React.DOM), and then set it's "tagname" as an after-thought.

Things like prop are tied directly to the DOM Element, further suggesting that the "thing" the component was, was actually a DOM Element.

I guess it's really subjective, but I think it'll be clearer to explain to people now:

"React manages creation and rendering of dynamic/intelligent (DOM) Elements"

(bonus points for no overlap with the Web Components terminology)

But then again a lot of this is just my opinion, consistency

Re: React v0.12

#34

Post by bostonvaulter2 »

I've been looking into React.js recently and I have a general question. Is it possible to use React.js with zurb foundation cleanly? It appears that it will not work well because Foundation expects to modify the state of the DOM for Foundation elements. Are there any workarounds?

Re: React v0.12

#36

Post by chenglou »

jbhatab wrote: post #17
hardwaresofton wrote: post #8

Earlier quoted context omitted.

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

As the others have stated, react requires me to add this line: var MyComponent = React.createFactory(require('MyComponent')); It's not a huge deal, but I keep getting this sense that jsx is strongly tied to react and this reaffirms that they are going to keep it that way. I do trust the react team still, but it makes me weary of future releases.

(I'll re-link to sebmarkbage's answer here in case people see this post and get confused: https://news.ycombinator.com/item?id=8523876)

In short, this is somewhat of a transition step for the (imo) even better way of specifying your render with pure vanilla js collections. This goes in the opposite direction of what you're worried about. You can view `createElement/Factory` as the stepping stone, with the _additional_ benefit of allowing you to use es6 classes very soon. Smaller API surface and + using more js features rather than library-specific ones; what's not to like? =)

As for your worries about JSX: yes, it does come from React since the beginning. But we've taken an extra step of making it clear that this doesn't have to be React-specific: http://facebook.github.io/jsx/. You can plug this in CoffeeScript. If not, see my previous point.

Re: React v0.12

#38

Post by jaredgrippe »

chenglou wrote: post #37
jaredgrippe wrote: post #35

I have a huge problem with this change explained here: https://gist.github.com/deadlyicon/da8c020662ea8e6002dc

Rest assured, see sebmarkbage's and my reply here: https://news.ycombinator.com/item?id=8523732 https://news.ycombinator.com/item?id=8524465

The object literal syntax also sucks :(

https://gist.github.com/deadlyicon/79c09610cac5a67f4a5d

Re: React v0.12

#39

Post by spicyj »

fiatjaf wrote: post #28

I don't get the React.isValidComponent -> React.isValidElement change. Wasn't "class" the name of the abstract idea of component and "component" the name of the actually rendered component, the class materialized in a DOM?

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

Re: React v0.12

#40

Post by spicyj »

fiatjaf wrote: post #29

I really don't see the point of making so much breaking changes just to simplify the public API. The thing was working, it was good. It didn't need any changes. God would have rested. But well, the developers were there and, you know, they cannot see a repository without commits for much time, right?

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.
Post reply on HN