

React v0.13.0 Beta 1 - antouank
http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html

======
danabramov
It's funny React gets bashed in this thread for pushing out createClass
crutch, mixins, autobinding into userland, when usually it is being modularity
shamed[0].

The change is subtle and easy to misinterpret. It's not that React drank ES6
class kool-aid and we're now gonna use inheritance over composition. (Nope[1],
in fact pretty much the opposite[2].)

The real change is that React.createClass is no longer _the_ way to create
components. It's just a fancy wrapper (which is not even being deprecated).
You want magic, you opt-in to it.

ES6 classes are also not _the_ way to create components. As mentioned at the
end of the article, you can even use ES3 module pattern:

    
    
        function MyComponent(initialProps) {
          return {
            state: { value: initialProps.initialValue },
            render: function() {
              return <span className={this.state.value} />
            }
          };
        }
    

React.createClass stops being special/required and becomes a (handy) utility.
Can potentially be moved into a separate package.

Competition for mixin systems is now possible.

Finally, this change opens up more possibilities for potential React-like
frameworks to “interpret” React components. Of course we don't do that today,
but it's still a nice property and may be handy later when you decide to
switch to future React-like competitor.

It's the anti-lock-in.

[0]: [http://jlongster.com/Modularity](http://jlongster.com/Modularity)

[1]:
[https://github.com/facebook/react/issues/613#issuecomment-29...](https://github.com/facebook/react/issues/613#issuecomment-29280175)

[2]: [https://github.com/reactjs/react-
future/blob/master/01%20-%2...](https://github.com/reactjs/react-
future/blob/master/01%20-%20Core/03%20-%20Stateless%20Functions.js)

~~~
tolmasky
Given the ES3 style creation if components (which appears to have no
"superclass"), can you also just do "class MyComponent" (no "extends
React.Component"?)

~~~
danabramov
I think so, but you'll probably miss `this.setState`.

They are moving out `setState` into a sideways module[1] so I assume full-
featured classes without React.Component should be possible in the future.

[1]:
[https://github.com/facebook/react/commit/ed7332c74921874cdcb...](https://github.com/facebook/react/commit/ed7332c74921874cdcb3cce629bb5bd8c95a7968)

~~~
danabramov
Indeed, it is not necessary to inherit form React.Component, see confirmation:

[https://github.com/facebook/react/pull/2975#issuecomment-729...](https://github.com/facebook/react/pull/2975#issuecomment-72962088)

------
skrebbel
Nice! I think that if you use vanilla JS (even ES6), the class support adds
more hassle than the gains it provides. For example, setting proptypes
completely at the bottom of the file seems, well, cumbersome. It's a bit like
putting a function signature after the function body. From that perspective,
using the old React.createClass syntax seems to keep everything together a bit
nicer.

However, if you want to use e.g. TypeScript with React, than this is a very
big thing! Up until now, it was always a bit of a hassle, and with this
change, it's completely straightforward (especially if you don't want JSX).
You'll also need propTypes less because you can just use TypeScript interfaces
for the `props` constructor parameter. Plus, TypeScript already has property
initializers and all that, so all the other annoyances that you get when doing
this with plain ES6 classes disappear with TypeScript.

I'm currently really considering porting my current project back to TypeScript
for this single reason. The bad mix of TypeScript and JSX is what mostly holds
me back. I'd like my view code to be somewhat understandable/hackable by
designers and JSX really matters there. Any suggestions?

~~~
JonnieCache
Similarly, I'm looking for a way to use react with HAML. I just can't give it
up, I have absolutely no interest in closing my tags ever again.

One of the things I like about angular is how it deals with standard HTML.
HAML doesn't care about its wacky attributes. Whats the best way to achieve
this with react? Does the JSX compiler have hooks for preprocessing of any
kind?

~~~
rattray
It wouldn't work with Typescript, but this is what my vanilla CoffeeScript
React code looks like:

    
    
        div
          className: 'navbar-form'
          style: 
            backgroundColor: "green"
          ,
          div
            className: 'btn-group'
            ,
            button
              type: 'button'
              className: 'btn btn-warning'
              onClick: @handleDecreaseWpmClick
              ,
              span
                className: 'glyphicon glyphicon-chevron-down'
            span
              className: 'btn btn-default disabled'
              ,
              "#{ @props.status.get('wpm') }"
              span
                className: 'hidden-xs'
                ,
                " wpm"
            button
              type: 'button'
              className: 'btn btn-warning'
              onClick: @handleIncreaseWpmClick
              ,
              span
                className: 'glyphicon glyphicon-chevron-up'
    

(For the curious, "wpm" is short for "words per minute" \- this is straight
out of my code for [http://splashreaderapp.com](http://splashreaderapp.com).
More code at
[http://github.com/rattrayalex/splashreaderapp](http://github.com/rattrayalex/splashreaderapp))

~~~
rapind
Pretty sure you can lose all of those single line "," and make it a bit nicer.

    
    
        div
          className: 'navbar-form'
          style: 
            backgroundColor: "green"
          div
            className: 'btn-group'
            button
              type: 'button'
              className: 'btn btn-warning'
              onClick: @handleDecreaseWpmClick
              span
                className: 'glyphicon glyphicon-chevron-down'
            span
              className: 'btn btn-default disabled'
              "#{ @props.status.get('wpm') }"
              span
                className: 'hidden-xs'
                " wpm"
            button
              type: 'button'
              className: 'btn btn-warning'
              onClick: @handleIncreaseWpmClick
              span
                className: 'glyphicon glyphicon-chevron-up'

------
davedx
I'm a bit scared of what will replace mixins.

I've worked with C++ code bases where inheritance went crazy, and also with
C++ code bases where composition via components was well supported and
somewhat enforced. I'd love to see ES building in some kind of default support
for composition with components if mixins are out.

See also how Unity3D does it:
[http://docs.unity3d.com/Manual/UsingComponents.html](http://docs.unity3d.com/Manual/UsingComponents.html)

I'm very happy to see JavaScript advancing, but I really hope we don't end up
falling into the same holes other OOP languages fell into and then had to
slowly educate and build themselves back out of again over the years. Frontend
seems to be very good at rediscovering the old-new.

~~~
toxicFork
Yeah it sounds like React's Components could be similar to Unity3D's
GameObjects and the replacement for mixins could be similar to Unity3D's
Components.

E.g. implementation: SubComponent (or something named better), a component can
add the subcomponents to itself on initialization, and the lifecycle events
can be similar to the Unity3D's SendMessage, i.e. similar to mixins. I think
it would work quite well!

You would need to get the child subcomponent specifically e.g. get the timer
subcomponent to create a timer, but as a bonus the subcomponent would not edit
the instance of the component, feels cleaner TBH. Also two subcomponents can
have the same this.field or this.property, or this.func without worrying about
whether it belongs to the Component, another mixin, or something else :D

------
danabramov
Shameless plug: I just updated React Hot Loader 1.1.3 to work with 0.13 Beta.

[https://github.com/gaearon/react-hot-
loader](https://github.com/gaearon/react-hot-loader)

------
antouank
Personally I don't see why I would go back to using classes. IMHO, classic OOP
doesn't fit to modern JS. I guess it's good to have the option though.

~~~
rattray
"Modern" JS simply didn't have classes, so classic OOP couldn't fit. People
still tried a million different hacky ways though (eg; `React.createClass`).
I'm disappointed with the implementation in this case (no mixins??) but the
idea of going to classes now that we finally can makes sense.

~~~
danabramov
>I'm disappointed with the implementation in this case (no mixins??)

The point is moving mixin handling to userland (and eventually some sort of
standard?), if I understand correctly. It's not really React's concern.

See also: Minimal API Surface Area
[http://www.youtube.com/watch?v=4anAwXYqLG8](http://www.youtube.com/watch?v=4anAwXYqLG8)

------
Confiks
About mixins: the blog post mentions that "In fact, several features to
support mixins were dropped from ES6 today." Does anyone know where these
features were proposed/discussed/rejected?

~~~
ilkkao
Must be ECMA standardization meeting that is ongoing (27-29 Jan) in San
Francisco. Haven't seen the meeting minutes yet though.

------
kuni-toko-tachi
Excited for the release, but disappointed in the embracing of OO programming
in Javascript. Object oriented programming is a poor way to express logic and
gets away from the beauty of languages like Javascript (and Perl) - functional
composition.

I deeply regret the day when all job postings for Javascript say "Looking for
an object-oriented Javascript developer", since like lemmings companies think
object-oriented programming is a good thing.

~~~
jowiar
All the React code I've written tends to be much more functional/declarative
in nature than OO. When writing web frontend code, there is the giant blob of
state known as the DOM that has to be dealt with in some way. More than
anything else, React allows you to treat the view as "create a function that
transforms data into DOM elements", handling the state diffs itself.

~~~
kuni-toko-tachi
When MVC is expressed as a composition of functions - whose purpose is data
transformation, it is an absurdly simple concept.

Only MVC described in object-oriented terms is "hard".

view(controller(model0,event0)) = representation

------
mrcwinn
I'm disappointed to see this prioritized over, say, a focus on reduced library
size or simply getting to a stable 1.0 release. I'm not sure how this moves
React forward, though I'm sure it's a "nice to have" for some people.

Still, perhaps we'll learn more about the roadmap and goals of the team at the
React conference this week.

~~~
andrewingram
1.0 implies API stability, so now is exactly the time they _should_ be
prioritising things that potentially change the API going forwards.

Also, is 40kb gzipped really something to lose sleep over? Especially when the
mere act of moving from old jQuery/Backbone soup to React reduces the size of
my real code by a far greater amount.

~~~
bambax
I don't know React, and use and love Backbone.

It's my (perhaps flawed) understanding that React deals only with the "view"
part of an app, and that you can use Backbone and React concurrently.

Could you elaborate on what you call "Backbone soup" and how React helps solve
this problem?

~~~
andrewingram
Our experience with Backbone, was that the majority of code in your models and
views is about keeping the two in sync. i.e. if a field on a model changes,
how to update the element that the view controls in the most efficient
possible way. We experimented with several methods of handling data-binding
(two-way at the time) for us, but weren't satisfied with any of them.

I was building a particularly complicated content editor with Backbone, and
was getting frustrated. So I spent the next morning learning React, then re-
implemented the whole thing that afternoon. All the complexities I was
grappling with disappeared. Obviously there were new challenges to replace the
old ones, but we've found it's much easier for someone to pick up work on a
React project than it ever was with Backbone.

To start with we were using Backbone models with React views, but now we just
use a flux implementation (Fluxxor), and don't bother with much else. Our
client-side JS stack is essentially React, Immutable, Fluxxor, superagent,
moment and mousetrap, with only the first three being core ingredients.

~~~
danabramov
This repeats my experience too. Backbone gets nasty too soon: nested entities,
pagination, invalidation, caching have to be ad-hoc ugly solutions because
Backbone is just too rigid where it better be flexible, and too flexible where
it should have been rigid.

We gradually moved from Backbone to React+Backbone, and finally to React+Flux.
It's been amazing since.

------
andrewingram
As an alternative to defining propTypes and defaultProps as shown in the
example, could I do something like this?

[https://gist.github.com/AndrewIngram/f0574f79fca8e13e201b](https://gist.github.com/AndrewIngram/f0574f79fca8e13e201b)

It's a similar pattern to how I got Backbone models and views converted to ES6
classes.

------
amelius
I'm actually looking for a system that allows me to write Javascript code in
the normal imperative way, and _automatically_ makes it reactive.

So, for example, calling a function f(a, b) is first done normally, and then,
when e.g. "b" changes value, the function f(a, b) is re-evaluated
incrementally. Note that this means that not simply f is invoked again, but
that f is recursively re-evaluated.

Anybody here aware of such a system?

I know there is research in this area ([1]). I would really like to use such a
system in Javascript.

[1] [http://www.umut-acar.org/publications-by-topic#TOC-Self-
Adju...](http://www.umut-acar.org/publications-by-topic#TOC-Self-Adjusting-
Computation)

~~~
laszlok
I think what you are looking for is called auto-lifting. That is,
automatically lifting functions into reactive streams.

While it sounds like an awesome idea, things get crazy really fast. It's hard
to explain briefly, but make it explicit and clear to the programmer which
things are reactive streams and which are simply values makes it much easier
to predict what the program is doing.

~~~
amelius
In my opinion, the current way of doing things with reactive mechanisms really
doesn't make it clear what the program is doing. There's lots of things
happening at the same time, and also glitches can occur (variables rapidly
changing after eachother), and also non-optimal efficiency (things being
recomputed unnecessarily).

If my program just gets re-evaluated in an optimal way (without any other
side-effects) then that would make my life much simpler.

The research I linked to already states that it can be done. So I was
wondering if there are any Javascript implementations yet out there.

~~~
seanmcdirmid
SAC is quite different from reactive programming in the sense that it is not,
well, reactive or interactive. SAC deals with incremental recomputation on
change, whereas most reactive programming systems out their don't support
incremental recomputation (maybe some DOM diffing and that's about it).

Check out Adapton though, which is trying to bridge the gap.

~~~
amelius
Very interesting! Thanks.

I just hope there will be a browser-implementation soon :)

------
potench
Looks like they removed autobinding. When I first saw React, I thought about
new JS developers maybe being led astray by React's magic handling of "this"
scope. So I'm glad they removed the magic. But, doesn't this break backwards
compatibility? Or does "createClass" keep autobinding while the new class
model loses it?

~~~
toxicFork
Yep, createClass keeps autobinding

------
danr4
Hmm. Feels like big changes too early. While it is more idiomatic, i can't see
any substantial gains here. Simply looks like more work to me until es7.
Especially binding each method manually, That shit's wack! And im actually
kinda scared to see OOP features being embraced so quickly. Hopefully a
changelog could ease my mind.

~~~
rpwverheij
I agree, I really don't like having to bind all the methods manually, and I'm
not sure I agree with the argument of causing confusion. Being used to having
to bind and finding out it's being done automatically in React is just a sweet
surprise. And besides, I'm sure we'll only see more and more automatic binding
in future projects?

~~~
DougBTX
Lambda expressions which capture "this" have replaced almost all the cases
when I'd use .bind in the past, the only time I've needed to do something like
that recently has been when attaching events to the window object which need
to be detached later - and come to think of it, writing a wrapper around that
which just returns an object with a .detach() method would remove that use-
case too.

Something like,

    
    
        this.handler = new Handler(window, "mouseup", () => this.whatever());
        
        // later...
        this.handler.detach();
    

YMMV though.

------
nuc
That coffeescript / JSX example from the blog post looks sooo sweet.

    
    
      render: ->
        div(onClick: @tick, 'Clicks: ', @state.count)
    

I couldn't find any transformers which support it. Is there anyone out there?

------
skratlo
Like classes matter. JS doesn't even have them, not in ES6, not in ES7. It's
all just sugar for prototypal inheritance, which has nothing to do with OOP. I
don't see any future for OOP in JS land. They'd be better off investing time
in reducing side-effects, and the enormous size the library sports.

~~~
danabramov
They're not investing in OOP in any way.

In fact, they're doing the opposite: deprecating proprietary pseudo-OOP
`React.createClass` helper and let people use whatever they fancy. This makes
it easier to write React components using idiomatic constructs from different
languages, whether it is TypeScript, ClojureScript, CoffeeScript, or whatever.
Also lets you use any mixin system, if you need it at all.

React's stance on inheritance:
[https://github.com/facebook/react/issues/613#issuecomment-29...](https://github.com/facebook/react/issues/613#issuecomment-29280175)

“Minimal API surface area”:
[http://www.youtube.com/watch?v=4anAwXYqLG8](http://www.youtube.com/watch?v=4anAwXYqLG8)

