# React, Class Syntax, and Autobinding Shenanigans!

**URL:** <https://forum.kirupa.com/t/react-class-syntax-and-autobinding-shenanigans/637147>\
**Category:** Uncategorized\
**Created:** [September 9, 2017, 12:37am UTC](https://forum.kirupa.com/t/react-class-syntax-and-autobinding-shenanigans/637147 "2017-09-09T00:37:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kirupa](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/kirupa/32/11616_2.png) [@kirupa](https://forum.kirupa.com/u/kirupa)\
**Post date:** [September 9, 2017, 12:37am UTC](https://forum.kirupa.com/t/react-class-syntax-and-autobinding-shenanigans/637147/1 "2017-09-09T00:37:37Z")

</div>

One of the big things [the React team announced](https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html) as part of React 15.5 and React 16 is that the old `React.createClass` approach for creating components is no longer recommended:

```
var Foo = React.createClass({
  render: function() {
    return (
      <h1>Hello!</h1>
    );
  }
});

```

The approach instead is to use the class syntax:

```
class Foo extends React.Component {
   render() {
      return (
           <h1>Hello!</h1>
       );
   }
}

```

Overall, this change is fine! It’s time we all moved to use the class-based syntax anyway. There is one major annoyance, though. When using `createClass`, React autobinds function to the component. This allows you to access the component via `this.componentName`. With the class approach, you don’t get autobinding. You have to bind functions and other things you care about manually…like an animal!

Here is an example:

```
class LightningCounter extends React.Component {
    constructor(props) {
        super(props);
        
        this.state = {
            strikes: 0
        };
    }

    timerTick() {
        this.setState({
            strikes: this.state.strikes + 100
        });
    }

    componentDidMount() {
        setInterval(this.timerTick, 1000);
    }
    
    render() {
        return (
            <h1>{this.state.strikes}</h1>
        );
    }
}

class LightningCounterDisplay extends React.Component {
    render() {
        var divStyle = {
            width: 250,
            textAlign: "center",
            backgroundColor: "black",
            padding: 40,
            fontFamily: "sans-serif",
            color: "#999",
            borderRadius: 10
        };

        return(
            <div style={divStyle}>
                <LightningCounter/>
            </div>
        );
    }
}

ReactDOM.render(
    <LightningCounterDisplay/>,
    document.querySelector("#container")
);

```

This is the code behind the [Dealing with State](https://www.kirupa.com/react/dealing_with_state.htm) tutorial. When the code runs, in an ideal world, the `timerTick` function will get called and the code inside it will execute. Reality is that the `timerTick` function gets called. **The `this.state` and other things inside it have no idea what they are bound to. They will return undefined errors when you try to use them.**

There are two solutions that you can use that don’t require additional 3rd party libraries. One solution is where you explicitly bind `timerTick` in the constructor:

```
class LightningCounter extends React.Component {
    constructor(props) {
        super(props);
        
        this.state = {
            strikes: 0
        };

        this.timerTick = this.timerTick.bind(this);
    }
    .
    .
    .
}

```

One other solution, is to use arrow functions:

```
timerTick = () => {
    this.setState({
        strikes: this.state.strikes + 100
    });
}

```

Both of these approaches will get your code to work. The value of `this` will be bound properly and all the properties you try to access will resolve correctly.

If you want a more automated solution that relies on another library, then **react-autobind** might be up your alley: [https://www.npmjs.com/package/react-autobind](https://www.npmjs.com/package/react-autobind)

With all of this said, this is a step backwards compared to `React.createClass`. There are ways to handle this automatically as part of the React library. Or maybe there isn’t. Who knows 😛

Cheers,  
Kirupa

---

<div class="post-metadata">

**Author:** ![senocular](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/senocular/32/7217_2.png) [@senocular](https://forum.kirupa.com/u/senocular)\
**Post date:** [September 9, 2017, 12:16pm UTC](https://forum.kirupa.com/t/react-class-syntax-and-autobinding-shenanigans/637147/2 "2017-09-09T12:16:39Z")

</div>

> [@kirupa](#):
>
> There are ways to handle this automatically as part of the React library.

React.Component _could_ autobind in its constructor if they really wanted to. It’s probably better that they’re not doing this for performance, but it would be a way to make this concern go away.

I think ultimately, language-wise, the intention is that you’d to be able to bind or not using decorators:

```auto
@autobind
class LightningCounter extends React.Component {
    ...
}

```

or per method:

```auto
class LightningCounter extends React.Component {

    @autobind
    timerTick() {
        this.setState({
            strikes: this.state.strikes + 100
        });
    }
    ...
}

```

autobind itself I don’t think would be built into the language, but implementations exist out there already like [autobind-decorator - npm](https://www.npmjs.com/package/autobind-decorator)

Decorators are in stage 2 right now, so they might be a little while longer before being official, but TypeScript already implements them (and has for a while).

---

<div class="post-metadata">

**Author:** ![kirupa](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/kirupa/32/11616_2.png) [@kirupa](https://forum.kirupa.com/u/kirupa)\
**Post date:** [September 10, 2017, 4:31pm UTC](https://forum.kirupa.com/t/react-class-syntax-and-autobinding-shenanigans/637147/3 "2017-09-10T16:31:35Z")

</div>

My main preference for it being done automatically is that it reduces the amount of extra steps a developer needs to keep in mind when building an app. Autobinding feels like something everybody would want by default, and the extra work should be disable it if you don’t want.

I believe React did do autobinding early on when the ES6 syntax was gaining traction, but they moved away from that in later versions. The performance reason that you mention might be why.

😋

---

<div class="post-metadata">

**Author:** ![krilnon](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/krilnon/32/34_2.png) [@krilnon](https://forum.kirupa.com/u/krilnon)\
**Post date:** [September 14, 2017, 5:44am UTC](https://forum.kirupa.com/t/react-class-syntax-and-autobinding-shenanigans/637147/4 "2017-09-14T05:44:55Z")

</div>

ECMA TC39 could have chosen to go with bound class methods by default. They did in ES4, then reversed for ES6. React’s flip-flopping is a direct result.

`@autobind` is a bit of a bandaid; it should probably be called `@bind`/`@bound`. I think including `auto` in the name makes it sound like more work is being done than is actually being done.

> [@kirupa](#):
>
> My main preference for it being done automatically is that it reduces the amount of extra steps a developer needs to keep in mind when building an app.

I think this is a good argument for it to have been a language-level decision to bind methods. Historically, that didn’t make a lot of sense when ES6 was being standardized.

I think it’s a mistake that arrow functions bind differently than non-arrow functions. It’s odd to swap `=>` for `function` when I want to swap binding semantics; both are fine for single- and multi-line- functions in certain situations.