

React v0.13 released - tilt
http://facebook.github.io/react/blog/2015/03/10/react-v0.13.html

======
dmnd
I'm looking forward to deleting all the annoying `.toJS()` conversions
everywhere I've used an immutable-js collection rather than a js array. (PR:
[https://github.com/facebook/react/pull/2376](https://github.com/facebook/react/pull/2376))

~~~
donw
Oh god, this. Using Immutable (via Immstruct) has been _glorious_ , but this
has been a minor annoyance that I'll be glad to be rid of.

Now all I need to do is sort out some issues with dispatch and I'm good to
go...

~~~
amccloud
Does Immstruct use Immutable's cursors? If so, you'll still need to use
.toArray() when dealing with a cursor to an array. React doesn't like what you
get after mapping over an IndexedCursor.

~~~
donw
It does, but you can just .deref()

~~~
amccloud
I'm usually looping over cursors I want to pass as a prop to a child
component. Deref-ing there would sorta defeat the purpose of cursors.

~~~
donw
Ah, fair enough. I usually deref before handing the data off to the rendering
chain, on the basis that future updates will just kick off another render
loop.

------
donw
I'm curious to see how mixins play out with ES6. While something similar to
'include' in Ruby would be nice, I've got a hard time seeing how that would
fly with multiple invocations of getInitialState, for example.

Of course, the big thing we're all waiting for is Native. If that truly offers
a bridge, rather than a wrapper, to native APIs from Javascript, then it will
be a game-changer.

~~~
spicyj
Most cases of mixins (especially ones that involve state, as you allude to)
can be implemented via composition by creating wrapper components instead.
This is how Relay
([http://facebook.github.io/react/blog/2015/02/20/introducing-...](http://facebook.github.io/react/blog/2015/02/20/introducing-
relay-and-graphql.html)) works and makes different components more contained
and easier to reason about. Here's one description of how to develop
containers (really, higher-order components) from someone who works on Relay:

[https://github.com/ericclemmons/react-
resolver/issues/8#issu...](https://github.com/ericclemmons/react-
resolver/issues/8#issuecomment-77765843)

(We know people are excited about React Native and we're working hard to get
it out the door – keep your eyes peeled!)

------
jbergens
The ES6 class system seems to be done to feel more like java and c# without
regard for the mixin/prototype parts. I'm glad React still works with mixins.
(edit spelling and clarification)

~~~
stupidcar
The ES6 class system is literally just syntactic sugar for prototypal
inheritance.

~~~
TazeTSchnitzel
No, it's syntactic sugar for one particular approach to using prototypical
inheritance that resembles "traditional" OOP.

~~~
Touche
Can you explain? It's sugar for this very common pattern:

    
    
        function Bar() {
          Foo.call(this);
        }
    
        Bar.prototype = Object.create(Foo.prototype);
        Bar.prototype.constructor = Bar;
    
        Foo.prototype.thing = function() { ....
    
    

What other "approach" to prototypical inheritance is there in JavaScript? The
module pattern doesn't use prototypes.

~~~
backslash_16
Is there a good book or website to learn about prototypical inheritance? I've
read a lot of Crockford's book and some stuff online about it, but I've never
run across the pattern you use above.

It would be great to know what the benefits are vs declaring function literals
on an object, or declaring a function directly on Bar's prototype.

~~~
cstrahan
Mozilla's documentation does a good job explaining prototypal inheritance:

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Inhe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain)

------
zellyn
Sadly, the much-discussed explosive second half of the PATENTS file is still
present:
[https://github.com/facebook/react/blob/91b45641b8bfbdecace94...](https://github.com/facebook/react/blob/91b45641b8bfbdecace941125a7a415aad1ebbce/PATENTS)

~~~
olov
"much-discussed" by "less-informed" I'd say.

There is nothing sad about React PATENTS file.

1\. React source code is licensed under the Modified BSD license.

2\. React also comes with a conditional patent grant. Here "conditional" means
that the _patent_ grant may terminate under some conditions. It does not
terminate 1.

Most BSD and MIT-licensed software you use comes without a patent grant at
all.

Still sad?

~~~
zellyn
[https://news.ycombinator.com/item?id=9113515](https://news.ycombinator.com/item?id=9113515)

~~~
olov
Thanks - I somehow managed not to look at that (saw it now after Twitter
feedback). I can't edit my earlier comments so I'll just amend here instead:
There are open source lawyers who consider simple permissive licenses such as
Modified BSD and MIT to have an implicit patent grant. The first public
discussion I found on this after a quick search is at
[http://lwn.net/Articles/389016/](http://lwn.net/Articles/389016/) \- would
love to see more and earlier.

If you the licensee also consider Modified BSD to have an implicit patent
grant then the React patent grant is much worse for you than if it hadn't
existed.

Guess I'm less less-informed now.

------
the_mitsuhiko
I wonder why they released it without some support for mixins. Right now you
might start with a ES6 class and then you need to go back to the old class
system if you want the mixins because of a reusable component you use.

~~~
spicyj
It's true that ES6 classes don't cover all existing use cases yet, which is
why I specifically mentioned in the blog post that we're continuing to support
React.createClass fully. The main Facebook site is still using
React.createClass everywhere, though we are starting to use ES6 class
components for some smaller projects here.

As I mentioned in another comment on this thread, many mixins can be
implemented as higher-order components that we call "containers". Many others
relate to data fetching, so we're looking at adding first-class support for
data subscriptions which can replace even more uses of mixins. (And in my
experience, it's rare to add mixins to a component after it's written.)

ES6 classes aren't suitable for everyone yet ("Ask your doctor if ES6
classes…") but they're a new API which is more convenient for some use cases,
so we chose to add it now instead of waiting until we're at perfect feature
parity to give people the chance to use the new syntax.

~~~
the_mitsuhiko
The thing is that I would like to use ES6 classes. There are some situations
where it just feels so bad to do "if (this.doFoo !== undefined) {
this.doFoo(); }" because you can't really define empty interfaces in mixins.

Subclassing would help a ton here.

------
modeless
Any news about React Native?

------
ariabuckles
I'm really excited for `React.cloneElement` and inlining of
`React.createElement`! `React.cloneElement` makes a bunch of tricks that used
to require hacks much cleaner, and finally promotes cloneWithProps to non-
addon API and removes the confusing magic. And if `React.cloneElement` starts
getting compiled into object literals it's going to speed up large render
calls significantly, and make the overall React API feel a bit simpler (to
me).

------
tehpwn69
Wonderful. I love the new ES6 syntax. To continue the discussion of mixins,
the 0.13 beta announcement mentioned there are ways to roll own your mixins
but can anyone offer examples of how to accomplish this?

------
ponytech
Any idea why React.addons.classSet is now deprecated? It was really helpful.

~~~
ykka
Not sure but it's very easy to implement it yourself... Check this
[https://github.com/facebook/react/blob/2aeb8a2a6beb00617a421...](https://github.com/facebook/react/blob/2aeb8a2a6beb00617a4217f7f8284924fa2ad819/src/utils/joinClasses.js)

But I also miss it, yeah, very useful addon.

------
jsprogrammer
Why is the second paragraph a shout-out backhand compliment to Ember and
Angular?

~~~
Bahamut
How is it a backhanded compliment? The React team is obviously proud of their
work, and used it as a point of reference that they believe they can do better
than what is there now too.

~~~
catshirt
the compliment is that the other frameworks are improving their rendering
speeds. the backhanded part is it implies they're slow.

~~~
flooq
They're just acknowledging that everything is moving forwards, I imagine that
they're pleased to have influenced the other frameworks. Ember in particular
seem to have learned a lot from React and are adopting a virtual-DOM approach
to rendering.

~~~
catshirt
sure, the same way i can "just acknowledge" that my friend is losing weight
but _is still fatter than me_.

it's a backhanded compliment.

