Use ES6 Classes to create React components.

Let’s use ES6 classes to create React component classes. We’ve accumulated some custom concepts that don’t lend themselves to using ES6 classes but we can still use them in conjunction with React components as ES6 classes, if the separation is performed as “enhancers” on top of completely pure ES6 classes:

class Typeahead extends ReactComponent {
   render() {

   }
 }

 // Enhancers
 ReactComponent
 ReactComponent.autoBindMethods(Typeahead);
 ReactComponent.validatePropTypes(Typeahead);
 ReactComponent.applyMixins([MixinOne, MixinTwo]);

 module.exports = Typeahead;

• Blockers:
  • Probably want to call the base class ReactComponent even though the base class of our components today is called ReactCompositeComponent. We just need to rename ReactCompositeComponent to ReactComponent and ReactComponent to ReactComponentBase.
  • Right now React.createClass doesn’t return the constructor. It returns the “convenience constructor” which can be invoked without new. We can unify the two concepts and eliminate convenience constructors altogether.
  • Determine how to support autobinding (likely an “enhancer” as shown above).
  • Get rid or (or figure out way to abstract out) special proprietary handling of overridden methods like componentWillMount, componentWillReceiveProps - there aren’t classical OO equivalents.
  • Of these proprietary handlers, some are for the purpose of validation (preventing people from overriding base class methods). Others add actual functionality. We can do whatever we have to to ensure validation, but the additional functionality should be factored out of the class hierarchy, into special “enhancers” as I’ve hinted at at the bottom of the previous example. It should be possible to program with pure, straight up ES6 classes.
  • The main challenge with our proprietary handlers is how we allow multiple mixins to redefine properties, and ReactCompositeComponent will attempt to intelligently merge their results. It is okay to factor all of that out into helper utilities, and we can supply a code mod that automatically updates your code that uses mixins.
• This is a huge undertaking. Before anyone takes a shot at this - please lock down the API. For ES6 related questions, run ideas by @jeffmo and @sebmarkbage who understand the direction of ES6. I’m happy to chat about the feasibility of potential changes to the React core, and practical ways to get started.
• This might require tiny changes to the JSX transformer - but I’m sure @jeffmo could get these done (or help) in minutes - they’re quite easy.

[jordwalke]

Just a heads up about some of the concerns regarding ES6 class support and how can can address them:

• Many people have become accustomed to using OO inheritance not just as a tool, but as the primary means of abstraction in their application. I’ve you’ve worked at a Java shop, you’ll know what I’m talking about. In my personal opinion, classical OO inheritance (as implemented in many popular languages) is not often the best tool for most jobs, let alone all jobs. But the situation should be approached with even more caution when inheritance is used within a framework or paradigm that uses functional composition as its primary abstraction (React). There are certain patterns we’ll want to prevent (there are many strange things that people can come up with when combining render with inheritance that don’t make sense and are addressed via simple composition). There’s also risk of making mutation more convenient. It might make sense to start with ES6 classes simply as a better syntax for React component creation, intentionally limiting some use cases (limiting inheritance depth, making some React base class methods final) (only when used with React components of course - all non-React use of ES6 classes wouldn’t be restricted).

[sebmarkbage]

@ericelliott Note that classic React factories created through createClass are just OOP classes like ES6 classes. They support the same kind of inheritance through mixins. In fact, because it also supports multi-inheritance it opens up even more pitfalls. In fact, mixins is unfortunately seen as the primary way to do abstractions.

ES6 classes in React is not adding anything you couldn’t already do. In fact it is constraining it further by encouraging object composition instead of mixins. It is an unfortunate marketing effect that this move is seen as encouraging OOP when it is really not.

My stance on progress in this space is that you can’t take things away from developers until you’ve taught them the alternatives… at scale. (That includes myself.)

The class system provides an optional escape hatch when you need it rather than completely stopping you.

The primary feature that our class system provides is an “instance” handle this has several features.

1. It provides a certain level of familiarity and convenience. You can use this as a middle man to refer to a group of arguments. This is a foot-gun but makes it easier to onboard new people.

2. The instance is an ID that you can use to refer to a place in the tree. It allows APIs like React.findDOMNode(component) and third-party APIs that can unify around it.

3. It provides single or multiple inheritance features if someone needs to create an abstraction and just can’t figure out how to do it using composition. This is unfortunately a very common problem.

If a developer can’t figure out a way to do it, we don’t want them to get stuck. Therefore, OOP is an escape hatch. At the same time we’re trying to teach and encourage composition of components and higher order functions/components instead of OOP. You can still implement that on top of the class systems that we have. Then, when this practice is common enough, we can start deprecating old class systems.

However, we make that progress by teaching and encouragement - not by force.

As a phase two of this, we can start introducing more pure models. See the alternatives that we’ve been working on to replace “instances” as an abstraction model:

https://github.com/reactjs/react-future/blob/master/01 - Core/03 - Stateless Functions.js https://github.com/reactjs/react-future/tree/master/07 - Returning State

As well as a declarative ways of updating state:

https://github.com/reactjs/react-future/tree/master/09 - Reduce State