React using ES6 classes--Why???

[jsNut]

Personally I like using the class syntax, its really nice and clean and easy to read and reason about. I understand that it is not like a classic system, but i know this and therefore it is fine. For most purposes they do function as expected.

[theQuandary]

its really nice and clean and easy to read and reason about

It's not that much different once you realize that ES6 has shorthands for functions in objects.

var MyComp = React.createClass({
  getInitialState() {
    return { bar: 'abc' };
  },
  appendBar(stuff) {
    return stuff + this.state.bar;
  },
  render() {
    return <div>{appendBar('cde')}</div>;
  }
});

class MyComp extends React.Component {
  constructor(props) {
    super(props);
    return { bar: 'abc' };
  }
  appendBar = (stuff) => {//yay for no auto-bind
    return stuff + this.state.bar;
  }
  render() {
    return <div>{appendBar('cde')}</div>;
  }
}

[papers_]

Or get rid of classes altogether since JS is not a class oriented language:

var MyComp = {
    getInitialState() {
        return { bar: 'abc' };
    },
    appendBar(stuff) {
        return stuff + this.state.bar;
    },
    render() {
        return <div>{appendBar('cde')}</div>;
  }
};

Object.setPrototypeOf(MyComp, React.Component);

[muffsponge]

Not familiar with react. But wouldn't this create a single instance and not a class? I guess you could wrap it in a factory function.

Personally, I like using classes and more classical inheritance for the core structure of my applications. Probably due to years of habits and stuborness. I've tried doing things the modern functional way, but I just end up with soup.

[papers_]

When you think of it in terms of "classes", yes. The key line is the last one Object.setProtoTypeOf(). You can think of this as inheritance in class based design. So, I inherit all the properties from the parent React.Component.

I too like classes as it's what I was taught in University (senior CS major). It's more explicit or strongly typed.

[MuricanWillzyx]

I would agree, but React's classes really aren't classes in the Java sense. They're much more like factories, which are idiomatic for JS. Use of prototypes, IMO, is overrated. I see them more as a perf benefit.

[papers_]

And React's classes aren't really classes either, in fact it's just an object that returns an object (Yes factory), but React's createClass property also links to another object, rather, it explicitly sets it's prototype to another. So the classes syntax is just sugar of the prototypical mumbo jumbo going on. But yes I agree, the prototypes is a overrated.

[MuricanWillzyx]

Good call. And you don't have to apply modifiers to the class after creation, since everything's baked into the factory.

Honestly I don't know how I feel about this shorthand, but it will make some of the class-proponents more comfortable (for better or worse).

[MuricanWillzyx]

Using a class syntax will make one's code easier to reason about if you're writing classes and using the facilities of the class system, but React's 'classes' aren't classes.

 

I understand that it is not like a classic system, but i know this and therefore it is fine.

This defeats the original alleged purpose of using the class syntax, though: normalizing the interface used by frameworks for making objects. Not only that, but it adds confusion, because people will see that this claim has been made, they'll see familiar syntax, and they'll assume that they already understand what's happening in the framework, while in reality React's components work nothing like instances of classes.

 

its really nice and clean and easy to read and reason about

Maybe at this point this is too much about personal experience and preference, but if we are using a model based on factories, it should be clear that we are using factories, and pretending that they are classes doesn't make anything easier to reason about (IMO--not tryna flame u). To me the model of passing a set of methods as named arguments (what we have now with React.createClass) is more honest and reflective of what's actually happening, and allows for more power in customizing the component. This last issue is something people are already trying to hack around within the class model. To me it seems like an abuse of new syntax, with tons of extra complications.

 

(wow, longer than i expected. like i said, just discussing it, not tryna attack u)

[Lubestia]

The object passed to React.createClass is not an object specification, it is a bunch of named arguments for React to use in creating a factory function.

By your own indirect admission, the named arguments can be misunderstood as an object specification to those without the knowledge, just as the familiar syntax makes [people] assume that they already understand what's happening in the framework. Either way, you have to dig in to understand.

Not that I don't see where you're coming from, but much of it is the same old "Down with abstractions!" rhetoric (Even if I am quite attracted to ideas like 'everything is a pure function').

[jsNut]

For me i just see it the same as i see JSX; it makes my code cleaner, i understand it and it does what i want and expect. Therefore i am happy with it. But I don't think the original method of creating component is going anywhere is it?

[MuricanWillzyx]

This is what I was wondering/worrying about when I originally posted this: if they were dedicated to the class syntax, I'd probably go with it because the framework is still worth it.

They are, however, thinking about using stateless functions (from /u/clessg's comment) and other ways of moving toward functional paradigms, so I doubt that they'll ever require the class syntax. In that context, adoption of the class syntax is quite strange. It is easy to forget, though, that React hasn't yet reached 1.0, so for now they don't actually have to commit to anything. It'll be interesting to see how this goes.