All language subtitles for 031 Class Methods and Arrow Functions_en

Welcome back, guys.

In this lesson, I'm going to take a deeper dive into writing methods on classes, because right now

is actually a good opportunity for us to explore a very fundamental thing in not only JavaScript, but

also in react.

And that's the idea of writing our own methods on our class components.

Right now, we pass in this anonymous function into our search box handle change in order to set our

state and we know that we've seen the this keyword a couple of times now.

What is it actually representing?

Well, this is a special keyword in JavaScript that references the context in which it's being invoked.

So what does that mean?

Well, when I say this dot state, we know that I'm trying to reference the state on our component.

Right.

Our class component.

The only reason that JavaScript is able to say, oh, when we're calling this DOT state, I want the

state object on our component is because the this keyword is set to the context of our class component.

Now, the weird thing is that in JavaScript, when we write our own class methods, we'll see that the

this keyword actually gets bound differently depending on how we write the class method.

Now, we've already seen class methods in our app component when we look at, say, the component amount

mount, which is a lifecycle method, as well as the render an inside of these methods, they take this

format where it's the function name the brackets and then the squiggly brackets.

But the this keyword is bound.

Now, the reason that this is actually happening where the this context is getting bound inside of these

methods is because when we call super, we're actually extending the functionality that exists on component,

which we get from react that has these lifecycle methods and render because we didn't write them.

We're like borrowing them from component and when we borrow them from component, component actually

sets the context of this inside of them for us to our class components.

If we were to write our own method, for example.

To represent this method that we're passing in.

We would have to be careful about how we write it.

Now, let me show you now the reason in the first place we even want to rewrite this method in its own

class method is because there's a chance that we might want to use it more than one place.

And we don't want to write code more than once.

We just want to put it in one place, pass it in, and then change it in one place if we have to, and

not have to change it in multiple places.

Now, how we would do this is we would write this handle change method here, right?

Taking the same format that we see.

And it would take some event, right, which is the synthetic event we're getting back from our input,

as you remember.

And then we call this sad state in it.

And now we're able to actually pass handle change into.

Our handle change property on our search box.

Now, we can write it like this because we're passing the whole callback through to it.

Right is being referenced in the function definition, so we even though earlier we were explicitly

writing it out like this, this is the same equivalent thing because this door handle change is referencing

this full function with the e-signature.

But if we were to save this, we'll actually see that our original conversation, which is about the

this context is undefined.

If we start typing, we'll see that we get an error, it says, that cannot read properly set state

of undefined and it seems that this is undefined.

Well, why is this?

Well, this is actually has to do with the way the functions behave in JavaScript.

When we put handle change on our app.

All it knows is that if we say this not handle change inside the context of our app, it points to this

function, but it doesn't actually set the context of this.

The reason for this is because JavaScript by default, doesn't set its scope of this on functions.

You have to actually explicitly state what context you want this to be for us.

We want this to be.

Our app component and the method in which we can do it is to define it in our constructor because our

constructor is the code that runs first before anything gets called.

Right.

So we want to make sure that the context of this is correct in all of our methods before any code gets

written.

So what we could do is we could say this dot handle change is equal to this dot handle change, dot

bind and then this.

Now, what is defined behind what I find is a method on any function that returns a new function where

the context of this is set to whatever we passed to it and the context of this that we're setting in

handle change.

Right here.

Is the this keyword that is defined inside of our constructor, which knows that it's R component.

And now if we save, we'll actually see that it'll work as it was before.

This is actually a very verbose way of writing code, because that means that for every new class method

that we write, we have to bind it.

We don't want to have to do that.

We can actually leverage its six arrow functions and a unique characteristic about them that allows

them to set the context of this in whatever it was that declared it in the first place.

So what do I mean?

Well, Arrow functions automatically allow you to set this when this thing is defined.

So when our component is getting run by JavaScript for the first time and it's like, oh, I got to

instantiate this new app class, it checks inside and it sees that there's this handle change method

that points to an arrow function.

So then it defines the arrow function based on what code we've given it.

Right.

And the moment it sees the this keyword, it's like, oh, this is an arrow function.

I'm going to automatically bind this to the place where this arrow function was defined in the first

place.

And the context of this arrow function is AR app component.

So that's the crazy thing about aero functions is that you actually cannot called unbind on them.

They automatically get what's called lexical scoping, which just means that they bind that this context

to the place where they were defined in the first place.

And we can actually see this now that it will continue to work.

As it did before, right, even though we're not calling the Binde in the constructor anymore, so this

is really handy for us because it saves us that extra step.

In order for me to prove that this is lexical scoping, another way I can show you is inside of our

browser, the highest level context is our window object.

If I were to define a function.

Called New Funk, and what we're logging is console dot, log this when we invoke new funk.

We'll see that this is that window object when JavaScript saw us define new func to this function and

brought it into existence within our JavaScript context so we could start using it.

It had to lexically scope this to the window object because the window object was the context in which

our new function, our aero function was given its existence.

This is the same case with our handle change method.

When handle change was declared, which means that when JavaScript first created our app component.

It also defined all of the methods on our components, including handle change, and it saw that this

was an arrow function.

And because of this, when this arrow function came into existence to JavaScript, it was going to bind

any references to this inside of it, to the context in which it was defined, which is our app component.

Just like we saw with our my funk in the browser, that's what happened with our handle change.

And this is great, because if we want to right class methods, we just write them with this arrow syntax

and now the context of this is what we expect it to be without us having to write all of that extensive

binding code if we were to write it the other way.

So with this in mind, it makes it easier for us to write our class components and their methods.