Pros and Cons of react-native Component versus React.createClass to implement UI components?

Question

What are the advantages of one versus the other?

Is one being deprecated and I should be using the newer one whichever that may be?

Should I be creating Components or React Class to develop my UI?

I see some examples using Component. For example:

export default class ItemList extends Component {
  constructor(props) {

  //binding functions
  this.renderHeader = this.renderHeader.bind(this);
  this.renderRow = this.renderRow.bind(this);

    super(props);
    this.state = {
      dataSource: this.props.state.planDataSource,
      planName: null
    }
}

And others using

var ItemList = React.createClass({

  getInitialState: function() {
    return {
      dataSource: this.props.state.planDataSource,
      planName: null
    };
  },

I am learning react-native by example and I am confused as to which is preferred.

I recently converted a React class to a component and discovered that the "this" pointer does not work because React classes used autobinding and Components require explicit binding.

Answer 1

Unless you're using mixins, always use class (read ES6) instead of React.createClass. Most of the react-native code are in ES6, so it helps to stay up to date with the current standards.

There is no difference regarding performance/UI. class (ES6) is a better way of writing react/react-native/JS code anyways. FWIW: http://es6-features.org/.

Answer 2

You should prefer Class over createClass because it will probably be deprecated.

The most notable new feature is support for ES6 classes, which allows developers to have more flexibility when writing components. Our eventual goal is for ES6 classes to replace React.createClass completely, but until we have a replacement for current mixin use cases and support for class property initializers in the language, we don't plan to deprecate React.createClass.

https://facebook.github.io/react/blog/2015/03/10/react-v0.13.html

No Autobinding

Methods follow the same semantics as regular ES6 classes, meaning that they don't automatically bind this to the instance. You'll have to explicitly use .bind(this) or arrow functions =>.

No Mixins

Unfortunately ES6 launched without any mixin support. Therefore, there is no support for mixins when you use React with ES6 classes. Instead, we're working on making it easier to support such use cases without resorting to mixins.

https://facebook.github.io/react/docs/reusable-components.html

Answer 3

As I saw in you comment, you're looking for an answer in simple words:

When looking at the example you provide in your question, you might be thinking "Oh my, why should I use this more verbose version with extends Component if it basically does the same as createClass?"

Well, the syntax using extends Component is the modern way of writing React Native UI Components and Javascript code in general. You should stick to this all the time unless you need a special feature called mixins because using the createClass way of writing components might soon be deprecated in React Native as pointed out by the other answers.

This modern version of Javascript is called ECMAScript 6 (with its compiler called babel which translates the new Javascript syntax into the old one so that that the current browsers can all understand it). It introduced this new more object-oriented way of writing Javascript with classes.

The naming in React is quite confusing when starting to transition to the new JS syntax, because the old syntax with createClass actually is not part of the new object-oriented syntax with classes, methods and such. This article nicely contrasts the differences between the two syntax styles you asked about in your question.

---

As an additional tipp, you don't have to bind this to your functions (e.g. this.renderHeader = this.renderHeader.bind(this); in your example if you define your custom functions by using another feature of ECMAScript 6 called arrow functions. This immediately deletes two more lines of code from your example and the two approaches require roughly the same amount of typing.