In new React ES6 classes this needs to be binded as stated here: http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html#autobinding
for eg:
class Counter extends React.Component {
constructor() {
super();
this.tick = this.tick.bind(this);
}
tick() {
...
}
...
}
The explanation for this is because it's the default behaviour, however if I make an ES6 class and then I make a new instance of it this will be binded
import React from 'React'
class Test extends React.Component {
constructor() {
super()
}
foo () {
console.log('bar')
}
hello() {
this.foo()
}
}
var test = new Test()
test.hello()
// > bar
Why binding is needed in React then?
You need set this to methods in case, for example, if you need pass function reference to event handlers, however you don't need set this for every method.,
class Counter extends React.Component {
constructor() {
super();
this.tick = this.tick.bind(this);
}
tick() {
// this refers to Counter
}
fn() {
// this refers to Counter
}
withoutBind() {
// this will be undefined or window it depends if you use "strict mode" or not
}
render() {
this.fn(); // this inside this method refers to Counter
// but if you will do like this
const fn = this.fn;
fn(); // this will refer to global scope
return <div>
<button onClick={this.tick}>1</button>
<button onClick={this.withoutBind}>2</button>
</div>;
}
}
Example
Classes in ES6 are functions. When you instantiate a class, you get an object. For all the methods in your class, if you used this inside them, it refers to the object that owns the method.
But it is confusing when you extract the method because the context changes. Examples:
let foo = Counter()
foo.tick()
If you call foo.tick(), this belongs to the object foo. Cool.
But watch this:
tickFunc = foo.tick()
tickFunc()
You detached the function from the original object, now the function invocation happens where this inside tickFunc() refers to the global object.
So why do you need to bind your methods in React? You do it because most of the times we are passing the method references either to the event handlers or as props to components. When you pass references of your methods, they become detached functions and their context changes. To solve that, you use bind() in the constructor.
Related
I'm currently studying Javascript and saw that we can define members of an object in its prototype instead of in the object's constructor since it makes the objects lighter because they don't carry the method code in every instance.
I can see how variables can work badly if all objects of this constructor point to the same variable field, but methods shouldn't change too much or at all, so its not a problem to share them.
Is there a reason not to define methods on the prototype rather than the object's constructor?
One reason why one might prefer putting methods on the instance itself would be to ensure the correct this context while adding a method concisely. Getting this to work properly is a very common problem in JavaScript.
For example:
class Foo {
i = 0;
clickHandler = () => console.log(this.i++);
}
const f = new Foo();
window.onclick = f.clickHandler;
This is a common pattern with class components in React. If one put the method on the prototype instead, it could sometimes get a bit uglier:
class Foo {
i = 0;
clickHandler() {
console.log(this.i++);
}
}
const f = new Foo();
window.onclick = () => f.clickHandler();
Another common way of dealing with this is to move a bound method from the prototype to the instance in the constructor:
class Foo {
i = 0;
constructor() {
this.clickHandler = this.clickHandler.bind(this);
}
clickHandler() {
console.log(this.i++);
}
}
const f = new Foo();
window.onclick = () => f.clickHandler();
Is that reason to prefer one over the other? That's up to you, but its one arguable advantage to keep in mind.
Just an idea from me - there is a way of dealing with the "proper" execution context of e.g. click handlers on prototype level as well. Consider the following example:
class AbstractClickHandler {
// the "proper" this is ensured via closure over the actual implementation
clickHandler() {
return (...args) => {
this.handleClick.apply(this, args)
}
}
// no-op in base class
handleClick() {
}
}
class ClickHandler extends AbstractClickHandler {
constructor(data) {
super()
this.data = data
}
// actual implementation of the handler logic
handleClick(arg1, arg2) {
console.log(`Click handled with data ${this.data} and arguments ${arg1}, ${arg2}`)
}
}
const instance = new ClickHandler(42)
const handler = instance.clickHandler()
handler.call(null, 'one', 'two')
This way, there is no need to define a bound handler in every concerned constructor.
Babel is doing its magic, which makes me very confused about what's going on.
What's the difference between foo and bar in this react Component? And when should I use which?
class MyComponent extends Component {
foo() {
//...
}
bar = () => {
//...
}
}
(My own guess is foo is in the prototype, and bar is in the constructor? Anyways, I don't know what I'm talking about)
My own guess is foo is in the prototype, and bar is in the constructor?
That's exactly right.
foo() {}
in this context is a method declaration and the value gets assigned to the prototype. It's equivalent to
MyComponent.prototype.foo = function() {};
bar = ... ;
on the other hand is a class field. This is a shorthand notation for assigning properties to the instance in the constructor:
constructor() {
this.bar = ... ;
}
And because of how arrow functions work, using class fields with arrow functions basically lets you create "bound" methods.
More on arrow functions: Arrow function vs function declaration / expressions: Are they equivalent / exchangeable?
And when should I use which?
The tl;dr is: Use class field + arrow function when you need a bound function.
When do you need a bound function? Whenever you want this inside the function to refer to a specific value but you don't control how the function is called.
That's mostly the case for event handlers (i.e. functions that are passed to other functions / components) that need to access the component instance (e.g. call this.setState or access this.props/this.state).
You don't have to use it though, you could also bind the method when you need to. However, binding a method only once in the constructor is ideal for React components so that, if the method is passed as event handler, always the same function object is passed.
As noted in another answer, this is not related to React at all. Class fields are likely officially integrated into the language this year.
In the second example bar is an arrow function.
Until arrow functions, every new function defined its own this value.
For instance, this can be a new object in the case of a constructor.
function Person(age){
this.age=age;
console.log(this);
}
let person=new Person(22);
Or this can points to the base object if the function created can be accessed like obj.getAge().
let obj={
getAge:function(){
console.log(this);
return 22;
}
}
console.log(obj.getAge());
An arrow function does not create its own this, it's just used the this value of the enclosing execution context. In the other hand, arrow function uses this of parent scope.
foo is an instance method of class MyComponent. While bar is an instance property of class MyComponent (that happens to be assigned an anonymous function).
It might make more sense to see it used in the traditional sense...
class MyComponent {
// instance property
someProperty = 42;
// instance method
someMethod() {}
}
So why use an instance property instead of an instance method?
Instance methods in javascript must be called within the class scope to inherit the class context (this)...
class MyComponent {
// instance method
someMethod() {
const value = this.state.value // ERROR: `this` is not defined
}
render() {
return <div onClick={this.someMethod} />
}
}
However, since arrow functions inherit their scope, this will be available if you use an arrow function instead
class MyComponent {
// instance method
someProperty = () => {
const value = this.state.value // this works!
}
render() {
return <div onClick={this.someProperty} />
}
}
Essentially, there is no difference.
This has nothing to do with React, though.
Arrow functions
Arrow functions are a relatively new feature added to Javascript that give you a way of defining functions in a more concise way.
function foo (param1, param2, etc) {
// do something
}
// becomes
var foo = (param1, param2, etc) => {
// do something
}
If you have only 1 param, you don't need the parantheses:
function foo (param) {
// do something
}
// becomes
var foo = param => {
// do something
}
If there is only 1 expression, and the result is returned, you can omit the {} too!
function foo (param) {
returns param * 2
}
// becomes
var foo = param1 => param * 2
this is not not updated
In an arrow function, you don't get a new this - it is the same as in the parent block. This can be useful in some cases (when using setTimeout, for example)
JS Classes
In ES6 we can also use the class keyword to define "classes" in Javascript. They still use prototype, though!
function Something (foo) {
this.bar = foo;
}
Something.prototype.baz = function () {
return baz * 2
}
// becomes
class Something {
constructor(foo) {
this.bar = foo;
}
baz () {
return baz * 2
}
}
So the constructor is done in constructor() and all the following methods are added to the Prototype. It's nothing but syntactic sugar (but kinda does some of the Prototype heavy lifting for you)
You can use extends!
class SomethingElse extends Something {
constructor(foo, lol) {
this.lol = lol
// Use super() to call the parent's constructor
super(foo)
}
baz () {
return baz * 2
}
}
This question already has answers here:
Should I write methods as arrow functions in Angular's class
(3 answers)
Arrow vs classic method in ES6 class
(1 answer)
Closed 5 years ago.
class App extends Component {
constructor(props) {
...
}
onChange = (e) => this.setState({term: e.target.value})
onSubmit(e){
e.preventDefault();
const api_key = "C1hha1quJAQZf2JUlK";
const url = `http://api.giphy.com/v1/gifs/search?q=${this.state.term}&api_key=${api_key}`;
}
render() {
return (
<div>
<form onSubmit={this.onSubmit}>
<input value={this.state.term} onChange={this.onChange}/>
<button>Search!</button>
</form>
</div>
);
}
}
What is the difference between the two type of functions declared in the class (onChange and onSubmit). I get an error on referencing this.sate in const url if I declare it as an ES6 class method but changing it to arrow function fixes it.
I want to know how exactly 'this' is handled in both the cases
Also, how do I do it the other way? Say, if I want to use the same onSubmit function (ES6 class method) but want to handle this when I call it (in the form element), how do I do it ?
Using this.onSubmit.bind(this) ?
It's important to know that this syntax:
class A {
method = () => {}
}
is just syntactic sugar for creating an instance method in the class constructor:
class A {
constructor() {
this.method = () => {}
}
}
Note: This syntax is not an official part of the JavaScript language yet (currently in stage 3) so you must use a transpiler like Babel to handle it.
The value of this within method is the class A because that is what this points to in the constructor (since arrow functions inherit the context from the scope they are defined in):
class A {
constructor() {
this.method = () => this;
}
}
const instance = new A();
console.log(instance.method() === instance); // true
Defining a regular (non-arrow function) method on the class creates a method on the class prototype (not instance) but sets no rules on what this will be (since this is dynamic in JS and depends on how a function is called, not how it's defined).
class A {
method() {}
}
console.log(new A().method === A.prototype.method); // true
If methods defined in either of these ways are called on the class instance (via the .), as per the rule of how this is bound when a function is called as a method of an object, this will point to the class instance in both cases:
class A {
constructor() {
this.methodOnInstance = () => this;
}
methodOnPrototype() { return this; }
}
const instance = new A();
console.log(
instance.methodOnInstance() === instance.methodOnPrototype(), // true
instance.methodOnPrototype() === instance // true
);
One major difference between the two method declarations above is that the instance method has this always fixed to the class instance while the class (prototype) method does not (we can change it by using Function.prototype.apply or Function.prototype.call)
class A {
constructor() {
this.methodOnInstance = () => this;
}
methodOnPrototype() { return this; }
}
const instance = new A();
console.log(
instance.methodOnInstance() === instance.methodOnPrototype(), // true
instance.methodOnPrototype.call('new this') === 'new this' // true
);
A common occurrence where the this changes is within an event handler, where the event handler calls the function passed into it and binds the context to the element on which the event happened (so overrides the value of this to be the element that was clicked or whatever the event was)
This happens in React as well for all (synthetic) DOM event handlers.
Therefore, if we want our method's context to always point to the instance of the React component, we can use the instance method.
Another way of restricting the context but not using the special instance method syntax that requires Babel is to directly create an instance method ourselves by creating a new function from the class (prototype) method with a bound context (using Function.prototype.bind):
class A {
constructor() {
this.methodOnInstance = this.methodOnPrototype.bind(this);
}
methodOnPrototype() { return this; }
}
const instance = new A();
console.log(
instance.methodOnInstance() === instance.methodOnPrototype(), // true
instance.methodOnPrototype() === instance // true
);
This allows us to arrive to the same result as using the special instance method syntax but with the currently available tools (ES2017 and under).
If for some reason we want a method that is always bound to something that is not an instance of the class, we can do that as well:
class A {
constructor() {
this.method = this.method.bind(console);
}
method() { return this; }
}
const instance = new A();
console.log(
instance.method() === console // true
);
An arrow function expression has a shorter syntax than a function
expression and does not have its own this, arguments, super, or
new.target. These function expressions are best suited for non-method
functions, and they cannot be used as constructors.
Arrow Functions lexically bind their context so this actually refers to the originating context.
In ES3/4 functions declaration you can use this by storing in some other variable.
const that = this;
onSubmit(e){
e.preventDefault();
const api_key = "***************";
const url = `http://api.giphy.com/v1/gifs/search?q=${that.state.term}&api_key=${api_key}`;
}
Also, how do I do it the other way? Say, if I want to use the same onSubmit function (ES6 class method) but want to handle this when I call it (in the form element), how do I do it ?
Using this.onSubmit.bind(this) ?
Yes you must bind the method to the component in the constructor. It's because the arrow functions get automatically binded to the class therefore the scope of this is set in the method. While onSubmit is a regular function that is not yet binded therefore the this inside the method will reference the function and not the component.
You need to use bind in your class's constructor with the ES6 class method. In essence, arrow functions do this for you automatically.
constructor(props) {
super(props);
this.onSubmit = this.onSubmit.bind(this);
}
The more important thing to note here is that I believe the arrow function here will be created on each instance of the class, where the ES6 class method will be made part of the class's prototype and shared amongst all instances.
The key difference is that in ES5 we don't have auto binding which means you have to bind your event handler function manually in order to play with state or props inside the function in react. But in ES6 it does auto binding. That's the key difference
ES5: you have to bind onSubmit preferably in constructor
//is valid
this.onSubmit = this.onSubmit.bind(this);
onSubmit(e){
e.preventDefault();
const api_key = "C1hha1quJAQZf2JUlK";
const url = `http://api.giphy.com/v1/gifs/search?q=${this.state.term}&api_key=${api_key}`;
}
ES6:
The below is valid because it does auto binding.
onChange = (e) => this.setState({term: e.target.value})
I've been working in React and Redux for past 2 years but when I was using inheritance in javascript, I found the difference between these 2 type of function declaration in javascript.
I've the class a and a class b which inherits from class a and whenever I'm running the following snippet, it logs out
bfunc called from class a
afunc called from class b
I assume that the syntax bfunc = function(){ puts the function in this and the syntax afunc() { puts the function in the prototype of class but I'm not really sure. Can someone please explain this behaviour?
class a {
afunc() {
console.log('afunc called from class a');
}
bfunc = function() {
console.log('bfunc called from class a');
}
}
class b extends a {
afunc() {
console.log('afunc called from class b');
}
bfunc() {
console.log('bfunc called from class b');
}
}
const bObject = new b();
bObject.bfunc();
bObject.afunc();
bfunc called from class a
afunc called from class b
Your assumption is correct. If you do console.log(bObject); you'll see that it has its own bfunc property that contains the function.
Since the prototype is only used when the object doesn't have its own property, this takes precedence even though it was put in by the parent class.
As #Barmar said in his answer, and in details:
Using babel this is what your code's transpiled to: [Follow the link].
If you beautified the transpiled version of the code you'll notice that defining a function like:
bfunc = function() {
//
}
Will a add the function to this.
While:
bfunc() {
//
}
Will be added to the prototype it self:
b.prototype.bfunc = function () {
//do something
};
Take a look here for more details on why calling bfunc using this will take precedence over prototype.
What's the difference between .call() and super()? Is super() just an es2015 thing? Or does .call() have more functionality?
super() calls the constructor of the class you extened
class Foo extends Bar {
constructor() {
super(); // calls Bar's constructor
}
}
call is a generic function you can use with any function
function a() { console.log(this); };
function b() { console.log(this); };
function c() { console.log(this}; };
a.call("hello");
b.call(123);
c.call({});
super knows which class you inherited from and automatically passes the correct this.
class Foo extends Bar {
constructor() {
super(); // calls Bar's constructor
}
}
call requires you to be explicit.
class Foo extends Bar {
constructor() {
Bar.call(this); // You had explicitly specify 'Bar'
// and explicitly pass 'this'
}
}
super lets you call functions on the parent implicitly
class Bar {
log() {
console.log("bar-log");
}
}
class Foo extends Bar {
log() {
super.log();
}
}
call requires you to be explicit
class Bar {
log() {
console.log("bar-log");
}
}
class Foo extends Bar {
log() {
Bar.prototype.log.call(this); // Explicitly reference bar's log function
// and explicitly specify 'this'
}
}
I think you could argue super offers a subset of the functionality of call. Some might call it syntactic sugar meaning you can use call everywhere you can use super, super is just easier because it implicitly calls stuff from the class you extended/inherited from (technically the next thing up the prototype chain?) and because it implicitly passes this for you.
I imagine you relate call and super because of code like the following:
function Foo() {
Bar.call(this)
}
class Foo extends Bar {
constructor() {
super()
}
}
In the case above, both examples do the same thing (call the constructor of Bar in the context of a new instance of Foo), but from there super and call differ greatly.
First off super is a key word, call is a method of Function's prototype.
The super keyword can be used to call the parent classes constructor and methods. So, in addition to the examples above super can do this:
class Bar {
constructor() {
//...
}
bang() {
console.log('bang')
}
}
class Foo extends Bar {
constructor() {
super()
//...
}
bang() {
// call parents method in context of `this`
super.bang()
//...
}
}
call, on the other hand, is a method of the Function class that allows a function to be invoked with an explicit value for the this variable. Consider the following function.
function baz() { console.log(this.bar) }
baz() // -> "undefined"
baz.call({ bar: 'foo' }) // -> "foo"
The above example is actually a little more nuanced. Unless in strict mode, this will be the global object (global, window). In strict mode, this is undefined, and our baz function will throw an error. With call we can explicitly set this, a very powerful feature.